6 July 2007

The V-Model: Test and Verify on the way out

Once the actual development has been done you want to test it to make sure it meets specifications. Again the maths of picking up defects early applies. The earlier you find an error the easier it is to fix.

It seems to me that this is one of the strengths of an agile development approach; you are putting functional components into production or at least a test space as early as you can so you can pick up problems. Regardless of the method the principle still applies.

The phases in the V-model cycle are listed below, but there are other labels and other types of testing. The nice thing about the V-model is that each level of testing can be reconciled back to a design stage. So, for example user acceptance testing becomes a way of checking off whether business requirements have been met, just as interface testing can test whether the system design got things right.

V-Model Testing phases

  • Component testing
  • Interface testing
  • System testing
  • User acceptance testing
  • Release testing
I am not going to break down test activities and their details here. If you want that level of information I recommend you Craig Borysowich’s blog at IT Toolbox for a very detailed run down on test activities. Instead let me focus on the ways a business analyst would interact with each of these test activities.

The business analysts role in this phase of the development lifecycle is to act as an assessor and communicator. Your role is to understand what the testers are doing, what results they get and to be able to clearly explain what that means to business stakeholders.

Things to consider include;
  • When you don’t understand what is in the test plan; ask the test manager or developer to explain it.
  • When you think you see gaps in the planning; raise the issue until you are satisfied; these are your requirements that are being serviced after all.
  • When there are bugs or problems; understand them in the context of the full solution before raising the alarm, but if things are really not working, let people know.

You can manage bugs like you manage project issues and risks; they should be clearly articulated and have an owner, an action plan and a deadline. If you don’t time box a problem it can have an impact n the whole project schedule. If problems aren’t resolved by a deadline it’s a flag to escalate the problem to a new level.

Many business analysts are also heavily involved in user acceptance testing (UAT). Business analysts (and other types of requirements managers) should be involved in UAT so that they have a detailed and thorough understanding of both the validation process and the useability of new systems and processes. By participating fully in this activity you can identify poorly built aspects of the system and areas where the business processes need to be enhanced.

You also deepen your subject matter expertise in the solution, which is useful for the change management work that comes at the implementation phase of the project.

1 comment: