HOW TO DEAL WITH SUBCONSCIOUS REQUIREMENTS
Many testers will have been through the same experience when working on a new release; a few days before “going live” a user identifies a serious bug, which is typically a non-functional requirement, that has been overlooked and not included in the specifications.
The user may believe the requirement is so self-evident that it did not need to be specified. This is an example of a “subconscious requirement”.
We can define subconscious requirements as ”requirements that stakeholders do not explicitly ask for, but still expect to be present in a system. Such requirements are problematic to testers as they can easily be overlooked and not be included in the specifications and, therefore, may not be tested at all”.
>>> HERE TO GET INFORMATION ON REQUIREMENTS ENGINEERING – FOUNDATION LEVEL
Where specifications are missing, the tester will find it challenging to apply common black-box or white-box testing techniques and may apply experience-based techniques.
According to Hans van Loenhoud, Second Chair of IREB, testers can turn to proven techniques from the requirements engineering discipline to gain the necessary experience.
As more and more complex IT solutions are being developed, the emergence of subconscious requirements increases. They need to be tested as ignoring them will lead to costly reprocessing.
Therefore, it becomes necessary for the testers to apply techniques based on experience. In experience-based testing, the tests come from a rich basis made up of the knowledge and experience of the testers themselves. These techniques are error guessing, exploratory testing, and checklist-based testing.
In order to solve this problem and uncover subconscious requirements, a tester may find this list of 7 suitable engineering techniques useful, which can be found in the IREB body of knowledge.
- 1. Field observation: this technique consists of observing users during their work in their usual environment. The tester does not interfere at all; instead, he may notice some unexpected or undescribed behaviour or strange sequences in certain activities. These are solid indicators of subconscious requirements.
- 2. Apprenticing: apprenticing goes one step beyond field observation. Here, the evaluator conducts a short hands-on training in the environment in which the system will be implemented. Key users teach the testers their work processes to better understand the domain. Thanks to this involvement in the work to be done, subconscious requirements easily come to the surface.
Both 1 and 2 belong to the “observation techniques”.
3. Contextual inquiry: this is a repetitive data collection technique that studies in depth a few carefully selected users to arrive at a more complete understanding of their practises across the entire user base.
- 4. System archaeology: this technique is used to gather information about a new system from the documentation, user interface, or competitor system. Most of the requirements found by this technique will be in the specifications of the system to be tested. The rest of the requirements will not be relevant in this particular or will become subconscious.
5. Perspective-based reading: in this technique, the tester uses a specific perspective to look for unknown requirements. In this sense, he retrieves information from documents that are relevant to the domain in which the system is embedded, for example, process descriptions and company regulations.
3, 4 and 5 are known as artefact-based techniques.
- >>> HERE TO GET INFORMATION ON IREB® ADVANCED LEVEL, ELICITATION
- These techniques have a great disadvantage, since they are quite time consuming. However, sometimes this time investment is unavoidable in order to gain full domain knowledge to recognize subconscious requirements and design tests to minimise related risks.
- Another different approach for the same purpose is the 6. Specification by Example. This approach works best when applied by the entire team throughout the development process. Here the test cases are not derived from specifications, but from a repetitive and growing set of real-life examples of inputs and outputs of the work processes that the system is intended to support. The specification for example is capable of producing tests for all requirements, conscious, unconscious and subconscious alike. All these examples make up the so-called "living documentation". In the end, this technique becomes more efficient than the techniques mentioned above.
>>> HERE TO GET INFORMATION ON IREB® ADVANCED LEVEL, REQUIREMENTS MANAGEMENT
- Another approach that deserves to be mentioned is 7. Design Thinking. Although there are several variants of Design Thinking, they all focus on understanding the true needs of users by introducing human-centric techniques such as Persona and Empathy Mapping. Especially exploring the "pains" and "gains" of different user groups can help the tester to identify previously undetected subconscious requirements. For example, prototyping is a technique common to most variants of Design Thinking, which gives prospective users the opportunity to gain hands-on experience with early versions of a new system and provide feedback on its behaviour. Here one can mention storyboards and customer journeys, which are very helpful to discover subconscious requirements.
- Like Specification by Example, Design Thinking is, in fact, a whole team effort, involving analysts, designers, developers, and testers. Techniques 6 and 7 present an agile approach.
>>> HERE TO GET INFORMATION ON A4Q DESIGN THINKING FOUNDATION LEVEL
CONCLUSION
Subconscious requirements are requirements for a feature that users in a certain domain either take for granted or are only aware of when it is not implemented.
Such requirements are easily overlooked, even by experienced analysts and designers, so it is highly likely that some of them will be missing from a system's specifications.
Testers still have the responsibility to test the relevant subconscious requirements, but they are afraid of missing some of them, because they can't trust the specifications. Where testers cannot apply testing techniques that are based on specifications, they could opt for experience-based techniques.
>>> HERE TO GET INFORMATION ON IREB® RE@AGILE PRIMER
This raises the question of how evaluators should acquire the necessary domain knowledge and experience.
First, testers can apply observational and Artifact-based techniques from the requirements engineering discipline, since these are particularly well suited techniques to find subconscious requirements. Learning and applying these techniques is very important, but will significantly affect the evaluator's workload.
Agile approaches such as “Specification by Example”, “Behavior-Driven Development” and “Design Thinking” also significantly reduce the risk of overlooking subconscious requirements, as it relies heavily on real-life examples, customer empathy and early feedback. These techniques work best when applied by the whole team and not for testers in isolation.
>>> HERE TO GET INFORMATION ON RE@AGILE ADVANCED LEVEL (IREB®)
For testing professionals, knowledge of how to apply experience-based techniques can add significant value.
>>> HERE TO GET INFORMATION ON IREB® ADVANCED LEVEL, REQUIREMENTS MODELING
.png?width=1350&name=Infographic%20Bugs%20(1).png)
