Moving forwards with V-Model

I recently worked with a VP of Quality Assurance.  His system needed high quality: it transported 10s if not 100s of Millions of CHF every day. It had to work and the consequences of it not working were horrendously expensive! He genuinely believed in the V-Model. Introducing the V-Model had substantially improved the quality of the system. His QA department was the last guardrail before the cliff.

In retrospect, I am not sure if his inspiration was the German government V-Modell, or the more general V Model.  In any case, the developers wanted to do Scrum and he wanted to preserve the essential aspects of the V Model which had enabled the level of quality they had achieved. How can he do that while moving forward in a Scrum context?

For him, three facets of the V Model were essential:

1. Tester and developer roles should be separated (“4 eyes principle”)
2. Requirements should be matched with Acceptance tests
3. A quality gate between QA and Production is essential to prevent poor quality code from entering service.

Applying the V Model mapped naturally to their organizational structure (roughly: Business, SW-Dev, QA, Production). This had improved the software from where it had been previously, but had caused substantial rivalry between the organizations, especially between Dev & QA:

A development manager was fond of telling people “75% of the time spent in the QA phase is not a about fixing bugs, but agreeing on the right version of the spec, the right interpretation of the spec, the right test data, etc. Most ‘findings’ aren’t really findings, but misunderstandings.”

The test manager responded: ‘3/4ths of the genuine findings do not get fixed before the system goes into production.’ 

Both of these statements were correct. How can you fix this the problem? The short answer is for the stakeholders to agree on the acceptance tests before the developer starts to write the code. This is what Scrum helps you do.

Separation of tester from developer role

An side-effect of having a QA department do acceptance testing is that the Business people who defined the requirements are not the necessarily the people accepting the results (until it is put into production). So the tester has to interpret the spec — possibly, but not necessarily the same spec that the developer is working to — and this leads to differing interpretations. Who knows the answer? The customer, user or stakeholder: “Business.”

Scrum does not say how to test. It does say that 1) Product Owner represents the interests of all the stakeholders (and is free to involve them directly when appropriate), 2) the Team has all the skills necessary to get to Done — which surely includes analysis, coding and testing, and may include other skills, 3) that the Team is responsible for the Quality of its work, and 4) that the Product Owner and Implementation team must agree on a Definition of Done to ensure the quality of each feature as it is produced.

This definition often includes some form of pairing, e.g. Design Review, Code Review or Pair Programming or and independent test. Many teams automate the execution of their test suites. The discussions which occur in preparation of and during the sprint ensure all questions related to a feature get raised and captured in some form of acceptance test.

So adhering to the “4-eye principle” is ensured explicitly by the planning process and strengthened through the definition of done.

Requirements should be matched with Acceptance tests

The latest version of the V-Modell (“XT”) was developed in 1997 and it has not been updated since. Therefore modern thinking about ‘test-first’ strategies, such as Test Driven Development, has not been incorporated into the V-Modell.

In Scrum, every entry on the Product Backlog represents a requirement and either is, or can be mapped to, an acceptance test. The corresponding acceptance test(s) are defined no later than the Sprint Planning Meeting, and probably somewhat earlier. The definition is moved to the front of the process, and the developers have a fixed target to work toward.

Quality gate between QA and Production

The Definition of Done is in essence an internal quality gate for the team. It is passed by every function that is completed in every sprint. Teams often include test automation in their definition of done, so that running, tested features in this sprint stay running and testing in future sprints.

I like to compare software production with auto production at this point. When Toyota has finished building a car, they do a quality check to make sure there are no defects. They don’t expect to find any, but they check anyway. Why? Because it will be more expensive to fix it in the field, and they want to prevent the mistake from reoccurring.

In software it should be the same. The initial quality gate in Scrum is the definition of done, which is checked by the team.

So your teams work on improving their quality though automation and test first strategies. The definition of done always includes verifying the that the acceptance tests pass. At each Sprint Review, the Product Owner confirms that the implementation is doing what the stakeholders want.

If the team has achieved the level of quality which is possible through automated testing, then a relatively quick sanity check should be sufficient to ensure the system will work properly in production. There should be no question whether the features will meet the requirements; that has already been verified by the stakeholders themselves. (Actually achieving this level can be a substantial challenge and may take months or years to achieve – in the meantime you will have no choice but to do manual regression or integration tests).

So Scrum addresses all of the key points of his V Model while recognizing the chaotic, creative nature of software development. The organizational structure around the development organization may change, but happy users of the V Model will recognize many of their core principles in Scrum.

Update: Thanks to James Christie for pointing out that there are really two V-Models – the very specific German V-Modell (which was the subject of yesterday’s article) and the vaguer ‘V Model’ which is familiar to most testers. For an excellent article on the history and context of the V Model(s), see The Dangerous and Seductive V Model.