Explore the Importance of Validation Testing:
What You Will Learn:
- What is Validation Testing?
- Difference Between Verification and Validation
- Stages Involved
- Sample Validation Test Cases or Protocol
- Recommended Reading
What is Validation Testing?
Validation testing is the process of ensuring if the tested and developed software satisfies the client /user 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 detail evaluation of the functionalities is the Validation Process.
Whenever you are asked to perform a validation test, it takes a great responsibility as you need to test all the critical business requirements based on the user needs. There should not be even a single miss on the requirements asked by the user. Hence a keen knowledge on validation testing is much important.
As a tester, you need to evaluate if the test execution results comply with that 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 test 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 the 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, 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 for 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.
The proposed injection should not weigh above 2 cms.
- Check if the injection is the injection that does not weigh above 2 cms by using checklist, review, and design.
- 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 cms.
|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.|
- 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 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.
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.
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, 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 technique).
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 description 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 all 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 the 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.
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
- 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 in 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, 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 the various levels of testing.
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, review, 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 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 says “abc” has to be tested in mobile (Android 4.3.1) and browser (Chrome 54), in such a case, we have to keep a 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, Internet Explorer with required version are available.
- Check if those are installed correctly with the specified versions (Eg: Chrome 54, Android version 4.3.1).
- Make sure if the app is accessible in both the browser and mobile.
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.
A 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 of 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 to 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.
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 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.
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.
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. 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, 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 as Regression testing. Only certain test cases pertaining to the new requirements have to be tested here.
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 at 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.
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 requirements.
=> Download Sample Validation test Cases: Gmail login test case
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. 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 that involves the validation plan, Installation qualification that talks about the hardware-software installment, an Operational qualification that involves the entire system testing, Performance qualification that involves the user acceptance testing which provides the authorization for production.
Hope this article would have enriched your knowledge on the concept of Validation Testing!!