In my previous articles I covered some knowledge and tricks that I’m using. This time I’ll be sharing an experience I learned the hard way. It sounds a bit dramatic, but it is not - it’s just something to keep in mind so you don’t fall into a trap you set yourself.

Whenever I began working with some project that is unknown to me I always started with exploratory testing. Exploratory testing in combination with some product manuals or product specification is the best way to learn dark corners and hidden behaviors of the product. No matter how much the product has been tested previously (by someone else), this way of familiarizing yourself with the product hugely increases chances to reveal some inconsistencies and bugs.

Should test case IDs reflect execution order at all? If yes, here is the pain and my solution. If no, here is the alternative philosophy.

At some point I probably mentioned that most of the things I write on this blog came from my personal experience. It might be some interesting discovery I made, an advice I want to share, or question I want to clarify. This time I want to share one of (workaround) solutions I made, but I’m also raising a question in order to cope with this challenge more efficient in the future. This might also help other QA colleagues who will enroll on new projects and want to be as prepared as possible.

I can’t forget the words my colleague gave me when I was just taking my first baby steps as a QA, and it was a great QA-related piece of advice: “Never assume anything.” I can assure you that the more time progresses, the more this makes sense.

Today’s IT systems we work with are more complicated than ever before, and we need to be completely sure of the outcome of any part of the system that we are either testing, exploring, or developing. If we are not sure about the expected behavior, there is always a specification or some other type of documentation that is supposed to clarify the enigma. If there is no specification and the documentation is lacking, we can always check with the project manager, product owner, developer, or anyone who is familiar with the system.

Sometimes the simplest additions make the biggest difference. While working on test specifications, I realized that many test cases describe what happens, but not where it happens. To fix that, I started adding a small column - or a quick tag - that turned out to be a subtle but powerful way to bring structure and instant clarity to my test documentation.

I’m the author of test specifications for a few products, one of which I’m continuously maintaining, and I’m currently designing another one for a product still in development. During both designing and maintaining, I faced a challenge that might seem trivial at first… until it starts to get on your nerves. You might find yourself in this situation too, so lean in and try to visualize it.