SCRUM and Testing

From my experience, most, if not all, software development teams are following some sort of agile software development methodology. SCRUM being the most popular. Different organisations will adapt SCRUM to suit their need and figure out how this methodology can guide them in their development efforts. The differences from organisation to organisation are small and if you've experience with one well then you're ready for them all. 

The aim here is to guide you through my experience of how QA Engineers fit into this methodology and how to be a valuable member of a SCRUM team. So the SCRUM Guide won't mention QA engineers specifically, but there are references to quality throughout. It is at these points where you inject yourself into the development efforts.

Just a couple of definitions in case this is not familiar to you:

• Ticket: some work item, usually a business need like providing some piece of functionality to an end user. These might also be technical tasks that affect an area but with no visible changes. For example dependency updates.
• Backlog: simply a list of tickets.
• Sprint: a period of time in which a selected set of tickets from the backlog are delivered, usually all the way through to production.
• User Story: just a type of ticket.

Scrum Ceremonies

So let's focus on the SCRUM ceremonies:

1. Refinement
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective

Refinement

My favourite of all the SCRUM ceremonies. This is where the entire SCRUM team get introduced to a business need typically by the teams Product Owner, who is the teams link between the business and the SCRUM Team. These items usually come from the teams backlog. So if you're really savvy you'll have had a snoop pre refinement to give you the extra edge. 

Get involved, be objective and ask those questions that are bothering you. Use your business knowledge to challenge and inform. By questioning as much as we need to we get a better understanding of what needs to be delivered. Through in dept collaboration better approaches are agreed on. Everyones opinion matters.

If tickets have enough of the required information the team might decide it's time to estimate and label it as ready to be brought into a sprint. Estimation is relative to the team you're in. It normally takes a couple of sprints to get everyone singing off the same hymn sheet. Whether you're a new team, or new to a team it takes some time to be in sync, but, that does does not mean you should be estimating the same as everyone else all the time. If you feel strongly about an estimation let it be known. Risk and complexity are my two biggest considerations when estimating tickets. If it's high risk you might think it's going to need additional testing. And if it's complex the same so we can test those the common and maybe the edge cases to ensure what's delivered reaches the predefined level of quality we need to meet our definition of done.

Sprint Planning

As you'll have no doubt guessed, this is where the team plans the upcoming sprint. Business needs will have been fleshed out, broken up, estimated and marked as "Ready" in refinement. The product owner will have prioritised the backlog based on their knowledge of what the business requires. The SCRUM team will have an idea of their average velocity if the team is a somewhat mature SCRUM team. If the team is not mature, let's say a new SCRUM team, then it's just a case of best guess, accept you'll get it wrong(underestimate or over estimate) and form that velocity from here. 

Now we need to meet that average velocity with the highest priority tickets in our backlog. Once the tickets are selected, we'll then discuss how we plan to deliver these. This is where the entire team has a role to play. As a tester your input could be something like:

• What are we going to test?
• How are we going to test this?
• At what point are we going to test this?
• Are we going to write automated tests?
• Will we write automated tests in parallel with developers coding, close to in parallel, or after it's been released to some test environment?
• What environment do we want to test this on?
• What level of unit test coverage is required?
• Do we need manual exploratory testing?

Answering questions like these will give you, as a tester, your strategy to meet the planned sprint deliverables. It's important to be engaged here. 

You might be thinking sprints do not always go to plan. Even if they don't we're better placed through our engagement  and input in planning to either pivot and update our strategy or pivot and return to the course. Because if you think about it, we have no Strategy well then how do we adjust.

Daily Scrum

The heartbeat of the sprint they say. Held daily as the title suggests. This is just a regular check in on how the Sprint is progressing. In reality we collaborate a lot more throughout the regular working day than just in the Daily Scrum. We're either instant messaging our teammates or tapping them on the shoulder and having a chat if you're in the office. This is just a summary of our work plus those chats in front of the entire Scrum team so this information is not siloed amongst those who had the informal chat.

