Acceptance Criteria and the Prioritised Product Backlog - Part 13 (Video Training Course)

Responsibility for Testing

The general principles of Agile, and especially Scrum, do not differentiate between team members’ abilities and skills. A team member may be called upon to code one user story and test code for another story. Another practice that is often used is “pairing”, where two team members work on a user story, sharing the coding and testing responsibilities, especially when applying TDD. This tends to increase velocity of a sprint, because of the collaboration between the two team members. Paired testing is generally more effective, because the one partner of a pair may pick up a potential point of failure which a developer working in isolation may miss, because he wrote the code in the first place, and may have a blind spot with regard to his own code defects. Bringing the customer in while performing testing will also help, as they will be able to pick up quickly if the code to be delivered is not matching expectations. They may also find that the original specification is not what they required and will request changes. Although users are exposed to the latest code during the Sprint Review, there is no harm in being proactive and getting them involved prior to the review.

While we have been focusing mainly on Acceptance Testing and functional testing here, we also want to look briefly at other testing disciplines that may be required to deliver the product as specified.

Additional Testing Disciplines that may be Required

Acceptance testing usually tests the functions of a user story from a customer perspective, but non-functional testing could also be part of the acceptance tests. Non-functional testing looks at issues such as security, response time and performance. With the ever-growing rise in cybercrime, security testing should form part of acceptance testing, to check whether vulnerabilities have crept in as new code is developed. Performance is also important, as the most perfectly specified and developed application will fail if it is too slow or cannot handle a large number of concurrent users. From a quality perspective, load and performance testing should be performed at least once per sprint, if response time or a large user base is part of the requirement. Security testing should be done more frequently – ideally security features must be embedded into the user story development and not tacked on later. If your company is considering moving to a DevOps culture this is especially important – security is fundamental to DevOps, and is sometimes expressed as DevSecOps.

Testing has always been the poor relative of development in traditional projects – if the project manager needed to find extra time, the first activities to get the chop would be testing. Using frameworks such as TDD ensures that this cannot happen in Agile, and that there is an agreed standard of how an application should work, as expressed via the acceptance criteria. The delivery of quality (i.e. defect-free software working according to specification) is what Agile promises, and this can only be achieved with extensive testing.

Acceptance Criteria and the Prioritised Product Backlog – Part 13 (Video Training Course)

Responsibility for Testing

Additional Testing Disciplines that may be Required

Recommended Further Reading

Course Contents