How do You Test in Agile Environment?

Testing in any industry means a product is built and tested. Take for example, a car tested against wet road surfaces or for maximum speed etc. This is known as “Quality Control”.

The term “Quality Assurance” however is a much better fit for software development. We make sure that quality is defined and built from beginning of software development process, not just to check at the end of production.
In major Agile techniques, the workflow (shown as columns in Kanban and Scrum boards) is divided up the into following stages:

• Defining the requirements (Backlog)
• In development
• In test
• Done

There might be more columns on the board but the ones above are common to all variations. Each of the two week sprint turns into a mini waterfall when the team members do not collaborate and there is a clear handover from BA to developers and from developer to testers. As you can see, testing contributes to the project as ‘Quality Control’ instead of ‘Quality Assurance’.

So how can we quality assure from the beginning? This article aims to address this challenge. In part I of this article we will concentrate on only defining requirements part. Part II will deal with development and testing stages.

Defining the requirements

At the beginning of the sprint developers and testers are given a list of stories. If requirements for these stories are determined without any collaboration between developers, QA Engineers and BA’s or PO’s then several problems will rise from this:

• The requirements can get lost in translation when multiple stakeholders are involved.
• When the requirements are defined in abstract terms, they can be ambiguous and overlooked until developer(s) start working.
• The requirements do not tend to include negative or edge case or unlikely scenarios.
• A particular requirement may conflict with existing functionality, or the requirements may be inconsistent with each other.
• The requirements may force a certain type of implementation or technology without defining what business problem it is trying to solve.
• Business Analysts and Product Owners may be the domain experts and what seems obvious to them may not be obvious to developers or testers (or worse the words might mean something else to them).

Team members with different expertise may not have the same understanding from the same subject. Like one comedian pointed out, when he hears “disabling cookies” he thinks of biting the legs off a ginger man biscuit.

So how do we prevent ambiguity during the requirements definition phase?

The solution is to acknowledge there is a communication gap and resolve it. The best way of achieving this according to Gojko Adzic author of ‘Bridging the Communication Gap’ book is to run a specifications workshop before each sprint. The workshop should be attended by BA’s, developer(s), QA Engineers and if possible stakeholder(s).

Preventing the workshop from turning into another boring meeting

• Every participant should focus on what the requirements are and not how to develop or test them.
• The workshop should take no longer than 2-3 hours.
• Only stories which will be implemented in the next sprint should be discussed nothing else.
• To cover as many important cases as possible, each requirement should be explained by specific examples.
• The specific examples should be documented and signed off by the BA.
• If the BA needs to obtain more details about the specific examples from stakeholders, then this should be noted down and one of the participants should be assigned to chase for the answers.

The list item 4 deserves more explanation. One of the best ways of understanding a new concept is to give examples. So I am going to give you an example about how to write examples:

Example of “Specification by Example”

Requirement: “User has to enter a valid amount into the textbox to execute a spot trade on a tile. See the UX design below”:

The questions a developer or QA Engineer might ask to the BA:

Now that we have all the questions we can think of answered, we can organise it into tables for neat presentation:

We now have a clear requirement which is ready to develop and write acceptance tests. In this approach ‘Business Requirement’ becomes equal to ‘Acceptance Testing Criteria’.

The benefits of specifications workshop are:

• Everyone in the team think harder about needs of business and users,
• Identify gaps in the initial set of requirements,
• Potential bugs are eliminated,
• Acceptance criteria for testing are already determined (QA starts now).

A specification workshop is not a:

• Sprint planning meeting,
• Software design meeting,
• Sizing meeting,
• Test design meeting.

In the next part of this article, I will take you through how to validate this requirement which happens in development and testing phases.