The daily Scrum can be used to make strategic decisions to pivot our strategy to cater for some unexpected need. For example, when you're testing you noticed a use case that we, as a team, didn't notice in refinement. Or a production bug has come in that needs an urgent fix and we need to address it as soon as possible. This helps the team be truly agile. And to achieve agility everyones input is needed because you're potentially deviating from the planned sprint strategy. Developers and QA(the dev team) can work together to adjust the strategy and cater for the unexpected.

And what if everything is going swimmingly? Well then your update will be just that. And that the predefined strategy to meet the sprint goal is working and we are holding course.

Sprint Review

The idea of a review is to get feedback on what was delivered during the sprint from stakeholders external to the Scrum team. Generally speaking, we're demoing developed business requirements in the form of something the end user can use. And the stakeholders present do not care about the ins and outs of the development that took place but only what the finished article looks like and how it behaves. Sometimes though we might have technical stakeholders like development managers and this is where we as QA engineers can demo some of the thrilling work delivered. Automation frameworks, coverage, reduced manual testing times, how they fit into the SDLC etc. will all be well received in this case.

Sprint Retrospective

This is usually the last ceremony held in a sprint and marks the end of the sprint. The Scrum team gathers and highlights the following(or some variation of):

• What went well
• What could be improved
• Actions to perform to improve

Everyone has their say here. Good ideas should never be shunned. So if you have ideas how the team could improve stand up and shout. As a QA expert in the team you know how to improve quality, speed up testing, increase coverage, help get code to production quicker etc. The retrospective is a great chance to voice your opinion and make a case for your ideas. So get talking and get actioning on them.

The Sprint Itself

In the sprint we start with a list of tickets that need to transition from written text to working software. Here's my take on the most common way for this to happen.

The blue is the path for the ticket to get from written text to working software. And the yellow are the quality gates that allow work to transition through the phases. Some look at this flow and think waterfall. I assure you it's not. This is a continuous feedback loop that allows very quick feedback to developers should there be any issues with what was produced. That's not to say the feedback loop cannot be shortened. Indeed it can. Not by adding to the above. But by rearranging. We'll look at the shift left concept in further blog posts. But I can assure that if you and your team are following a similar model you are doing software development well. And you are ready for the next steps. Remember, if you see potential points of improvement, bring it to your retrospective and get actioning.

So the developer gets their ticket and builds some software. They'll commit and push it usually via git to some centralised source control management system like Stash or Github. It's at this point the first quality checks are performed. Unit tests are ran on the branch, other developers perform code reviews and automated static code analysis is performed by a tool such as SonarQube. Can you as a tester get involved here. Yes is the answer. View, confirm and/or add to unit tests is an option. Code reviews? Give it a go and you'll surprise yourself. And begin to add to your automated suites. You now have a working(hopefully) branch get in there and start automating. Or maybe you started before this in parallel with the developer. Now you might be able to modify or even fully run them if you have branch testing capabilities. If they checks fail, feedback is given to the developer and any issues are addressed and in it comes again. Once they pass, the code is merged and the build is kicked off. Hopefully this is automated for you with some devops magic and the package is created and deployed to a test environment. Then we're into our next round of quality gates which is our automated end-to-end tests and maybe some manual exploratory testing if necessary. Again if anything fails at this point feedback is given to the developer and back in we come. And once they pass out it goes to the further environments where we might have another round of lesser tests. Simple and effective. And can be improved further of course.

Rinse and repeat for all other tickets in the sprint.

Conclusion

We've looked at the ceremonies and the lifecycle of tickets in a sprint and how you as a QA contribute to each to be a part of the software manufacturing line. It's important to be vigilant at all stages and look for areas of improvement. SCRUM will facilitate you in getting them improvements into your team and improving the manufacturing line. Just remember, be vocal and strive to improve.