Whenever we test an application, the main point in mind is to verify the requirements. But, we normally find the client providing feedback, even if all the requirements are met. Now, why exactly the client provided the feedback becomes a concern. To simplify this concern, the testers need to make sure that they are taking care of all types of requirements. By all types of requirements, it means direct (explicit), indirect (implicit), and latent (extra) requirements.
In this article, I will throw some light on these types of requirements and their details:
1. The explicit requirements noted down(Direct requirements): This kind of requirement is noted down directly from the client discussion and converted into the document of understanding. These are generally shared with the team working on the project, and the designs, wireframes and scenarios are made based on the provided details.
The process to test these requirements is simple and the tester needs to match all the requirements. If the requirements are met then it’s good to proceed, otherwise, the tester needs to log a bug. Whenever the software application fails to meet a requirement, in this case, the team need to analyze whether the software application needs to be fixed, or the requirement needs to be modified.
This testing also helps to analyze the performance of the team. If direct requirements are not met and the software application reaches the testing stage, the development process needs to be analyzed. If the development unit tests the build well, the direct requirements issues will be minimal in the testing phase.
2. The implicit requirements(Indirect but obvious requirements): This kind of requirement is generally not provided in the documents, but are obvious requirements expected by the client. These requirements can be related to the security testing of the application, performance testing of the application, usability testing of the application, and availability of the application. For example, the user expects that the loader icon should be displayed on navigation, the password is saved in encrypted form, etc. These requirements are sometimes called ‘non-functional requirements.
Say, for instance, there is data to be entered for a firm using the fields ‘Employee Name’, ‘Employee ID’, etc. Now the implicit requirements can be like, the uniqueness for the field ‘Employee ID’, search functionality for name, the performance of the page to save data, etc.
In order to verify implicit requirements, we can take help from popular applications. Like for a social networking application, we can use Facebook, Instagram, Snapchat, etc.. as a standard; for chatting applications, we can use Whatsapp, imo, etc. as a standard, for taxi applications, we can use Uber, OLA, etc. as a standard.
The process to test these requirements is a bit difficult and is often based on the experience of the tester. This testing represents the contribution of the tester in the development effort. The more the experience of a tester in a problematic domain, the contribution of the tester increases proportionally. The coverage of this type of testing cannot be explained without using the heuristic testing approach.
Whenever the software application fails to meet an indirect requirement, the team analyzes the customer point of view and its impact and based on these factors, the decision is taken.
3. The latent requirements(Unwanted but attractive features/requirements): Such requirements are the one which makes you different from others and makes you win the client appreciation. These requirements are actually not expected by the client, but still an add on gives them a reason to appreciate you more. An example can be like providing an animated icon explaining the ongoing process making it simple for laymen and giving an attractive look to the application, or handling the latest hardware feature in an application and providing an add on for the same. These can be related to implicit requirements, but since these are not obvious/expected, they become a bit different.
The process to test these requirements is the most difficult out of the 3 types of requirements, because these requirements cannot be easily thought of by the testers, and are generally first encountered when the application comes in the testing phase. Testers need to understand the viewpoint of customers in this case and think like them to make wise decisions for such requirements. The testers need to be aware of the customer environment and accept/reject these requirements accordingly.
For example, if you are playing a game on your mobile, and you receive a phone call. When the user comes back to the game application, the user expects that the game will restart. However, the developers have handled that scenario such that the game will resume from the last updated state. This is kind of an extra feature, which delights the client as the game progress is not lost.
Another example can be like handling scenarios for disabled people, like adding vibration for notifications with voice assist. This feature can delight the client as it will increase customer coverage.
Whenever the software application fails to meet a latent requirement, it provides the opportunity to improve the software, but also provides you with the knowledge to convert it into a revised process. This revised process will ultimately help your team to develop a smooth product with perfect quality, making the client and customer more satisfied and happier.
So the job of a tester is not just to verify the direct requirements, but also to take care of the indirect requirements and the extra features. An expert tester is the one who knows the coverage of implicit and latent requirements in addition to the explicit requirements.
