Published in · 6 min read · Feb 7, 2019
If you’re an Agile tester, odds are that the start of each sprint begins with the question of what to do with the user stories. It’s easy for developers — pick a user story off the “To Do” pile and start working on it. In my experience, there are rarely stories or tasks written for the QA group. So what does the testing team do?
In this article, I’ll talk about an approach I use in creating and organizing tasks for manual and automated testing so that testing can start work from the start.
- Testers in a project using the Agile methodology
- Testers who create manual and automated test cases
- Testers who want to improve their organizational skills
Assuming you use some kind of software tracker (like JIRA), you’ll see all of the sprint’s user stories. These are written to describe a new/updated feature and are generally taken on by developers. One thing — where are the tickets for QA? That’s where you start.
Right from the beginning of the sprint, create task tickets based off each user story:
- Create manual test cases
- Create test code scaffolding
- Connect the scaffolding and write a basic automated test
- Complete the remaining automated tests
Each user story will have these four tasks associated with it. (Whether you want to make them subtasks or not is up to you and what is correct for the cadence of your project.) This will allow you to track what needs to be done, what is in progress, and what has been completed. It will also give the rest of your team a better understanding of the work being performed since it’s more visual. Win-win!
Let’s talk more about these four tasks above.
In this task, you will create all of your manual test cases in whatever test case management software you use (TestRail, Excel, hotel napkin, etc.). Here are some general guidelines I try to follow:
- The test cases should have enough detail to allow anyone with a basic knowledge of the project to run them.
- The cases should also not test too much. For example, each action should have its own test case along with a case for the style, content, etc.
- Each user story will often have at least four or five test cases. If you add edge cases the number of test cases can increase exponentially.
- Writing test cases often gives you your first thorough look into a user story and is a good time to ask questions. How a feature will work, what happens if the user does X, if the text should match similar text used elsewhere, etc. This is the perfect time to ask these questions, especially if the developer has yet to begin their work (as they will likely have similar questions).
One of the banes of automated testing is often this refrain: “I can’t start until the developers have completed their work.” Poppyco*ck and balderdash! You can start writing your test code as soon as you receive the user stories. How? Write the test code scaffolding!
Scaffolding is meant to write the broad brushstrokes of the test code. The goal of code scaffolding isn’t to be complete nor to be fully functional. The objective is to get the feature described in the user story into your testing code quickly and early. Once the developer has completed their work, you should only have to connect identifiers from your code to the identifiers in the software elements for it to work.
Scaffolding also allows you to think more holistically about your project. Don’t just think about how the feature described in the user story works. Consider how it fits in your project.
(For more on code scaffolding, please see “Stop Waiting for Developers! Utilize Code Scaffolding And Get Ahead”)
Three things need to have happened to make it to this point:
- You have written out all your manual test cases
- You have completed the test code scaffolding
- The developer’s code has made it through code review and has merged it into a develop/testing branch
Once these are done, you can connect the code scaffolding that you’ve created and write out a basic automated test. Let’s get into that:
Connect the code scaffolding
In Task 2 we created the code scaffolding. Now it’s time to connect it to the code from development. You will use the identifiers for the feature’s elements (via CSS, xpath, IDs, etc.) in the code scaffolding, connecting the two. Once this is done, you’ll…
Write a basic automated test
A basic test should be something simple that will touch as many elements of the feature as possible. Something such as “All the expected elements for the feature are on the page and have the correct text”. The point of the basic test is to ensure the properties of the feature are accounted for in your scaffolding. Performing other tests should (theoretically) be possible without much hassle if you get those connected and validated.
Now that you have connected the code scaffolding and written a basic test, it is time to write the remaining automated tests for the feature not completed in Task 3. These should be more in-depth tests, such as actions, data validations, edge cases, etc.
Once all four tasks have been completed for that feature/user story, you can say that all work on it has been done. Of course, this is an ideal. Depending on your project’s cadence, expectations, available resources, etc., you may not be able to complete all the tasks. For instance, on a recent project of mine, we agreed that only Tasks 1 and 2 would be required for each sprint. We would complete as many Task 3s as time allowed. It was understood that Task 4s would likely live in the backlog. This still allowed us to complete all manual testing, capture 100% of the functionality delivered by development in our test code, and write approximately 35% of our test cases into automation.
As projects go forward you will start to see user stories that update current functionality rather than create new (i.e. — maintenance). When you come across this, it will be up to you as to how you should proceed. Is it a simple text update or a full refactor? Will the updates needed be easy or complex? For this phase, I generally will rebrand the tasks above like this:
- Task 1: Update Manual Test Cases — assuming the updates aren’t a complete tear-down, you should be able to update the current test cases. You may need to write some new ones, too.
- Task 2: Update the automated test cases — again, assuming the updates aren’t a complete tear-down, you should be able to update the current automated tests to work with the updated UI code.
- Task 3: Complete the remaining automated tests (optional)— if you do find that the updates require new automation code, it should go in this task. If there’s no new automation needed, you can omit this task.
“What about creating code scaffolding?” Since these are updates you shouldn’t have to create any new scaffolding. If you do, it should be so minimal that it can be covered in Task 2 or 3.
“What if it is a complete tear-down?” If the ‘update’ is a total refactor of a feature, then that’s really not an update. You should treat it more like a new feature. This will be more difficult, as your automation will need attention for possible new patterns and logic. You might want to create a fifth task — Task 5: Remove Unused Code, but this should be a rare occurrence.
With all that said, I hope you now have a better understanding of how to approach user stories, how to create and organize tasks around them, and how to get your automation to keep pace with development’s output. Remember - it is up to you as to how best use this with your project. No two are the same, and what works for one won’t necessarily work for the other. Using the information above, you should be able to find a plan and cadence that works for your team. Good luck!
