Test Case Driven Requirement – A New V-Model

We’ve been very familiar with the traditional V-model like below:

Even when implementing an Agile SDLC, sometimes we still treat this model as an important  guidance to some degree when defining our development/testing activities. We have to admit that the traditional deliverables/documents used to define the product are still widely accepted by senior developers and testers who have been educated and acclimated to UML and RUP. It’s very normal for a Scrum team to be using Requirement Specification documents and Test Cases as the required workpiece to drive the corresponding programming and testing work separately.

I’ve seen the below documents/format are used in several different projects:

Usually,  the SRS or Requirement Document are used as the unique official input for both development and testing teams for the technical design/implementation and the test case design/test execution work. Let’s take a look at what we usually do when using the traditional V-model:

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

That approach is not agile enough. In a Scrum process we have very short period of time to get all the things done, we deal with a lot of changes sprint by sprint, our teams are not so functional –i.e. not responsible for only one area or role, and we hate unnecessary heavy documentation.

In my past experiences I’ve seen numerous times that my Scrum teams got a big headache from dealing with requirement/test case documents. They spent comparatively huge effort synchronizing the 2 important documents: SRS (or Requirement Document), and Test Cases.

• We host long reviewing meetings trying to address all the mismatches between the test cases and the requirements.
• It’s normal for the testing team and the development team to have different understanding of the requirements even if there is no gap between the documents.
• The requirement documents are never detailed enough – we do 3 rounds of review meetings, but after we start the implementation we still find we need more detailed specifications for the requirement.
• Issues are always exposed at the last minute – when system testing is performed and bugs are raised the teams start to argue whether or not the implementation aligns with the requirement.
• It’s almost impossible to keep the requirement documents and the test cases up-to-date – some details are described in e-mails, wikis, phone calls, or issue tickets, and test cases have to be up-to-date on a regular basis. It’s very hard to trace these back to detailed requirement/requirement changes after 3 or 4 sprints.

We started to think about how we deal with these kind of headaches. Once our friend Ken McCorkell introduced the “Test Case Driven Requirements” to one of our projects. This approach allows using Functional Test Cases to directly represent the requirement, and use that representation as the only required documents for both the development and testing teams. That sounds really interesting to us because we realized that from the developer/tester perspective the test cases actually have the same objective as the requirement documents but are usually much more detailed with more information.

We’ve tried this approach in 2 or 3 projects (including big projects with complex requirements), and now we’re feeling that this approach could be a good option to the Scrum teams if we want to escape from heavy documentation.

• In one of my past projects, we were still using requirement document in Use Case format, but it stays at a high level only figuring out the business value and the most important business rules.
• We defined a new User Acceptance Test Case format, making it suitable to describe the typical behaviors of one User Story.
• We build up a hierarchical structure between User Acceptance Test (UAT) Cases and Functional Test Cases: we added multiple Functional Tests under one UAT to cover all the major flows and alternative flows.
• The developers worked together with the testers to refine every Functional Test Case; they added more detailed specifications until they felt comfortable to start development. Both teams worked together to maintain the Functional Test Cases since that became the new unique formal input to the development/testing work.
• We don’t spent too much time in requirement meetings any more. Instead we talk about detailed and specific questions which were documented as “test steps” and “expected results”.

Using Test Case Driven Requirement, we came up with a new, more Agile like V-model:

A couple of best practices:

• An “Integrated Development and QA team” is the key of using this model successfully. Please refer to my previous posts on how that team model works in the “Implementation” box on the above diagram.
• We can still use a traditional format to describe the requirement. The difference is that we leave that document in a high level and put the details into our Functional Test Cases.
• We’ll have two levels of Functional Test Cases to represent requirements – the UAT Case could be a User Story level document defining all the main flows and alternative flows, while the Functional Test Cases figures out the details for each flow. Below is one simple example for the UAT case format:

We’re still trying to implement this new approach in our projects, in the meanwhile I’d like to share this idea with anybody who is interested. We invite you to try this on your project and share your results and feedback so that we make improvements together.