The Art of Testing: How I Plan and Prioritize Tasks for Effective and Quality Results (Tech)

Photo by Battlecreek Coffee Roasters on Unsplash

QA is an essential part of the testing process, and it’s crucial to understand what needs to be tested and to what extent to avoid overdoing or underdoing the testing process. Communication plays a vital role in understanding what needs to be tested and ensuring that all bugs are rectified.

As a tester in a fairly new company, you get to test various parts of various products. Each testing task is different — some are quick to complete, while others with more test cases take longer. Some tasks even require the help of other department members. Here are some learnings that have helped you manage tasks more efficiently, which we will discuss below:

Planning Ahead

Handling multiple tickets simultaneously is a common challenge for QA professionals, requiring careful sorting based on priority, due date, and level of difficulty. Initially, I struggled to effectively manage the workload, but soon realized the importance of approaching each ticket with utmost care and responsibility. There could be tickets that require other departments’ help as well, like:

• DevOps: populating databases in the QA environment from the dumps (snapshot of database) from the production environment for testing purposes, white-listing and black-listing IP addresses, etc.
• IT: Adding yourself to a specific group to gain access to specific virtual machines for development or staging purposes.
• Data Engineers: Getting some specific SQL queries to test benchmarking(calculating how quick or slow a particular query runs) of queries in QA Environment. Planning ahead could help in managing time better and also helps to complete the work on time, or even better, before time and use the free time to automate the boring parts of the job like building an automated test suite or documenting what you have done — including SQL queries/config file changes/errors that could arise while testing.

The planning doesn’t need to be overly complex. For instance, if some tasks are dependent on other departments, we don’t have to wait idly. Instead, we can start working on other tasks while the previous task is on hold due to the other department. A quick call with the developer while the DevOps are deploying their updates to the QA server can help us make good use of our time and be more productive.

The Process of Execution

When a ticket is assigned, I do the following steps(not exactly) to understand what to be tested and complete them on time. They are:

Understanding the Ticket

Understanding what needs to be tested and to what extent is crucial. In some scenarios, the API can be mocked using a fake API that returns pre-set values instead of the actual API. When reviewing the ticket, any ambiguity or inconsistency should be noted and clarified with the developer via chat or call, depending on the complexity of the issue. It’s also essential to check for grammatical errors as well as a simple change in spelling like IMS instead of OMS could sometimes denote another product or microservice altogether.

Photo by Erik Mclean on Unsplash

Talk to the developer

Usually, the tickets don’t have every detail that gives more context to the testing. A call is set up with the developer to get more context about the feature or bug and to discuss the possible test cases and the edge cases right before drafting the test plan. The call could be utilized to clarify doubts and even some ambiguity while trying to understand the ticket.

Photo by KOBU Agency on Unsplash

Preparing a Test Plan

Usually, bigger companies are often subscribed to test management tools like TestRail, Qmetry, etc, which act as a catalyst in documenting the test cases providing functionalities to store and manage screenshots as well. There are even some reporting frameworks like Allure that create concise and colorful reports that could be easily understood even by someone not part of the Testing.

Photo by Filip Mroz on Unsplash

Well, in our startup, we don’t have the luxury of fancy, expensive software, so we’ve resorted to using the timeless classic of Google Sheets to create and share our test cases. It consists of 4 titles(Testcase, Expected Behaviour, Result, Remarks).

• Testcase — The test case defines the parameters, and functionality of the test and outlines the steps that need to be taken to ensure that part of the software is working as intended.
• Expected Behaviour — This column consists of the expected behavior or what is expected to happen while executing the test case.
• Result — This column holds the actual result mostly it is passed or failed.
• Remarks — If there is some context that needs to be conveyed like “The UI and the database value are same as expected”, or “the API is tested via swagger (framework allowing users to explore and test the API’s functionality without needing to write any code) as well”.

Proactive in Following Up

We often forget to run quick errands for our colleagues or friends, and it seems that many people operate in the same way. Personally, I find reminders helpful in ensuring that I complete my tasks on time. However, not everyone uses reminders to stay on track. In my opinion, it’s fair and reasonable to check in with someone now and then to speed up the process and understand any challenges they may be facing. Of course, it’s important to be polite when asking for a status update and to avoid sounding like we’re micro-managing them. Using phrases like…

Photo by Dan Dennis on Unsplash

• Is it done?
• can you make it fast?

makes the person pressurized or just gives reasons to hate you. A genuine reason, with better explaining the situation by requesting them politely will make your colleague comfortable to speak with you and also helps in speeding up the process. More contextual and positive pinging looks like this:

• Hey, this is quite urgent with higher priority. It would be very helpful if you could provide access as soon as possible. Thank you! (try not to use ASAP)
• Could you please let me know if there is any ambiguity in the test document? 1 hour later: Is the document looking good? Let me know if there are any complications.

Use the magic words! They are truly magical! Like please, pardon me, thank you, sorry, excuse me, etc.

Quick Tip: Time is your best friend. Whenever you are asking for an errand that depends on someone from another department, asking them how long would it take would make it easy for us to just ping after the agreed time to know the status. It helps you to know when can you expect and also sets the pace for checking the progress as well.

If you want someone to do something just ping them until it is done. Works for me, hope it works for you as well. Avoiding the usage of short forms like ASAP, TY, etc… is never liked by people in the corporate.

I hope that the lessons I’ve shared here can be helpful to you as well and that you’ll continue to explore new ways to improve your testing skills and provide value to your organization.

Happy Testing :)

Author: M M Kishore