What about the V-Model?

The V-Model for Software Development specifies 4 kinds of testing:

  • Unit Testing
  • Integration Testing
  • System Testing
  • Acceptance Testing

What I’m finding is that of those only the Unit Testing is clear to me. The other kinds maybe good phases in a project, but for test design it doesn’t help much. It is hard to say which tests should go in a system test, an integration test or an acceptance test.

In Action Based Testing(tm) (ABT) we have a concept called “test modules”, that I feel can work much better. A test module is a collection of tests with similar scope, designed to be executed together. In practice the test module is a sheet like document with “actions”: lines specific test actions (and checks), each starting with an “action keyword” (or “action word”), followed by arguments.

In ABT we focus strongly on what we call the high level test design, in which we identify the test modules and groups of test modules. I have written about this in my articles on test design. This process is dependent on the context of the project and the system under test, and can therefore lead to different results in different circumstances. What it typically never leads to is “integration testing”, “system testing” or “acceptance testing”. It will rather be a mix of modules like “user interface tests”, “financial transactions”, “database integrity”, “security”, etc.

Once a list is established, the next step is make a schedule, with for each test module: (1) when to develop the module, and (2) when to execute it. The development scheduling typically depends on availability of specifications. for a mortgage calculation test module this will be early in a project, when the business rules are expect to be available, while for a UI test of a dialog one has to wait until the dialog has been specified in detail. For the execution scheduling generally the order reverses: tests that verify details of the user interaction need to pass before it makes sense to run tests that enter and verify financial transactions.

The result is that the V Model is still visible as a pattern in the sense that tests developed earlier are commonly executed later. However, the traditional interpretation of “integration testing”, “system testing” and “acceptance testing” is not commonly seen, and in particular does not appear to be a good starting point for the test development planning.

You can find more information here (Wikipedia)

Hans Buwalda

Author:  Hans Buwalda, Chief Technical Officer

Hans Buwalda is an internationally recognized expert in test development and testing technology management and a pioneer of keyword-driven test automation. He was the first to present this approach, which is now widely used throughout the testing industry. Originally from The Netherlands, Hans now lives and works in California as CTO of LogiGear Corporation, directing the development of what has become the successful Action Based Testing™ methodology for test automation and its supporting TestArchitect™ toolset. Prior to joining LogiGear, Hans served as project director at CMG (now CGI) in the Netherlands. He is co-author of Integrated Test Design and Automation and a frequent speaker at international conferences.

Facebooktwittergoogle_pluspinterestlinkedinmail

6 thoughts on “What about the V-Model?

  1. I so agree with your post. I too follow a similar model of creating modules. Many a times it confuses me as to where a test should be classified wrt Integration, System or Acceptance testing.
    Btw the links provided in your RSS feed are not working. You might want to “test” that out 🙂

  2. My brother suggested I would possibly like this blog. He used to be totally right. This submit truly made my day. You cann’t imagine simply how so much time I had spent for this info! Thank you!

  3. Hello there, You have performed a great job. I’ll definitely digg it and for my part recommend to my friends. I’m confident they will be benefited from this site.

Comments are closed.