The transition from being a waterfall tester into being an Agile tester can be a rocky road for some! Over the years, McKenna Consultants have developed a wide experience of Agile testing. Agile Testing is distinct from waterfall testing in several ways.
First of all, most testers have gotten used to being at the end of a long development process. They have become used to being passive participants in the software development game. Effectively they sit and wait to be given something to test and then they work out a test plan and then they manually test the software (and raise lots of bugs).
An Agile tester is proactive. An Agile tester does not wait to be given something to test. They seek out developers and Product Owners to find out what is being worked on. Agile Testers have this kind of conversation:
- Agile Tester: “Hi, Nick! What are you working on today?”
- Nick (The Developer): I’m creating a login screen for the web portal.
- Agile Tester: “Oh , great! How can we test this?”
Eventually the developers and other team members will learn to approach an Agile Tester before they start work on a new User Story so that they can develop a test strategy (and tests) in parallel with the development effort. A good Agile Tester encourages the “tester’s mind” in others and encourages their team to always think “How are we going to test this”.
When should Agile Testers get involved in a project?
Agile Testers should be involved from the beginning in a project, not dumped on at the end. During Foundations (DSDM) or Sprint 0 (Scrum) or Elaboration (RUP) the tester should be involved in defining the test architecture and strategy for the product in the same way that the developers will define the software strategy and architecture. Key questions about what types of testing are planned should be answered (see Lisa Crispin’s Testing Quadrants for details on types of testing).
Preparing test cases
The preparation of test cases and acceptance criteria (which will be very similar or the same thing) is important in an Agile project.
Depending on the personalities and availability of the team there are two principal strategies to consider.
The first strategy is to develop the test cases ahead of time (i.e. an iteration or two before the development work is planned to take place). This means that everything is prepared and thought through so that the developers can smoothly get on with the work that needs to be done. They are never “starved” of requirements. On the other hand, the risk is that time is spent developing test cases for features that are then deprioritised (i.e. waste).
Another approach is to prepare the test cases on demand. This works when the resource to develop the test cases is very limited. It also has the low-waste benefits of “just-in-time” delivery. On the other hand, this approach means that we will have all of our requirements headaches and problems just as we need the requirements for developers which creates a less smooth development process.
The role of an Agile Tester
The good Agile Tester is an ambassador for testing. He or she should encourage others to test and drive the quality message to others within the organisation. Agile Testers should be proactive in running workshops, seminars, training courses etc explaining to others how they think and the techniques they use when developing tests.
What needs to be tested?
In an Agile project EVERYTHING should be tested! For example, when was the last time you tested your specification / requirements / user stories / use cases? When writing them up, did you think “How can I test THIS DOCUMENT”? How could one possibly test a document?
Recently I was writing on outline specification of about 100 pages to give some idea of the scope of a major project. This was intended for a variety of audiences from the developers right through to the executive board of the business.
From experience I know that there is no correct way to write this document and I had no idea what the best way to do it for this team would be. I thought that I needed to be able to test the document as I went. So I wrote the contents page and introduction and sent it to my intended audience asking them if this was the document that they wanted to read.
It turns out I was pretty accurate. So I wrote Chapter One and circulated that. Then Chapter Two. All the time I was trying to fail early. Rather than spending days writing an incorrect 100 page document, I wrote a few pages at a time and tested them as best I could by sending them to the intended audience. You can test everything and a good Agile Tester should encourage this in everybody.
Agile gives rise to this collaborative approach to testing. It is not the Agile Testers responsibility to test. It is their responsibility to ensure that the software is of good quality. The only way to do this is to “bake in” quality. Consider these three definitions of a good tester:
- A good tester is someone who finds lots of bugs
- A good tester is someone who gets lots of bugs fixed
- A good tester is someone who prevents bugs from occurring in the first place
Of these, my definition of a good Agile Testing is number 3. Good Agile Testers “pair program” with developers (and others) to install a sense of quality and how to test. Agile testers discuss and evolve tests with everyone else. Agile Testers are the leaders in the field of quality, but are not the only source of tests. They gather everyone’s ideas together into a cohesive test strategy and plan.
Ideally, testers should never find failing tests because they have discussed and agreed the test strategy / plan with the development team before development takes place. Agile Testers make their tests available to the team whilst the tests are in development rather than waiting until development is complete to create unknown tests. This prevents the bugs entering the system in the first place which reduces the time and cost of development and drives up the quality.
Automated testing is key to success in Agile
Not all tests are automated (see Lisa Crispin’s Testing Quadrants again), but without automation it is very hard to create a rapid Inspect and Adapt feedback loop. If it takes five days to execute your manual test scripts you are going to be stuck in a waterfall process! The kinds of things an Agile Tester should be encouraging their team to automate are:
- Unit Testing (make sure your team knows the difference between Unit and Integration testing)
- Integration Testing
- Acceptance Testing
- GUI Testing
- Disability Testing
- Security Testing
- Maintainability Testing
- Performance Testing
- Load Testing
That’s a lot of automation! In reality Agile Testers prioritise these areas of automation (and include some not on this list) for economic reasons (i.e. there are never enough people to do it all!). McKenna Consultants have worked as an external test partner for many companies helping them develop these automated test strategies.
So, to summarise, the Agile Tester should:
- Be proactive
- Collaborate
- Be an Ambassador and Leader for testing and quality
- Prevent bugs from occurring
- Automate the appropriate parts of the testing process
Get in touch with our team to learn about range of Agile Services and Workshops to kick start your transformation.
