Agile Myths - Part 1

August 19th, 2014 by inflectra

The enthusiasm these days for Agile development is rightly deserved, but with so much being written and said about Agile development, there should be room for healthy debate. While Agile development has proven to be a huge step forward and the right approach for many projects, it is important to continue to ask questions in order that we don’t start to endorse the bad along with the good. We don’t want to throw the baby out with the bathwater, but we can’t keep the bathwater just to avoid the risk of doing so. An occasional examination of principles being promoted and used within the industry helps to maintain Agile methods as the best alternative to traditional development practices for many projects.

In this series of blog postings we shall discuss some of the characteristics of various Agile methodologies and ask whether the ideas are valid or whether they are in fact, industry myths.

Myth 1 - Test Cases Can be Used as Requirements

This is an interesting idea because it tries to conflate two different types of information, namely requirements and tests. But that’s the point, I hear you cry! However, we must be careful how we allocate responsibility for these requirement/test hybrids. If they are created by traditional test engineers then we have testers defining the product, however these are not typically the skill types used to define solutions. There is also the risk that in trying to write solid and definitive tests which are easy to execute, the engineer may influence the solution negatively. Instead of test engineers as authors, the requirement/test hybrids could be created by someone in the role of product owner, but then the product owner is writing tests, which seems equally undesirable.

Agile Teamwork

The problem can be overcome with another Agile development principle, that of cohesive teamwork. Within Agile projects, roles are merged and combined in ways that would not be viable in traditional projects. By defining roles that allow individuals to work closely with both developers and stakeholders, test cases can be created by individuals who are able to refine the user stories in the form of test cases. This element combining requirement information and test information can reduce effort and improve quality by making requirements effectively their own test cases. But it can be risky. By trying to get to the solution faster, it puts great responsibility in one place; get that wrong and the consequences could be significant.

Use a Productivity Tool

To reduce this risk, any interactions with stakeholders which lead to the understanding of either the problem or the desired solution should be recorded using a robust productivity tool; ideally a tool that can manage user stories, requirements and tests as well as the relationships between them. The new test cases that also refine the user stories reduce the number of transitory steps between need and software solution and can easily be used as a level of validation with the stakeholders, who now only have one set of data to approve, killing two birds with one stone.

As we can see then, there are clear benefits to using test cases as one level of decomposition below user stories and therefore this idea is not a myth, provided it is not implemented as a singular initiative but is used in an environment where other supporting Agile principles are practiced.

You may also be interested in:
10 Questions You Should Ask When Choosing a Tool for Requirements Management
Testing in Agile Projects: Familiarity Breeds Consent
Principles of Requirements Engineering (or Requirements 101)
The Cost of Quality Assurance