Agileista

What is testing?
There are two main sides to testing and both are about delivering value . Above the waterline you have quality indicators that are visible to everyone. These deal with the experiential quality of the story. Below the waterline is code quality testing. This helps us to understand how expensive development and maintenance of the code is. A good agile or scrum implementation uses Acceptance Criteria or Q&A style functional black box testing, adding code testing such as unit testing and continuous integration. Omitting to do either side of this testing can have some pretty negative consequences.

Different types of testing
Acceptance criteria cover the visible or functional above the waterline tests. Validating functional correctness of the story. By defining how the story will interact with the user and visa versa the Product Owner (PO) can test for expected functionality. Acceptance criteria can also define any restrictions in functionality: for example, only accepting Visa for an ecommerce payment story or stating that no registrations can come from a web based email account.

From the team's perspective these tests also let the team know when they are ‘done’ with a story because if a story does not pass its Acceptance Criteria, it is not accepted as complete by the customer or Product Owner. If this happens the team are not awarded the estimated points for the story and the story is considered to have not been delivered, remaining on the backlog until it is.

Acceptance tests can also be used for release and regression testing. This moves us nicely on to code quality and build quality testing. The team need to know that what they've coded won’t break everything. Continuous Integration checks the entire code base each time code is committed to the repository and Test driven development can help you to build safe to re-factor code that also conforms to the acceptance criteria tests. The quality state of the code-base will affect the complexity estimates the team make for a given story as much as anything.

If you make sure to get those acceptance criteria exposed and agreed before each Sprint then at least that gives you and your team the ability to implement as much or as little testing as needed. If you don’t have acceptance criteria then your options for testing and knowing if you're doing the right thing are limited. What are everyone else’s experiences of testing in an Agile or Scrum environment?