Software testing is a very strategic activity. It required high amount of mental and creative thinking. If you cannot think and work on several different context and scenarios at one time, you can never be a good tester.
That is why experts in tech industry recommend good programming skills to gel up with testing skills.
With the availability of tools as plugins and cloud based communication management tools, the software development process is becoming cheaper and faster with the passing of each day. This speed effects the working of a software tester. When there are smaller teams, defining the coverage of the application within the limited sprint time becomes a serious issue.
The Use Heuristics and Oracles:
Within the domains of Exploratory testing and context driven testing approaches, several heuristics and oracles are created, so that testers under time crunch and other such pressures can define good test coverage and find important bugs.
What are oracles and heuristics?
“A heuristic is a fallible method for solving a problem or making a decision”, whereas an oracles is “A principle or mechanism by which we recognize a problem”
There are several Oracles and Heuristics in place. One such is called FEW – HICCUPPS.
I remember being at a software project exhibition, where I met these two wonderful tech savvy students working on an interactive web portal for a university. They asked me specifically about managing coverage of the application to reach the right quality standards. Student projects always fascinate me, as they have limited resources, short deadlines, and their coordinators to manage.
I took a paper and write “FEW” on it. They asked me what is it, and I responded; this is what gives you the bigger coverage of your application, and you can make sure what’s being developed is as per the quality standards. I then completed the acronym to “Familiarity”, “Explainability” and “World”.
The Amazing Oracle:
About three years ago, while going through Michael Bolton’s blog, I came across FEW-HICCUPPS heuristic. I found that fascinating, as it was the answer to most of our questions regarding gate keeping the quality standards of an application.
The oracle contains:
- Comparable Products
- User Desires
If you are part of a small testing team and have multiple projects and sprints running at the same time. You need to be really careful and picky about how to get the right quality standards for the products and above all, get the bugs before they get to the customers.
Familiarity means, that the application and whoever is part of developing and testing that application must be inconsistent with the previous bugs and problems. Meaning that the developers and testers must be efficient enough to code, detect, and prevent recurring problems in the system.
It is highly dissatisfactory for the users and customers to come across a same bug over and over again, and eventually they look for other solutions.
Being familiar to the inconsistencies is good, as the team would know which areas to tap when the application is rolled out to the client.
In context driven testing, testers need to be careful while looking for familiar bug patterns, as the familiarity changes from context to context. A mobile application would require testing the UI and experience more than an application being developed for an accounts department, and to be used internally within an organization.
For a test team working on a system under time sessions and strict deadlines, it is utmost important that every member should understand the application and what it does. Explainability is creating such understanding of the system which not only team members can articulate to themselves but to others as well.
Explainability related to understandability, and if you are part of the application development and delivery process, you would know the amount of bugs we record on test management tool, with tags such as “User understanding” and “System Knowledge”.
It is also something which spans beyond testers domain. It is related to programmers, business analysts, marketers, team leads and project managers. For each entity, it is necessary to understand the system and explain it.
On the other side of the picture, if the system is not understandable, and some of its function is hard to grasp and explain to a common user or peers, then we also have a problem in our hand.
It’s all about consistency. The consistency of the product to the scenarios and pattern we see around the world. If the product is not behaving as per the recognized scenarios in the world then there is a severe inconsistency problem with it.
This applies to every aspect of the product, with the inclusion of its User interfaces, the database architecture, logics, and its purpose.
For example, an icon for email is usually an envelope, and replacing this with some other image will not allow the users to understand it, because they are applying the worldly context on it. Same goes for the usage of message texts, fonts, database variable definitions, color, fields’ entries, system setups, menus, and configuration management of the product.
So here it is. It is just the initial part of a complete oracle, but these three heuristics are really helpful for small teams working on big projects and are confused about giving it the right coverage.
That is the purpose of heuristics and oracles, to give testers a free creative hand in order to get the most out of their time and thinking patterns.
If we apply this at the very beginning of the project, the results are not only overwhelming, they are deeply satisfying for the Quality Assurance team and their peers.