Why I do not like to be a tester in Agile project?

What do we understand as an Agile project?

What is the tester responsible for?

Where lies the main problems?

How we tried to solve them?

In February 2001, 17 software developers met at the Snowbird, Utah resort. They published the Agile Manifesto (Manifesto for Agile Software Development) to define the approach now known as agile software development.

Basic Agile principles are as follows:

• Working software,
• Self-organization and motivation,
• Informal communication,
• Inspect and adapt,
• Customer collaboration,
• Welcome changing requirements, even late in development.

It means only iterative incremental approach. What more as a result of each iteration one obtain the working software.

From results of Dr Dobbs Journal Investigations (2008) we know that Agile teams are more effective in desired functionality than “traditional” teams, but less in quality. In other hands testers are responsible for quality. What can we do to change this aspect, to obtain higher quality in Agile teams? The first step is done: DDJ found also that people believe that Agile teams produce higher quality (however it is NOT true) then traditional teams, hence one can observe higher satisfaction of stakeholders.

If we have 3-4 weeks for each sprint and as result, one obtains working software, testers must work mostly in a non-scripted manner; testers need also test automata. But – mostly of financial problems – it means that Agile teams concentrate on low-level unit tests. But module tests are limited in finding bugs:

• Capers Jones found that average effectiveness for a unit test is between 25 - 30%. (Capers Jones: MEASURING DEFECT POTENTIALS AND DEFECT REMOVAL EFFICIENCY http://www.rbcs-us.com/images/documents/Measuring-Defect-Potentials-and-Defect-Removal-Efficiency.pdf)

and

• Rex Black (for the American market ) found that good system tests done by independent test team achieve 85% effectiveness in founding bugs. (http://www.rbcs-us.com/images/documents/)

What can we (testers) do? and what are we doing?

The first solution is called “inverted test pyramid”. We – testers – try to replace “end-to-end” functional tests described in user story by some number of smaller unit tests and one, two integration tests. Does it works? It depends on the team, on strong cooperation between developers and testers. Yes, of course such roles do not exist in Agile team, but typically in 8 -10 persons team is at least 1, sometimes two persons, who specialized in testing. And they must cooperate, usually with 5, 6 developers. But “typical” developer

1. has limited business knowledge
2. believes that they do not make errors
3. typically thinks only on positive actions and many defects results from invalid action and/or invalid date

It results that 1 tester in Agile team must cooperate with 3, 4 developers, preparing appropriate unit tests for them. It means that such tester

• must have the business knowledge - on the Product Owner level
• must exactly understand the architecture of the whole system, not only the actually built part

The second solution – also rather typical – is independent external (out of the Agile group) test team, oriented on acceptance tests. This solution is used in many organizations, because clients do not believe in “working in real world” new software systems (new version of systems). In the moment such external team can work according to classical methods. Only one problem arises:

The Agile team work “behind closed doors” – during the Sprint time the team does not take into account any modification or suggestion – and information about failures can be treated as a new requirement. It means that such failure must wait 2 – 3 weeks for being taken into account and next 3 weeks for solutions. If one need faster fixing, the Agile team must change the way they are working.

Independently of the solutions, always the tester is responsible for quality. Hence he/she must work harder than in “classical” teams. The responsibility is also much greater.

Presentation

Video