Test Modeling: Solving Challenges in Behavior-Driven Development

In behavior-driven development (BDD), functionality needs to match intent, and tests need to match requirements. Learn seven reasons why it’s important to employ test modeling. Find out how to test smart and true with a new model-based approach that aligns tests with requirements, and scales at the speed of Agile.

BDD has changed today’s software development landscape so that requirements are correctly translated into the tests that evaluate the quality of code written. Tests are tightly interwoven with requirements captured from user stories, with an emphasis on validating requirements to be tested well before writing functional code.

End-to-End Collaboration When Testing in BDD

Establishing clear requirements before coding ensures quality is built into applications from the start. Developers write code good enough to pass every in-sprint test, rather than testing code after the fact. This constant refactoring of code to tests accumulates, ensuring that clean code is built up over time. For effective requirements-based testing to work, important discussions need to be held upfront to get everyone on the same page—whether they work on the business side of the organization or in testing or development. If this shared understanding between technical and nontechnical stakeholders is less than crystal clear, then Agile teams will end up with lots of rework and high technical debt.

Businesses need to address the inevitable communication challenges that crop up when technical and nontechnical stakeholders discuss how an application should perform. Teams need to be able to collaborate and to develop narrative user stories and scenarios that describe the who, the what, and the various when-then conditions for how the application will work. The output of these discussions defines test requirements and executable code to be developed.  Specifically, teams need to know if they have moved through all possible test cases systematically for an optimal set of test cases—clearly and unambiguously capturing all logical variations for maximum test coverage. Adding to this complexity are the hundreds of thousands of tests created manually today, making maintenance a nightmare as requirements change.

Clearly, it’s time to move from words to pictures for teams to manage developing to requirements with a model-based testing tool.  

Seven Key Considerations for Model-Based Testing

When taking a model-based approach to building application requirements that is tooled for today’s fast-paced development environments, development teams need to keep these seven key considerations in mind:

1. Single source of truth. When using a model-based approach, collaboration must be made simple. Everyone on the team should be able to visualize how they want users to experience an application and to determine what they want to happen when certain actions are taken. There is a shared understanding across the business, development and quality assurance teams.
2. Better requirements definitions. When doing test modeling, work smart by creating a visual roadmap for how users will move through the application. That means teams are less likely to miss an important requirement and more likely to test where it matters for more thorough test coverage. Teams “test right” based on actual requirements.
3. Optimized for testing in-sprint.  The visual models and automation in model-based testing should help development teams work faster—testing code the moment it is created. Teams can generate optimal test cases and automation scripts direct from requirements—streamlining Agile releases while eliminating the endless iterations previously needed to clarify ambiguity and to get everyone in sync. Teams can fail faster for more immediate feedback in-sprint, while reducing loads on the test environment for better resource utilization.
4. Test design automation. Teams should be able to simply make the appropriate menu selections, define the tests to be automatically generated, and enjoy easy test case maintenance. Manually parameterizing data values in tests for code changes before replaying tests in an automated fashion is not test design automation. In model-based testing, teams just focus on keeping their models up to date. All requirements and tests are updated automatically in lock step as changes are made, while maintaining requirements traceability across the entire development and testing lifecycle.
5. 100% test coverage. Test modeling should automatically generate the smallest number of test cases to achieve 100 percent coverage for development teams. They can avoid wasteful redundancy and costly gaps through clear dependency visualization that aids in capacity planning and in decision making during Agile planning.
6. Share, reuse test assets. Teams should be able to tailor their test coverage based on what they are trying to do in their model-based testing approach. That includes easily importing test cases, removing duplicates and sharing optimized test cases using existing application lifecycle management tools such as Rally, Micro Focus ALM/Quality Center, Jira, and more. Store, share, and reuse test cases and other test assets in a central repository so teams can quickly recreate and execute tests and put applications through the paces as they evolve.    
7. Continuous test feedback.Teams should be able to manage for the impact of requirements changes and to prioritize what needs to be tested. Continuous test feedback that’s anchored in visibility and traceability helps maintain the validity of the test designs used. In model-based testing, teams should be able to layer on reporting tools like Serenity to generate rich test reports that are simple enough for a business analyst with no technical background to understand. This allows teams to drill down and see screen shots of every step, and easily monitor if something goes wrong. 

By addressing the seven considerations above, teams can do more effective test modeling, so they can keep pace with the speed of Agile development—testing smart and at scale while truly in sprint.