Testing is a very different skill set to software development. Testers look at the problems that software developers are solving through a different lens. They are analytical and are ruthless in finding the problems hidden within the most finely crafted software.

In traditional software delivery methodologies, testing follows development, just as night follows day. To development teams, testing is hindrance and to testers, software developers are people who cut corners and put the team under pressure to release sub-standard software. The two roles are working against each other which can made for a stressful working environment.

In Agile delivery methodologies, rather than fighting each other, the two roles work together. Testers help developers build code that is easier to test and developers show testers at first hand just how complex software development can be. The roles combine to produce high quality automated testing solutions.

As I said above testers are analytical. They are driven to find problems and when they do find them they want to document what they have found. They describe how to reproduce the issue, its severity, based on a set of clear classifications and then build up a log of all discovered issues so they can determine whether they have been fixed or to be used to determine if issues reoccur in the future. What they like to do is find and then document bugs.

In Agile delivery things are different. An user story is either done or it isn’t. Testers have a valuable role in determining whether a story is done. Done could mean that the story is released to Live or more likely it has been deployed to a pre-production environment, it is working correctly and it is waiting to be deployed into production by another team. When the story is started the developer and tester define the acceptance criteria for the story. These are the criteria that defines if the story is done. These can be turned into automated acceptance tests but they could simple be a set of tasks that are checked manually. Development on the story continues until the acceptance criteria are met.  If the tester finds that the criteria are not met the developers undertake more tasks until they do.

Where is the documentation that ensures that issues found during development are not reintroduced?

These are the acceptance criteria for the story and this is why is a useful to build them up and automate them over time. Once they are in the acceptance test suite a successful run gives everyone confidence that no issues have been introduced. If it fails you can usually pinpoint the problem by identifying which test has failed. So in my opinion an issue found by a tester in a story that is in progress is not a bug, it is simply represents more work.

Does this mean that there are never any bugs?

This approach greatly reduces problems getting into live and also helps you to avoid reintroducing problems. However that is not to say that your software is problem free. Customers may report problems or exploratory testing might find issues not covered by acceptance testing. Finally automated error logging may identify problems neither your customer nor your testers can see.

These are bugs and they should enter your backlog in the same way as any other work. Once identified it is up the tester to provide a severity, from the product being completely broken and inaccessible, through to the product not working as designed but there being work arounds, to simple cosmetic issues. Severity should not be confused with priority. They can be related but not always. For example a typo is low severity bug but it is high priority in the backlog if the typo is your best customers name!

In traditional software development, long list of bugs were sometimes treated like a badge of honour by the testing team. It demonstrates the effectiveness of the testing team. Test exit reports which include counts of bug by severity become a bargaining chip between customer and supplier as to whether a product can be put live. In Agile software development low bug counts are worn as a badge of honour by the whole team which indicates the quality of the software they are delivering.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s