How to Train Your Testing Intuition

An experienced tester, familiar with their project for a long time, makes up a list of test cases quite easily. But if you are just developing your professional style, have come into a new project, or are simply open to sharing experience, then you will probably find something useful for yourself in this list of professional work methods.

There is a theory that intuition is the result of your experience and knowledge. Everything that you have ever seen, heard, and felt was left somewhere in your brain, even if you do not remember it. The sum of intuitive knowledge can include both knowledge gained by reading books or a phrase that you heard when flipping through the channels on the TV.

When you make decisions without relying on arguments, you rely on the intuition that you acquired just living life. It turns out that the broader your horizons, the better your intuition. This will obviously work when you need to write tests. Documentation is a good thing. But for a good Quality Control process, this is definitely not enough, especially if the task is urgent. You need to choose a limited set of tests intuitively.

Examining Use Cases

A use case is a scenario according to which a real client will use the functionality. The hardest part is obtaining them. Where can you get them? If it is possible to communicate with clients, ask them how, why, and what for. If this is not possible, ask the Product Manager to get real examples. The more, the better.

Being Friends With Technical Support Team

A wealth of information is the support team. From them, you can find out questions, problems, and scenarios that clients send.

Processing Bugs Found by Clients

Bugs found by clients are a valuable source of inspiration. Record the scenarios of these bugs in the form of regular tests (automated or manual) and save the client artifacts attached to the bug reports. These can be files, special metadata, settings, configs, etc. We run other tests on this real data too.

Exploring the White Box

Understanding the architecture of the project and the internal structure is a difficult task but achievable. Knowing what changes in one module affect internally and how the sequence works “under the hood”, you can write very competent tests.

Noticing Weak Points of the Product

Development never goes smoothly. Sometimes things are done under pressure and faster. Such parts of the product can have bugs for a long time. It’s good not to lose sight of this functionality.

Watching Developers

Knowing who made a piece of code, and who is the main developer is convenient. Some dislike tests, write only a few, and do not double-check anything (this does not mean that they are “bad”, they may have other talents). If you find out that this piece of code was done by this type of person, you need to be meticulous. Some test everything thoroughly. Testing this work is easier. You can create an internal rating for yourself: with whom you need to be more careful, and who does the clean job.

Diving Into the Topic of the Product

Each product exists for a specific area of life. There is a whole world: its own terms, concepts of “good” and “bad” and market. It can be useful to understand this vocabulary, know or read something about the industry and observe competitors’ products. When you keep up, the brain quickly figures out what to look for. And competitors’ products can sometimes teach you how to do better, for example, if the changes being tested relate to the interface.

Learning Testing Theory

Both for the Black Box and the White Box testing there are already developed techniques for writing tests. They can always be a starting point when you do not know where to start (Equivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition, Use Cases vs Statements testing).

Moreover, the inspiration for writing test cases can be drawn from the following areas:

1. Direct functionality:

• each acceptance criteria;
• valid tests;
• invalid tests;
• boundary values.

2. Boundary (integration) areas:

• areas that will send their data to the new functionality;
• collisions – the types of data sent and received match;
• variations of communication of the functionality with other modules: via ftp, via aws, configs, and so on.

3. Roles, permissions, access – nothing is violated, everything is preserved.

4. Canons, standards, and generally accepted rules.

5. UI/UX:

• Error messages are informative. Imagine that you are seeing a product for the first time and encountered an error: did the message help you take the next step to resolve it?
• Success is informative: the user realized that they achieved the desired goal?
• Style consistency (with the rest of the product): lists, filters, and tables.

Of course, ordinary daily experience also affects your intuition. The more time you spend on a project, the more acutely you feel it. It also happens as with driving a car: the longer you drive, the less careful you become. At such times, just go through the checklist above and check yourself. Maybe you missed something important.