You have arrived to work this morning only to see that none of your previously reported bugs are being fixed and new features are still in development. This might come as a surprise to Junior QAs who would expect their working environment to burden them all the time. The truth is, days that feel like there is “nothing to do today” are occurring more often than you think. But remember, this is only how they FEEL, especially at the beginning when you have just joined the team and don’t understand the product so well.
Falling into this trap may cost you your job or your reputation at work. Nobody wants a QA who appears to slack at their job since it is expected from your role to suggest improvements and to be the one who simply does not accept things the way they are if they are not done correctly.
Here, I want to suggest 3 things that could possibly improve your testing process when you feel like you covered a lot of cases and scenarios but still can’t be confident enough to say that something is completely tested.
When you join a new team and start exploring the product, you will probably notice every minor mistake and possible room for improvement. After going through most of the product’s features manually for months or even years, there are very high chances of missing the obvious stuff since you’ve checked them before and you assume they work as expected. Create yourself a template or a checklist (Trello is your best friend here) that will remind you to test scenarios that can be applied for specific features. This comes in handy after you spend some time on the project.
For example, if an application consists of a lot of panels that can be populated with data, you don’t want to miss a bug that might happen with users’ input and naming. You would probably want to check allowed characters when giving names, minimum and maximum length of names and similar basic stuff that we forget to check because we are concentrated on more complex cases and we allocate most of our time to that.
When features are interconnected it is hard to deliver a product “iteratively and incrementally” as Agile Manifest suggests. If this is true for your team too, it means that QAs can be left to wait for the next thing available for them to test.
This time can be used to prepare possible test cases for currently developed features based on previously defined requirements and acceptance criteria since these are the cases that should be verified first. This way, when feature is developed and ready for testing, you go through the most important stuff first and then through other possible cases. The most critical bugs are discovered and reported early preventing the cost and damage that could possibly be discovered in production.
You can always review uncompleted requirements and use them as learning points. After some time, a team could conclude that some specific stuff (UI for example) is usually not done according to plan. This can be used as an indication or proof that maybe more people are needed in the team to handle that work. QA team takes part here by being the ones who insist on quality, otherwise, unaccomplished requirements accumulate and result in overall dissatisfaction with the product.
Besides the obvious – talking to your customers and asking what they actually want, use your imagination. Try to be “in their shoes”, what would be useful for you if you were the customer of your product? This takes time and experience and is not something that everybody can easily do without previous experience but it is important to keep this in mind in order to make progress. This way you can see further and test scenarios that at first don’t come to your mind and are not that obvious.
As in every other job position, to learn is to grow. At first you start simple and as you get used to the product, more and more scenarios will come to your mind. After all, daily dedication to “what could possibly go wrong with this feature” is what you do… 🙂