What About the V-Model?

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

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

You can find more information here (Wikipedia):


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.

LogiGear Corporation
LogiGear Corporation provides global solutions for software testing, and offers public and corporate software testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast, cost-effective results. Since 1994, LogiGear has worked with Fortune 500 companies to early-stage start-ups in, creating unique solutions to meet their clients’ needs. With facilities in the US and Viet Nam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

The Related Post

This is an adaptation of a presentation entitled Software Testing 3.0 given by Hung Nguyen, LogiGear CEO, President, and Founder. The presentation was given as the keynote at the Spring 2007 STPCON conference in San Mateo, California. Watch for an upcoming whitepaper based on this topic. Introduction This first article of this two article series ...
There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing. There are situations, such as in testing mobile applications, complex systems and cyber security, where tests need to be creative, cover a lot of functionality, ...
The 12 Do’s and Don’ts of Test Automation When I started my career as a Software Tester a decade ago, Test Automation was viewed with some skepticism.
Introduction Software Testing 3.0 is a strategic end-to-end framework for change based upon a strategy to drive testing activities, tool selection, and people development that finally delivers on the promise of Software Testing. For more details on the evolution of Software Testing and Software Testing 3.0 see: The Early Evolution of Software Testing Software Testing ...
Introduction This article discusses the all-too-common occurrence of the time needed to perform Software Testing being short changed as specification, development, and unforeseen “issues” cause the phases prior to testing to expand. The result is that extreme pressure is placed upon the testing organization to perform the testing function within a reduced time frame. The ...
In today’s mobile-first world, a good app is important, meaning an effective Mobile Testing strategy is  essential.  
Regardless of the method you choose, simply spending some time thinking about good test design before writing the first test case will have a very high payback down the line, both in the quality and the efficiency of the tests. Test design is the single biggest contributor to success in software testing and its also ...
Karen N. Johnson began as a technical writer in 1985 and later switched to software testing in 1992. She maintains a blog at TestingReflections, a collaborative site where she is featured as a main contributor. In her latest entry, she discusses search testing with different languages. Here is an excerpt from her blog: “I started ...
Do testers have to write code? For years, whenever someone asked me if I thought testers had to know how to write code, I’ve responded: “Of course not.” The way I see it, test automation is inherently a programming activity. Anyone tasked with automating tests should know how to program. But not all testers are ...
Introduction Keyword-driven methodologies like Action Based Testing (ABT) are usually considered to be an Automation technique. They are commonly positioned as an advanced and practical alternative to other techniques like to “record & playback” or “scripting”.
At VISTACON 2011, Jane sat down with LogiGear Sr. VP, Michael Hackett, to discuss complex systems.
When You’re Out to Fix Bottlenecks, Be Sure You’re Able to Distinguish Them From System Failures and Slow Spots Bottlenecks are likely to be lurking in your application. Here’s how you as a performance tester can find them. This article first appeared in Software Test & Performance, May 2005. So you found an odd pattern ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news