TL;DR
You are a software tester in new prominent software startup company. Things are moving fast and you can not apply traditional software testing techniques. FEW HICCUPPS technique created by James Bach and Michael Bolton can help you to jump start your testing in your rapid changing company.
Introduction
We often imagine software testing as complicated and hard. Maybe because when you are new in this field, you do not know where to start, or you think that every software is put in NASA rocket.
Last Tuesday we gathered for Testival Meetup #45. Venue and food sponsor was software development agency Five, so many thanks to them. The main talk was by Iva Marinić (King ICT) on topicA FEW HICCUPPS heuristics and oracles as convenient way of discovering problems in software under test. Iva recently attended Michael Bolton’s excellent course Rapid Software Testing, and A FEW HICCUPPS is part of that course.
What Is a Bug?
First mistake that you can made as a new tester in agile environment, is to report every suspicious application behaviour as a software bug. Doing that, you will lose your credibility among your software developers very quickly. So how to filter out important bugs? Here is how you can use FEW HICCUPPS method to help you with that.
FEW HICCUPPS
A FEW HICCUPPS is a mnemonic that helps you to remember that method. It is a list of oracles, where oracle is some mechanism that could help you to determine is your test passed or failed (that something is a bug).
F is for Familiar Problems. Ok, but familiar problems recognized by who? Michael Bolton or Justin Bieber? You know that answer is Michael Bolton. There are other great testers, for example, there is test heuristic cheat sheet, with familiar problems in applications, created by Elisabeth Hendrickson, James Lyndsay, and Dale Emery. When I test, I always open this cheat sheet.
E is for Explainability. So you use the application. If you can not explain application behaviour, that part of application could have a bug and needs to be investigated further. For example, when you share something on Facebook, and you can not explain who will see that post.
W is for the World. Here we compare application behaviour from the world known facts. For example, weather application says for your town that is raining, but actually it is sunny beautiful day.
H is for history. You compare current application behaviour with one from the past. This could generate additional work when application under test is new for you. You will need to consult experienced team members.
I is for Image. Image of what? Of the organization that is creating the application. Image could be brand or reputation. For example, Apple applications must use beautiful design, and reliability comes second.
First C is for Comparable Products. The most obvious example is clock, every clock implementation should be compared with atomic FOCS-1 clock.
Second C is for Claims. Everything agreed on the application, use every type of information (Slack, Jira, Github issue, meeting notes) that describes what user wants from the application. Those are actually customer requirements. Create your tests based on those information.
U is for User’s Desires. And these are not all user desires, but only reasonable one. How to determine them, needs negotiation and thinking. For example, in notepad editor, user would like to edit complicated mathematical formulas. This is not reasonable desire.
P is for Product. When you are stuck with some behaviour, check how products behaves in similar part of application. For example, in Word, zoom in text and zoom in image should behave in similar ways.
Second P is for Purpose. Application is created with purpose. If user can not fulfill that purpose, than this is a bug. This could be explicit or implicit purpose. For example, in email client, user would like to send an email by copy/pasting its content.
S is for Statutes. Statutes are regulation. For example, every web application must comply with GDPR regulation.
Conclusion
In order to start testing the application you do not need any team explicit input. FEW HICCUPPS are proof for that.
