In the mobile app testing world, it’s important to understand the difference between verification vs validation. There’s certainly no shortage of jargon in the tech world—and no shortage of confusion about many of these technical terms. In fact, I bet if you asked someone to define a term they loosely throw around, they probably won’t be able to. We’re all guilty of mixing around or misusing common terms.
Authentication and authorization are two terms that I’ve often seen confused in the mobile app development world. Sure, both start with a v and end with a –tion and are used in regards to testing—but don’t let these superficial similarities fool you: They don’t refer to the same thing and are not interchangeable. In fact, verification and validation are unique, equally important processes in the world of application testing.
What is verification?
The modern English word verification ultimately derives from Medieval Latin verificationem and is defined by the Oxford English Dictionary as:
The action of establishing or testing the truth or correctness of a fact, theory, statement, etc., by means of special investigation or comparison of data.
In other words, verification is the process of ensuring that software behaves correctly and without incident. Is the application built correctly? Verification is examining the code, static code analysis, and recording design documents. The goal is to verify design specifications and architecture. Because of the nature of verification, it’s typically performed by a human.
Verification requires input outside of just the code/product itself. To truly verify, static documentation is needed, such as design specifications and other architectural documents. It’s due to this need for documentation that verification is performed primarily in a gated fashion at different stages of the systems development lifecycle (SDLC).
Verification steps
Here are three typical verification steps:
- Requirements review: Stakeholders and subject matter experts have been interviewed and functional requirements have been solicited and documented. Verification involves looking at the requirements holistically and corroborating that the needs of the business will be served by the fulfilled requirements and that the requirements are clear, actionable, and have well-defined acceptance criteria.
- Design verification: The technical design is based on the requirements, the technical design verification verifies that the documented design will meet the requirements. Do design elements trace back to the requirements? Do the requirements serve a business process? The design verification will also check prototypes, layouts, and data model logic for completeness and accuracy. In most cases verifying the design involves more than one individual from cross-functional technical teams.
- Code analysis: This verification step is completed either after or during application implementation, when the code is being written. This can be done in a formal code review process, walkthroughs, or through static code analysis.
Verification, while seeming initially time-consuming, mitigates risk and may well ultimately save your team hours of rework. Verification also serves as a quality milestone during project implementation, ensuring that development never veers off track.
What is validation?
In short, validation is the process of testing that the system works as expected. Rather than being concerned with how the application was designed, validation ensures that stakeholder requirements are met. Validation includes testing performed on the application during and after development.
Validation involves test cases, test automation, and other methods for actually testing the functioning system. We can think of validation in terms of the test pyramid.
Types of validation
Consider these common validation types:
Unit Testing
A unit test is an automated test that checks that the smallest units of code are working correctly. The goal of a unit test is to verify the accuracy of logic under multiple conditions.
Unit tests work by calling a method, passing any necessary parameters, making an assertion about the result, and evaluating the results.
Integration
These tests validate that different components of a system work together. This is where we make sure everything plays nice together. Integration testing can also involve interacting with third-party and external dependencies, like an API.
End-to-End
End-to-End testing validates the complete functionality and performance of the entire system, doing its best to replicate a production-like environment where the application will have its full set of features tested. Since the goal is to simulate how an actual end-user interacts with the system, end-to-end testing is referred to as UI testing.
Other types of validation can include load testing, performance testing, or any other validation of the system or functional requirements.
Validation tools
Validation is made possible through frameworks, tools, and platforms that can automate test cases and manage the suite of validation tests. These tools can be specific for a particular device (desktop, mobile, etc.) or an operating system (iOS, Android) and range in complexity. Open-source frameworks like Espresso, Selenium, and Appium, require more hands-on development but are flexible and extensible. No-code tools like Sofy are great for easily automating mobile test cases. With Sofy, you can grab an actual device, record an action, and turn it into an automated test case.
Typically, a well-defined strategy will determine the best tooling for your organization’s situation.
Verification vs validation: Understanding the difference
When considering the topic of verification vs validation, it’s easy to find examples of validation and verification used interchangeably. Yes, they sound similar, and refer to the same general domain, but perform different functions. Both are critical to delivering valuable and well-functioning features but each requires a different approach, processes, and tools.
Disclaimer: The views and opinions expressed above are those of the contributor and do not necessarily represent or reflect the official beliefs or positions of Sofy.
