Home arrow Quality arrow Quality Assurance arrow Test Methodology
Test Methodology

The testing process must also be adapted to the needs of the project, and in each case different testing techniques may be applied in various ways.

The definition of the testing process for a specific project is included in the Test Plan and basically consists of the following phases:

  • Analysis of tests
  • Design of tests
  • Performance of tests
  • Appraisal of results and improvements

The test processes applied by Kynetia in projects are based on adaptations and/or combinations of the following models:

  • V Model test process
  • W Model test process
  • Butterfly model test process

V Model test process

The V Model (with V standing for Verification and Validation) is the most widespread, due to its simplicity.

In contrast to classic models, the V Model spreads testing over the whole software life cycle. Illustrations 1 and 2 below show the differences between the processes applied to testing at specific moments and over the software life cycle.
Illustration 1 – Classic test model
Illustration 2 – Life cycle test model

The V model is directly derived from the application of verification and validation tests to the cascade development cycle.

Illustration 3 – V Test Model

This model can be easily extended to other iterative development models, if the V is regarded as a full iteration of the project.

Consequently, a test plan forming part of an iterative development process will evolve in line with the progress of the project through the successive iterations.

This model is quite sufficient in many projects, because it provides for the design of tests in the early stages, which are then executed later in the development cycle.

W Model test process

The W Model is a refinement of the V model. It provides a better reflection of the interdependence between the development team and the test team over the whole course of the system development process, in particular on the following two points:

  • It includes testing work in the early stages that is not reflected in the original model, such as the review of requirements, review of system specifications, review of architecture and detailed design, and code reviews.
  • It also differs from the original V model in the later stages, where testing tasks as such as broken down and separated from the work of debugging and error correction, which is performed by the developers.
Ilustración 4 - Modelo de Pruebas en W

In the above chart of the W model, testing tasks are shown in green. The blue blocks represent other activities in the software life cycle prior to the production launch. The verification of non-software products and tasks related with preparation for the verification and validation of software are concentrated in the early stages. In the late stages of the processes, the work focuses entirely on verification and validation of the software produced.

From the standpoint of the test team, we may distinguish two types of activity:

  • Tests on no-software products
    • Requirements review
    • Use case specification review
    • Architecture design review
    • Detailed design review
  • Software tests
    • Preparation of acceptance tests
    • Preparation of system tests
    • Preparation of sub-system integration tests
    • Preparation of unit tests
    • Code reviews
    • Performance of tests
    • Debugging and introduction of changes

Verification and Validation tests for non-software products

These tests cover the majority of products taking the form of documents. The number of “non-software” products tested will depend on the characteristics of the project.

These tests are based on peer reviews and do not necessarily involve test personnel. The documents are subjected to a review process as established in the project quality assurance plan, which defines who is responsible for the review (normally people having at least the same level of technical qualifications as the author of the document, and sometimes the client), how weaknesses should be corrected, and how the document is approved for use in subsequent stages of the development cycle.

Butterfly Model for software testing

This model concentrates on the verification and validation of software products, and it therefore provides a perfect fit with the software testing tasks forming part of both the V and the W model. It focuses more on detail and provides an even more accurate reflection than the W model of the complexity of interaction between the development and test teams.

The model provides a graphic picture of the complexity of the tasks required. This is done using a butterfly. The areas occupied by the wings and body are approximately related to the level of effort afforded to each of the activities included in the model. The use of the butterfly stems from Chaos theory, which states that a minute perturbation in part of a system (the flight of a butterfly in Asia) cause a huge perturbation in some other part of the system (a hurricane in Europe). The development of a software system has certain similarities. Small modifications or errors in the code may result in absolutely abnormal performance.

Illustration 5 – Butterfly Test Model

The model establishes three groups of activities, which wee include in the test plan. In terms of their importance, the areas reflected in the graphic are:

  • Test Analysis (butterfly’s left wing)
  • Test Design (right wing)
  • Performance of tests (butterfly’s body)