Designing and maintaining test cases for a fast-paced agile team can be a real challenge. Testers don’t often receive rich requirements for test planning in advance, and they aren’t given months notice to write test-case specifications. In fact, it’s not uncommon for a tester to get his or her first look at a working piece of code just before the hopeful go-live deadline.

In order to overcome this common challenge and speed up the entire testing process, agile teams can implement a few different strategies to simplify team communications, reduce the risk of development rework, and increase the overall quality of delivered software.

Light and Fast Strategy #1 – The Three Cs

The Three-Cs concept, heralded by Ron Jeffries, emphasizes a discovery process instead of a traditional requirement/specification process, forgoing the precondition of comprehensive information early in the development cycle. The three core elements are as follows:

• Card – Write user stories on cards. The card does not contain comprehensive requirement information. Instead, the card has just enough text to identify the requirement and remind everyone what the story is. Keep it simple.
• Conversation – Customers communicate requirements to the team through conversation, including thoughts, opinions, and feelings. Conversations take place over time and are particularly important when a story is estimated (during release planning) and again when the story is scheduled for implementation. Conversations should aim to produce executable examples, which Jeffries calls confirmations—assurances that the team understands the goal and is producing the agreed upon functionality.
• Confirmation – Regardless of how many conversations and examples are produced, certainty of success cannot be achieved without the customer-generated acceptance test. As the ultimate judge of all our development and testing efforts, the customer must be the primary voice that defines the parameters of success.

This lightweight approach replaces the time spent writing exhaustive documentation with conversation and collaboration. A good user story should collect and summarize conversations and log the agreed upon confirmation/acceptance tests, giving a tester the ability to execute tests manually with minimal—but invaluable—information.

Test cases define how a particular story could be used from an end-user’s perspective, and they are used to confirm when a story is complete and working as intended. They establish the boundaries of a story’s scope and the definition of done.

Lightweight test cases needn’t consist of more than a brief description of what needs to be tested. A clear and simple statement is the goal, with no detailed steps or expected results. In this regard, less is more because lightweight test cases generally won’t need to be revised as technical details shift throughout development.

Other benefits of lightweight test cases include:

• A reduced number of test cases
• Less time spent on test case design and maintenance
• Emphasis placed only on work that adds value to the end product

Agile teams using Jira to plan and track software development oftentimes struggle to manage acceptance tests since Jira doesn’t support them natively. Adaptavist’s Test Management for Jira (TM4J) is a full-featured test management app that seamlessly integrates with Jira and unlocks lightweight test case design right out of the box. TM4J sits on top of Jira and runs natively so testers and developers can work closely together to design and execute test cases directly from agile and kanban boards.

Light and Fast Strategy #2: Behaviour-Driven Development (BDD)

Behaviour-Driven Development (BDD) is another approach to lightweight test-case design for agile teams. BDD is a story-centric development concept, initially developed by Dan North, that builds upon the conversational and collaborative elements of the Three-C’s method.

BDD defines behaviours of a system through examples in plain text. Agile teams practicing BDD often run special meetings before or early on in a sprint in which developers, testers, and domain experts discuss the concrete behaviours of how the system should work. These concrete behaviors are called examples. The goal of the BDD approach is to solidify the shared understanding of the development efforts and to minimize the risk for rework at later stages.

To clearly communicate desired behaviours for all involved parties, test case descriptions (or examples) should contain realistic data, not abstract jargon. The approach aims to avoid misunderstandings and waste while simultaneously giving non-technical users an opportunity to express thoughts and ideas in the shared common language.

A plain-text structured language called Gherkin is often used to design BDD test cases. It is incredibly basic but has just enough structure to make it useful for developers. Gherkin’s format has Given, When, Then, And, and But elements to illustrate behaviours of the system or functionalities with example data, including pre/post-conditions. It simultaneously specifies user stories while identifying acceptance tests, thereby streamlining requirement discovery and test case design.

Adaptavist’s Test Management for Jira (TM4J) supports BDD with Cucumber and a host of other Gherkin-compatible tools used to write acceptance tests. TM4J helps teams build a shared understanding around acceptance tests within Jira.

When concisely written, these tests help development teams avoid ambiguity and rework, ensure all scenarios are accounted for, and help establish that all user stories are complete. If you’re interested in learning more about the topic, check our our guide to BDD in Jira here.

Closing thoughts

100% of successful agile teams eventually learn this important lesson: testing is not a separate stage of development, but an integral part of the software development lifecycle.

With new code being pushed daily (or even hourly!), the changes that teams need to test are constantly moving targets. Designing lightweight test cases allow testers to respond faster to changed requirements and streamlines the entire testing process. Test cases that are easy to understand aids clear team communication and ensures that the delivered software is exactly what the end-user expects and needs. Improved communication between developers, testers, and domain experts simplifies the development process, meaning less bureaucracy, more time to code, and faster delivery.

Want to learn more about agile testing inside Jira? Come chat with us at booth #11 at the EuroSTAR Testing Expo.

– – – – – – – – – – – – – – — – – – – – – – – – – – – – – – – – — – – – – – — – – – – – – – – – –

Author: Cristiano Caetano

Cristiano is a Product Manager lead at Adaptavist, one of Atlassian’s leading global Platinum Solution Partners.

He is interestested in all things agile, digital transformation, and helping companies build better software. He shares his thoughts on these topics and more on the Adaptavist blog.