If you’re a tester who has only worked on waterfall projects, you’ll definitely have questions when you start your first agile project. The two methodologies differ drastically so expect an adjustment period.
I speak from experience.
I spent many years as a Quality Assurance analyst before working on an agile project. There was definitely a learning curve when moving from testing on waterfall projects to agile projects. In the beginning, there were more questions than answers about this transition. Some projects were challenging because we used a hybrid approach of agile/waterfall (Can you say Scrumerfall?).
In Waterfall, my involvement usually happened at the end. With agile, it felt cool to be involved in feature discussions at inception and to work closely as part of a team. If you’re used to testing in waterfall, and are now working on agile projects, you probably have some of those same questions.
I am lucky to work with agile practitioners who have a great deal of experience with the behaviors that make someone successful at being agile. Two of those people are Shaun Bradshaw and Bob Galen. Both men have extensive experience as agile practitioners. A while back, they co-hosted a webinar discussing 13 essential patterns testers need to move from Doing agile to Being agile. They provided practical examples for each pattern.
This post will draw from these patterns. But first, let’s touch on the basics of what agile means for testing.
Let’s say you have experience in quality assurance but your company used waterfall as their project methodology. Perhaps the company is now moving to agile. You aren’t sure how that impacts your role. Like me at the beginning, you have more questions than answers.
As a waterfall tester, you’re used to receiving requirements documents to guide writing your test plans and test cases. From there, you write your tests then execute them. You open your defect management system and log the defects you discovered. When the defects are fixed, they are assigned back to you for retesting. If your waterfall experience is similar to mine, you don’t interact much with the rest of the project team.
A tester's role on an agile project differs greatly from waterfall. How to test, what to test, when to test, and who can test are all different. Testing is only one aspect of ensuring a quality feature or product.
Agile is a project management philosophy that uses a set of principles and values to help software teams respond to change. Agile teams value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to changes over following a plan. These values are outlined in the Agile Manifesto.
Scrum is an agile framework that helps teams structure their work into short development cycles called sprints. The team commits to delivering work at the end of each sprint. There are scrum ceremonies that help the scrum master, product owner and the rest of the team meet to plan work and get feedback.
This is a popular question. The most important distinction though, is that testing is only one part of how quality is built in for agile. Later, we will talk more about how quality is built in everywhere. First, let’s dig into what agile testing is and is not. In agile:
Agile testing includes most of the same types of testing as waterfall. From an execution standpoint, it’s almost the same in either case. With that said, there are some types of testing that are more common in agile. Types of testing include:
Unlike Waterfall, working software is more important than comprehensive documentation. There are no multi-page Test Strategy or Test Plan documents. Agile focuses on user stories and acceptance criteria. User Stories contain the Acceptance Criteria for a feature. During Sprint Planning or Backlog refinement, QA, Developers and Product Owners will discuss what a feature does. Often, as the team discusses the acceptance criteria together, modifications may occur. All Acceptance Criteria should be reviewed for testability as well.
Acceptance Criteria is used as the basis for test cases. Scenarios should be simple. In my experience, if I have formal test cases, they are simple steps in a google sheet. If needed, I only make notes in the Jira comments, noting my observations and including screenshots
Time is limited in sprints. A sprint is typically 2 weeks. Test cases should be prioritized based on the feature's importance and risk. Focus on high-priority and high-risk areas first. Time also needs to be allowed for regression testing. In addition, if tests are automated, part of the Definition of Done for a story is identifying tests for automation.
Yes! Testing is based on flexible requirements that can evolve. The most important features are completed first. This is a big change from waterfall where requirements generally remain fixed during the course of the project. Being flexible is key!
We want to address defects as quickly as we can. When a defect is found, the tester should immediately talk with the developer that created the code to quickly clarify the issue. This often allows for a collaborative approach to the resolution. Defects must be prioritized based on user impact and risk to project. High impact or high risk defects will be addressed immediately and lower priority defects can be scheduled for future sprints. The Product Owner will prioritize the defects. Defects are always discussed with the whole team as well.
The entire team typically attends scrum ceremonies. Keep in mind agile is collaborative and team members will work together often to program or test, so unscheduled meetings are encouraged and frequently happen in order to meet the goals of the sprint. Below are the agile ceremonies:
Now that we have covered the basics, let’s jump into the first four patterns that Shaun Bradshaw and Bob Galen talked about in the Essential Patterns of Mature Agile Testers. These behaviors are exhibited by testers who are agile and are not going through the motions of “doing” agile. In future blogs we will explore the other nine patterns.
Do you have trust issues? In my early days of testing on agile teams, I had serious trust issues. I didn’t trust that anyone could test except me. I was used to being on Waterfall projects where I didn’t always see requirements. I definitely didn’t get the opportunity to ask developers questions. The relationship between QA and Development was not close. In addition, the tests I created were not reviewed by the team. I also didn’t have much of an idea of what testing was being done by developers before their handoff to me. My main roles were writing test plans, then writing tests, followed by executing tests, and logging defects.
Bob and Shaun shared the following behaviors associated with this pattern:
I didn’t just have trust issues with other people testing. I also had trust issues with agile. On one of my first projects, we were working in sprints. Requirements were created in Sprint 1. Development was done in Sprint 2. Testing was done in Sprint 3. We had sprint ceremonies such as Sprint Planning and Retrospectives. We were also heavy with Test Strategy and Test Plan documents. We were simply doing Waterfall and including some agile methodologies here and there.
The gist of this pattern is that as testers, we need to work with our team to “swarm” the important tests, bugs and tasks. We can’t be test documentation-heavy either. We also can’t throw in parts of agile and scrum but still do Waterfall. Bob and Shaun suggest avoiding Scrummerfall. They also suggest starting testing as soon as code is ready. Most importantly, as a team we need to focus on testing the most important stories or defects in the sprint.
I recently worked on a team that believed quality is everyone’s responsibility. I would pair with one of the backend developers while he performed his unit testing. I was able to suggest additional tests for him, and he suggested tests for me to do during functional testing. I also did testing with the Product Owner in order to find any customer-facing issues as quickly as possible.
For this third pattern, Shaun and Bob mention the following behaviors:
• Everyone is responsible for testing/quality
• Opportunistic pairing between Developer and Tester
• Engage in debate
• Design for test and testability
• Focus on the most important tests
• Stop reinforcing thinking in terms of silos (“Development Complete” or “Test Complete”)
• Everyone on the team owns the QA outcome
This is the most important of the patterns. Quality shouldn’t be assessed after development is complete. If there wasn’t a focus on quality prior to testing, more defects will be introduced. The entire team should focus on quality at every phase. Quality should be built in as early as defining acceptance criteria. Testing should focus on the important features for the sprint. In this pattern, there is also discussion around removing silos. We can’t afford siloed team members.
Shaun and Bob discuss the following behaviors for this pattern:
I hope this blog has answered some of your initial questions about testing on an agile project. Using the patterns mentioned will help you on your journey to be agile and work with your team to ensure quality. There are many more agile resources on Zenergy’s website. We have blogs and webinars done by our agile practitioners that you can check out as well. You can find them under the Resources link at https://www.zenergytechnologies.com/
Check out our Agile 101 workshop, suitable for anyone looking to learn the basics of Scrum or Kanban.