The Testing Role in Agile: A quick note on skill expectations and test cases

As I mentioned in my previous article I am exploring different elements of a testing role in an Agile environment. One item I did not explicitly state was the assumed skill level of those who play the testing role. My assumption is that those working in the manner I am describing are skilled exploratory testers. That means they are able to effectively plan and execute tests without written step driven test cases.

In Agile the documentation that would historically be included in Test Cases should be moved in the body of a User Story in the form of Acceptance Criteria. Creating Test Cases based on the Acceptance Criteria would be a wasteful duplication of effort. The type of waste that iterative development methods such as Agile looks to remove from the process. The exception to this would be in a regulatory environment where that level of documentation is legally required. If there is no legal requirement then it’s important to remember the Agile Manifesto “Working software over comprehensive documentation”. If the documentation isn’t creating value then it’s not worth the effort of creating it.

Fast feedback is crucial in an Agile environment. Automation can seem like the best way to get it but only focusing on automation ignores what a skilled tester can bring when empowered to do so. If the tester finds value in documenting how they intend to test then they should do so. My personal concern is more around using Test Cases or Automation as the default rather than a tester making a choice as a skilled professional.

A skilled, empowered, engaged, and embedded tester will be able to give the best feedback in whatever method is appropriate. That method might be automation, verbal, metrics, or written. The goal is for tools to support what you do, not drive what you do. Let the skilled professionals drive testing. They will get you there safely.