When the topic turns to testing and Agile software development, I usually hear variations of the following two questions:
- We usually take six weeks to do systems testing after development is over. How could we possibly develop AND test something within two weeks?
- If developers are doing the testing, what do testers do?
This post addresses both questions in part by questioning the assumptions that underlie them.
Everyone is responsible for quality throughout your process
The first question is based on the assumption that the sole purpose of testing is to check quality after the product is built.
A better approach is to build quality into your product. To do that effectively everyone on the team needs to own quality, not just the testers.
What does everyone “owning quality” look like? To start off with, as Karen Greaves and Samantha Laing suggest in their Coach’s Guide to Agile Testing, stop thinking of testing as trying to break the product in order to find bugs. That approach leads to an adversarial relationship between the builders and checkers and does no one any favors.
Instead, think of testing as preventing bugs to get to the best product possible.
Use the three amigos concept to get people with different perspectives (business, development, testing) together to discuss the problem you are trying to solve and identify possible solutions. Have your three amigos use behavior-driven development (BDD) to identify examples in order to build a shared understanding of the problem and possible solutions.
Encourage your team to use test-driven development (TDD) to ensure they’re building the solution right. Follow that up with acceptance test-driven development (ATDD) to make sure you built the right thing.
When you seek to build quality into your product, it no longer makes sense to treat testing as a phase you do after the product is built. Testing is now an activity that occurs throughout your entire process.
One reason that system testing always takes a long time is that teams generally want to run at least some regression tests. Not only do you test the new functionality, but you also want to (or at least should) test functionality that you didn’t change just to make sure you don’t have any unintended consequences.
The more complex your product, the more regression tests you need to run. This is where automated testing comes into play. The more you can automate the tests you need to run, the quicker you can run them and identify any issues you may have inadvertently caused.
Test automation is a key aspect of TDD and ATDD. When you first write the tests and the code to make them pass, you’re confirming that you’ve built the product properly. If you automate those tests so that you can run them again and again, they then become part of your regression test allowing you to quickly tell if you changed something you didn’t intend to.
Automated tests also support safe refactoring. They provide that safety net for you to change the structure of a bit of code and know that you didn’t impact the end result provided by that code.
Automated tests are good, but that doesn’t mean you should automate everything. While you should seek to automate all of your unit tests, you don’t necessarily need to automate every acceptance test you can possibly think of, and you should automate tests through the UI only when it makes sense. A rule of thumb is to automate the tests that provide the fastest feedback.
And there are going to be some tests that you don’t want to automate at all – exploratory tests. You want to identify situations your team hasn’t identified before. You’re looking for unknown unknowns. It’s difficult to automate testing for something when you’re not sure what you’re looking for.
Testers help the team consider “what if”
So if everyone on the team tests, does that mean that testers don’t have anything to do?
Hardly.
If everyone is testing, you want to make sure they are doing it effectively. If you’re a tester, you’ll adopt the role of part-time coach and mentor helping everyone else on the team learn how to test the right way. You’re also there to provide perspective and to be one of the three amigos that always asks “what if” and encourages your teammates to ask the same question.
You can be more involved in defining what the team is building. You can work alongside the people on your team building the solution to catch those little bugs that sneak out when someone works on something by themselves. You can perform exploratory testing to identify the situations you didn’t think of initially.
Along with all of that, you’ll get the opportunity to expand your own skills into areas you may not have had the opportunity before.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
