Explore the Importance of Validation Testing:
Table of Contents:
What is Validation Testing?
Validation testing is the process of ensuring that the tested and developed software satisfies the client /user’s needs. The business requirement logic or scenarios have to be tested in detail. All the critical functionalities of an application must be tested here.
As a tester, it is always important to know how to verify the business logic or scenarios that are given to you. One such method that helps in detailed evaluation of the functionalities is the Validation Process.
Whenever you are asked to perform a validation test, it takes great responsibility as you need to test all the critical business requirements based on the user’s needs. There should not be even a single miss on the requirements asked by the user. Hence a keen knowledge of validation testing is much important.
As a tester, you need to evaluate if the test execution results comply with what is mentioned in the requirements document. Any deviation should be reported immediately and that deviation is thus called a bug.
Tools like HP Quality Centre, Selenium, Appium, etc are used to perform validation tests and we can store the test results there. A proper test plan, test execution runs, defect reports, reports & metrics are the important deliverables to be submitted.
From a company perspective, the validation test in simple is carried out by the following steps:
- You gather the business requirements for validation testing from the end user.
- Prepare the business plan and send it for approval to the onsite/stakeholders involved.
- On approval of the plan, you begin to write the necessary test cases and send them for approval.
- Once approved you begin to complete testing with the required software, and environment and send the deliverables as requested by the client.
- Upon approval of the deliverables, UAT testing is done by the client.
- After that, the software goes into production.
Let us now explore more about validation in detail.
Difference Between Verification and Validation
Let us understand these with an example in a simple way.
Example:
Client Requirement:
The proposed injection should not weigh above 2 cms.
Verification Test:
- Check if the injection is an injection that does not weigh above 2 cms by using a checklist, review, and design.
Validation Test:
- Check if the injection does not weigh above 2 cms by using manual or automation testing.
- You have to check each and every possible scenario pertaining to the injection weight by using any suitable method of testing (functional and non-functional methods).
- Check for measurements less than 2 cm and above 2 cm.
| Verification | Validation |
|---|---|
| The process just checks the design, code and program. | It should evaluate the entire product including the code. |
| Reviews, walkthroughs, inspections, and desk- checking involved. | Functional and non functional methods of testing are involved . In depth check of the product is done. |
| It checks the software with specification. | It checks if the software meets the user needs. |
Stages Involved
- Design Qualification: This includes creating the test plan based on the business requirements. All the specifications need to be mentioned clearly.
- Installation Qualification: This includes software installation based on the requirements.
- Operational Qualification: This includes the testing phase based on the User requirement specification.
This may include Functionality testing:
-
- Unit Testing – Black box, White box, Gray box.
- Integration Testing – Top-down, Bottom-up, Big bang.
- System Testing – Sanity, Smoke, and Regression Testing.
- Performance Qualification: UAT(User Acceptance testing) – Alpha and Beta testing.
- Production
Design Qualification
Design qualification simply means that you have to prepare the design of the software in such a way so that it meets the user specifications. Primarily you need to get the User Requirements Specification (URS) document from the client to proceed with the design.
Test Strategy:
This document forms the base for preparing the test plan. It is usually prepared by the team lead or manager of the project. It describes how we are going to proceed to test and achieve the desired target.
To incorporate all the procedures a proper plan should be designed and get approved by the stakeholders. So let us know the components of the test plan.
In a few projects, the test plan and test strategy can be incorporated as a single document. Separate strategy documents are also prepared for a complex project (mostly in automation techniques).
Components of the Validation Test Plan:
- Description of the project
- Understanding the requirements
- Scope of testing
- Testing levels and test schedule
- Run plan creation
- Hardware-software and staffing requirements
- Roles and responsibilities
- Assumption and dependencies
- Risks and mitigation
- Report and Metrics
Description of the Project: Here you need to elucidate all the descriptions of the application bestowed to you for testing. It should include all the functionalities of the app.
Understanding the Requirements: Upon getting the USR, you need to mention the understood requirements from your side. You can also raise clarifications if any. This stands as the base or test criteria for testing.
Scope of Testing: The scope must include the modules in detail along with the features at a high level. You need to tell the client what requirements you would cover in your testing.
From a business perspective, validation testing may be asked to perform for the critical requirements of an application. It simply means that you say what will be covered and what not.
Testing Levels and Test Schedule: You need to mention how many rounds of testing have to be conducted. The overall effort for the testing project is estimated using standard estimation techniques like Test Case Point (TCP) estimation etc.
As the name implies test schedule describes how the testing will be carried out. It should also say how and when the approval, and reviews will be conducted.
Example:
The design of a webpage is the project considered.
Testing levels include:
Level 1: Smoke testing
Level 2: Unit Testing
Level 3: Integration testing
Level 3: System testing
Level 3: Acceptance testing
Test Schedule:
- Plan submission – Day 1
- Design of Test Cases – Day 2
- Dry run and bug fixing – Day 4
- Review- Day 5
- Formal Run – Day 6
- Deliverables sent for approval – Day 8
- Reports – Day 10
Run plan creation: The run plan marks the number of runs required for testing. Every run you perform on the offsite will be noted by the onsite team.
For Example, when you use the HP Quick Test Professional tool for execution, the number of runs will be shown in the Runs tab of the test plan.
Hardware-software and staffing requirements:
- Hardware and software requirements like the devices, browser versions, IOS, and testing tools required for the project.
- Staffing means appointing the persons required for testing. You can mention the team count here.
- In case you need any extra testing members, then you can request onsite depending on the testing scope. Simply when the number of test cases increases, then it implies that you need more team members to execute them.
Roles and Responsibilities: This implies assigning tasks to the related roles responsible for carrying out the various levels of testing.
For Example,
An app needs to be tested by a team comprising of 4 members to execute 4 validation protocols and you can delegate the responsibilities as follows:
- Test Lead: Design of test plan
- Team member 1: Design & execution of protocols 1,2.
- Team member 2: Design & execution of protocols 3,4.
- Team member: Preparation of reports, reviews, and metrics.
Assumption and Dependencies: This means that the assumptions made during design and dependencies identified for testing will be included here.
Risks and Mitigation: Risks related to the test planning such as availability of the desired environments, build, etc along with mitigation and contingency plans.
Report and Metrics: Factors that were used for testing and reports to the stakeholders have to be mentioned here.
An Example of a mobile app is provided below:
Installation Qualification
- Installation qualification contains details like which and how many test environments would be used, what access level is required for the testers in each environment along with the test data required. It may include browser compatibility, tools required for execution, devices required for testing, etc. The system being developed should be installed in accordance with user requirements.
- Test data may be required for testing some applications and it needs to be given by the proper person. It is a vital pre-requisite.
- Some applications may require a database. We have to keep all data required for testing ready in a database to validate the specifications.
For Example, A new app that says “abc” has to be tested in mobile (Android 4.3.1) and browser (Chrome 54), in such a case, we have to keep track of the following:
- Check if proper authorization is given to check the site of the app “abc”.
- See if the devices used for testing the app like mobile (android /ios), browser-Chrome, and Internet Explorer with the required version are available.
- Check if those are installed correctly with the specified versions (Eg: Chrome 54, Android version 4.3.1).
- Make sure the app is accessible in both the browser and mobile.
Operational Qualification
Operational qualification ensures that every module and sub-module designed for the application under test functions properly as it is expected to in the desired environment.
Validation testing, in general, is carried out in the following hierarchy.
Functional testing plays a major role in validation testing. It simply means that you have to validate the functionality of the application by each and every critical requirement mentioned. This paves the way to map the requirements mentioned in the Functional Specification document and ensures that the product meets all the requirements mentioned.
Functional Testing and its Types
As the name suggests, functional testing is testing the functions i.e. what the software has to do. The functionalities of the software will be defined in the requirement specification document.
Let’s have a quick glance at its types.
#1) Unit Testing:
Unit testing is testing the individual units/modules/components/methods of the given system. The field validation, layout control, design, etc., are tested with different inputs after coding. Each line of the code should be validated for the individual unit test cases.
Unit testing is done by the developers themselves. The cost of fixing bugs is less here when compared to the other levels of testing.
Example:
Evaluating a loop of the code for a function say gender choice is an example of unit testing.
#2) Black Box Testing:
Testing the behavior of an application for the desired functionalities against the requirements without focusing on the internal details of the system is called Black box testing. It is usually performed by an independent testing team or the end users of the application.
The application is tested with relevant inputs and is tested to validate if the system behaves as desired. This can be used to test both the functional as well as non-functional requirements.
#3) White Box Testing:
White box testing is nothing but a detailed checking of the program code by code. The entire working of the application depends on the code written, hence it is necessary to test the code very carefully. You need to check every unit and its integration as a whole module in a step-by-step way.
A tester with programming knowledge is a must criterion here. This clearly finds out if there is any deviation in the workflow of the application. It is useful for both the developers as well as testers.
#4) Gray Box Testing:
Gray box testing is a combination of both white box and black box testing. Partial knowledge about the structure or the code of the unit to be tested is known here.
Integration Testing and its Types
The individual components of the software that are already tested in unit testing are integrated and tested together to test their functionalities as a whole, in order to ensure data flow across the modules.
This is done by the developers themselves or by an independent testing team. This can be done after two or more units are tested.
Top-down Approach:
In this approach, the top units are tested first, and then the lower level units are tested one by one stepwise. Test stubs that may be used are required to simulate the lower-level units that may not be available during the initial phases.
Bottom-up Approach:
In this approach, the bottom units are tested first, integrated, and then the higher level units are tested. Test stubs that may be used are required to simulate the higher-level units that may not be available during the initial phases.
System Testing and its Types
Testing the complete system/software is called system testing. The system is tested completely against the functional requirement specifications. System testing is done against both the functional and non-functional requirements. Black box testing is generally preferred for this type of testing.
#1) Smoke Testing:
When the builders give the build to test initially, we have to test the build thoroughly. This is called smoke testing. We need to state if the build is capable of further testing or not.
In order to perform validation, you need a proper build. Hence smoke testing is firstly done by the testing team. The workflow of the application tested should be tested either with the test cases or without it. A test case covering the entire flow is helpful for this testing.
#2) Sanity Testing:
In sanity testing, the main functionalities of the modules of the application under test are tested. In testing a website that has 3 tabs i.e. profile creation, education, login, etc., in IRCTC, the main functionalities of all these tabs have to be checked without going very deeper.
The menus, sub-menus, and tabs have to be tested in all modules. It is a subset of regression testing as testing is done only of the main flow and not in depth.
#3) Regression Testing:
For every release of the project, the development team may introduce certain changes. Validating if the new changes introduced have not affected the working flow of the system is called Regression testing. Only certain test cases pertaining to the new requirements have to be tested here.
Performance Qualification
UAT (User Acceptance Testing):
This is the last phase of testing that is done to ensure that the system behaves as required corresponding to the specified requirements. This is done by the client. Once the client certifies and clears system testing, the product can go for deployment.
Alpha and Beta Testing:
Alpha testing is done by the developers on the application before release at the software development site. It involves black and white box testing. Beta testing is done on the customer side after the product is developed and deployed.
Sample Validation Test Cases or Protocol
With my experience, I have written this protocol for Gmail login.
An in-depth check of the login functionality covered is what validation actually is. But I would like to mention that the style of sentence columns used may completely differ and depend on the client’s requirements.
=> Download Sample Validation test Cases: Gmail login test case
Conclusion
Well, validation is all about analyzing the functionalities of a product in detail. As a validation tester, you must always remember to report the deviations then and there in order to obtain optimum results in testing.
Every test case that is written should be sharp, concise, and understandable even to the common man. The validation tester should ensure that the right product is being developed against the specified requirements.
As a guide for validation testing, I have covered the process associated with validation.
Design qualification involves the validation plan, Installation qualification that talks about the hardware-software installment, Operational qualification that involves the entire system testing, and Performance qualification that involves the user acceptance testing which provides the authorization for production.
Hope this article would have enriched your knowledge of the concept of Validation Testing!!