Test smart: How to select testing techniques for agile team
Like it or not, an agile mindset has become mainstream in software development nowadays. The teams aim to be fast, flexible and responsive to evolving customers’ needs. The products are built in iterations, and development cycles get much shorter.
Development and testing activities are applied concurrently: each iteration has its testing phase. The teams release the new versions biweekly, weekly, or even every day. Once the development gets things done fast, there is always a higher risk of neglecting quality, and that’s where continuous testing is vital.
Sceptics will say: “So what? There are giant companies that have cut their quality assurance (QA) departments. They test in production”. That’s OK. However, one detail matters: these companies are so giant and their products are consumed so massively that they can afford to test already developed products live. In the end, their end-users will still tolerate the shortcomings in UX or even bugs. Furthermore, large companies have enough people and resources to fix reported issues immediately. And if your goal is to deliver a competitive high-quality product, testing is still essential for your software development lifecycle.
Testing in a more agile style
Looking back at my first year in QA, the variety of testing-related information was overwhelming. Yet, long lists of testing techniques seemed to be out of the agile context. It was not clear what, where, when and how to apply. Then I finally found a simple tool that helped me visualize it all.
If your team is heading towards agile practice, it is handy to apply the Agile Testing Quadrants. Developed by the pioneers of agile testing Lisa Crispin and Janet Gregory, testing quadrants is a taxonomy of various types of testing. You can use it as a thinking tool to empower the team to discuss which testing activities they might need and make sure they have the right people and resources to perform them.
Here is a sample of Agile Testing Quadrants filled with a few popular testing techniques. Each quadrant has its specific meaning and purpose.
Testing activities on the left-hand side are those that guide development. These are the tests that are performed before coding happens or concurrently as coding proceeds. For instance, at this stage, your development team might apply unit tests, integration tests, etc. Simultaneously, testers may evaluate prototypes (wireframes), test features (stories), or run end-to-end tests to check a new version for possible regression failures.
The tests on the right-hand side are those that critique (evaluate) the product after coding is complete. For example, once the MVP is ready, a team may apply exploratory testing, heuristic evaluation or test the product with users (user testing). Here, the team might also test potential security issues, measure the performance of the application, and other quality attributes.
As you might have noticed, the top half of the quadrants focuses on tests that are readable by business stakeholders and could be performed by testers, product owners, designers. The bottom half includes the tests that are written by or with the help of technical team members (developers or infrastructure engineers).
There is no strict order in applying selected testing techniques. As the authors of the testing quadrants model note in the More Agile Testing book: “Most teams concurrently use testing techniques from all of the quadrants, working in small increments. Write a test (or check) for a small chunk of a story, write the code, and once the test is passing, perhaps automate more tests for it. Once the tests (automated checks) are passing, use exploratory testing to see what was missed. Perform security or load testing, and then add the next small chunk and go through the whole process again”. Of course, this is not a golden rule. Therefore, the selection and sequence of testing activities should be adjusted to your team’s workflow.
Selecting the right techniques
In case your team is struggling with selecting proper testing techniques, it is smart to arrange a brainstorming session involving everyone: developers, testers, infrastructure engineers, designers, product owners. In this group brainstorming, use the blank version of Agile Testing Quadrants. Just draw a similar one on a whiteboard to kick off the discussion with your team.
As various types of testing exist, consult with your teammates and fill the agile testing quadrants with the techniques that match your unique context. After all, your team members will bring light on how testing should look from their field of expertise.
It is good to think about the speciality areas of your teammates and the product’s main areas of validation. Through open team discussion, you’ll select the matching techniques that will boost the product’s quality.
The obvious benefit of using testing quadrants is that a team gains more thoughtful and more collaborative insight into testing. Consequently, the team gets a chance to optimize a testing strategy by selecting techniques that fit their resources and project needs. And finally, a previously obscure testing effort gets clear so everyone knows what, where, when and how to test. As a result, you’ll get a good roadmap for testing. Anyhow, a lot of persistent collaboration is required to put the ideas from agile testing quadrants into practice. The reward is sweet: your team is getting more and more confident about the quality, and the customers are getting excited about the product.
Resources:
- Janet Gregory and Lisa Crispin, Agile Testing Condensed (2019): https://leanpub.com/agiletesting-condensed or https://www.amazon.de/gp/product/199922051X
- Janet Gregory and Lisa Crispin, More Agile Testing (2015): https://www.amazon.de/gp/product/0321967054
- Niket Sahu, QA Agile Methodologies: https://medium.com/@niketsahu/qa-agile-methodologies-50504d9eab92
