Test Driven Requirement - A New V-Model


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

500px-Systems_Engineering_Process_II.svg.png

Even when implementing an Agile SDLC, sometimes we still treat this model as an important guidance to some degrees when defining our development/testing activities. We have to admit that those traditional deliverables/documents we’re still using to define the product are widely accepted by those Senior developers and testers who are educated well 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:
Workpiece
Format
Usage
RUP SRS (Software Requirement Specification), or any other Requirement Document
UML Use Cases + natural narratives
Define the product from the end-user perspectives
Functional Test Cases
Test steps + expected results
Define the expected behavior for the product from the end-user perspectives
UI design
Mockups, screenshots
The reference used from both requirement and testing perspectives

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:

Traditional_V_Model_Activities_small.png

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 of being responsible for one area only, and we hate heavy documentations.
In my past experiences I’ve seen numerous times that my Scrum teams got big headaches dealing with requirement/test case documents. They spent comparatively huge effort on 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 requirement understandings even if the two documents look like no gap.
  • The requirement documents never come to detailed enough – we do 3 rounds of review meetings, but after we start the implementation we still find we need more detailed specifications to the requirement.
  • The issues always be exposed in the late minute – when system testing is performed and bugs are raised the teams start to argue whether or not the implementation aligns to the requirement.
  • It’s almost impossible to maintain the requirement documents and the test cases update to date – some details are described in e-mails, wikis, phone calls, or Jira tickets, while our test cases have to be up-to-date on a regular basis. It’s very hard to trace back those detailed requirement/requirement changes after 3 or 4 sprints.
We started to think about how we deal with that kind of headaches. Once our friend Ken McCorkell introduced the “Test Case Driven Requirement” to one of our projects, this approach allows using Functional Test Cases directly to represent the requirement, and use that as the only required documents for both Development and the Testing teams. That sounds really interesting to us, because we realized that from the developer/tester perspective, the test cases actually are having the same usage as the requirement documents, while they’re much more detailed with more information.
We tried that approach in 2 or 3 projects (some are even big projects with complex requirements), and now we’re feeling that approach could be a good option to the Scrum teams if we want to escape from heavy documentations.
  • In one of my past project, 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 define new User Acceptance Test Case format, make it suitable to describe the typical behaviors of one User Story.
  • We build up a hierarchical structure between User Acceptance Test Cases and Functional Test Cases: we add multiple Functional Tests under one UAT to cover all the major flows and the alternative flows.
  • The developers work together with the testers to refine every Functional Test Cases; they add more detailed specifications until they feel comfortable to start the development, the both two teams work together to maintain those Functional Test Cases since that has become the new unique formal input to the development/testing work.
  • We don’t spent too much time on requirement discussion meetings any more, instead, we talk about detailed, specific questions which can be documented as “test steps” and “expected results”.
And now, by using Test Case Driven Requirement, we came up with a new, more Agile like V-model:

Scrum_V_Model_small.png

A couple of best practices:
  • One “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 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 requirement – 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:

FT.png

We’re still trying to implement this new approach in our organization, mean while I’d like to share this idea with anybody who is interested. We invite you to try this in your project, and let us know the feedback so that we make improvements together.