The Sprint has started and I have a set of user stories to test. Now what?
By: Hal Deranek
Tags: QA, Testing My Story, Software Testing, Automation, Quality Engineering

Photo by Icons8 team on Unsplash

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.

Who this is for:

Testers in a project using the Agile methodology

Testers who create manual and automated test cases

Testers who want to improve their organizational skills

Create tasks for each story

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.

Task 1: Create Manual Test Cases

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).

Task 2: Create Test Code Scaffolding

One of the banes of automated testing is often this refrain: “I can’t start until the developers have completed their work.” Poppycock 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”)

Task 3: Connect the scaffolding and write a basic automated test

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.

Task 4: Complete the remaining automated tests

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.

Reality Check

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.

What About Feature Updates?

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.

— 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.

— 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.