V Testing Model

Testing following the Development Process

The level of testing required for a system varies from project to project, however the steps for testing follow the the way the system has been designed and built. Conventually this is known as the “V Model”, which maps the types of tests to each stage of the development.

Component Testing

Starting from the bottom the first level is “Component Testing”, sometimes referred to as “Unit Testing”. In theory an independent tester should perform the testing for this stage, but in practice this is normally completed by the developer. The components are such a small part of the system when they are running on there own & normally only complete one specific process. The testing of these components is normally within an isolated environment performed by the developer as they complete the development and confirm the component works. This is not the preferred practice but often the reality.

Interface Testing

As the components are constructed they can be linked together to check if they work with each other. Interface testing is not focussed on what the components are doing but on how they communicate with each other. The Interface testing is linked to the System Design as it defines the relationship between the components. This involves stating :

1. What a component can expect from another component in terms of data format, content, size, frequency, “Service”

2. How to handle nonstandard conditions, i.e errors.

The tests are organized to complete all the interface testing, completing the data ‘flow’ from the first components interface through to the final component. Each interface test is performed and verified independently from other interfaces.  

System Testing

System testing is the first time the entire system is available to be tested as a whole. Confirming functionality and information flow of data through each part of the system. The testing must meet the “System Specifications” and although still developer focussed the testing is completed by specialized developers known as system testers.

System Testing can involve a number of specialized types of tests to check Performance, Volume, Stress, Limit and Documentation.

    Performance - Are the performance criteria’s met?

    Volume - Can the larges of anticipated volumes of information be handled ?

    Stress - Can peak volumes of information be handled and how is the performance impacted at these times.?

    Limit - Testing the system to break point, confirming when, where and how the system will break and what is required to restore it. This testing should also confirm certain disaster recovery requirements detailed within the system specifications.

    Documentation - Is the documentation useable for the system ?

Acceptance Testing ( UAT )

Acceptance testing checks the system against the “Requirements”. It is similar to the system testing in that the whole system is checked, but the important difference is the change in focus.

    System Testing checks that the system which was specified has been delivered.

    Acceptance Testing checks that the system delivers what was requested.

Acceptance testing looks to confirm that the new software and system delivers and performs what the business requires. The best people to decide if the requirements have been met are the real business users who have been using the old system on a day to day basis. This is why this phase of the testing is normally referred to as User Acceptance Testing or UAT.

UAT is known under many different names depending on the company or people you work with. During my career within testing I have heard it called “Beta testing, QA testing, Application testing, End user testing and even Model office testing. Often users do not have the time or the understanding to complete UAT and specialized testers are employed to liaise between the users and the system specialist. This, along with system testing has been predominately my position within many companies.

The concept of User Acceptance Testing is to use the system as the users would, including every process and functionality that the users would use. These are the easy to identify functionality’s, and the users are best used to complete or identify these tasks. The system has been designed specifically to complete these tasks and normally a well developed system will stand up and look good with this type of testing. The specialist areas of UAT come with performing the tasks which the users will do but the system was not designed for. These areas of defects are the ones specialist experience testers will identify and test for. A few examples of the type of defect which are discovered may explain this clearer.

  • A HR system required that a user logged in with user id and password, it was discovered that if the user entered the number 0 within the password the system allowed the user access as long as the id was correct.
  • A very well known online web site which sold books as one of their main products,  released software for end users which included credit card transactions. The general concept of the site was that the user would select a book, enter the quantity of units they required and their credit card was approved and payment was made. It was discovered after the release that if a user entered a negative quantity then the credit card would be credited rather than debited.
  • A time and expense system allowed the user to give an explanation for the expense within a narrative box. The anticipated text length from the business was not specified within the design documentation, however upon discussion it was agreed that a brief explanation consisting of less than 120 characters was what was expected. Further to UAT it was discovered that the narrative field populated an Oracle database field which was restricted to 255 characters. If an expense was submitted with more than 255 characters not only did the expense reports crash during submission but it also froze the users machine forcing a reboot.  As a resolution to the defect code was written before release advising if the narrative box contained more than 255 characters and forced the user to remove some of the text. Within 3 months and only half way through the system roll out, the business users requested the narrative size to be increased to a 1000 characters

Release Testing

Even if a system meets all the requirements, there is still the case to be answered that, will the new system benefit the business and meet the initial business case.

Release Testing identifies if the new or change system will work in the existing business environment. Mainly this means the technical environment and checks concerns such as :

    Does the new system effect any other system

    Is it compatible with other systems

These tests are normally run by the operation team within a business and their opinion to the impact of the system should have been asked during the Business Case stage. They would have identified new hardware if it was required and ongoing costs can now be confirmed and maintenance processes finalized.


www.Surfersjunkyard.com contact me on admin@surfersjunkyard.com