So Much More Than Bug Hunting: How to Overcome Common QA Challenges
By Carmen Făt, Senior QA Engineer, Cognizant Softvision
Many people have the wrong opinion when it comes to the work of a QA. Most believe that a QA engineer runs after bugs all day, every day. But is bug hunting the only thing that a QA has to do? Let’s shed some light on what a manual Quality Assurance tester really does.
There are several other tasks a QA engineer performs each day. We also encounter obstacles that block the flow of the testing process, making our work even more interesting.
I. DOCUMENTATION (Or lack of it)
The first step to start the testing process is to study the available documentation. Mock-ups, PRDs, frameworks, UI//UX, you name it. All of these types of documents are useful in order to understand the product.
As we all know, documents may contain designs, specifications in regards to the expected behavior of the product in test, and the Acceptance Criteria that needs to be fulfilled before launching the product to the users. There is no doubt that a good testing process begins with good documentation.
But what happens if there is no written information about the product? What if most of the documentation is not ready/accessible? Let’s review the following cases and some best practices to handle them:
a. Lack of documentation: You just found out that a new app is being developed and you will be in charge of testing it. The first thing you do is ask a bunch of questions about the app. Unfortunately, your thrill is gone when you find out that there is no documentation to read, so you won’t get the answers you looked forward to.
What can you do? Ask the Development Engineering or Product Management team about the development progress of the app. You might be lucky enough to get pieces and bits of the app while the development is still ongoing. You’re able to gain a general idea about the product and can start creating basic QA documentation (such as Test Plans). This way you will already be prepared when more details become available and will only have to update the QA documents you previously started writing. This is an important step since involving the QA early in the process can have a significant impact on the project, but it’s often forgotten or undervalued. (Search for the “Early Testing Principle” to learn more about the importance of involving QA early in the process).
b. Outdated documentation: You consider yourself fortunate enough because you got your hands on some documentation. This is until you read it and realize that it is obsolete and the information contained doesn’t correlate with the little information you received when you started working on the project. This can mean only one of two things: either the most recent documentation is placed somewhere else or the existing documents were not updated with the latest decisions.
What can you do? Ask for updated documentation. If this is not possible, there are two paths you can take:
- One way is to escalate this issue to upper management (either your team lead, coordinator, project manager, etc). The advantage, in this case, is that you will benefit from your manager’s guidance on any escalation points.
- The other way is to escalate this by yourself and ask for a meeting with the Development Engineering and Product Management teams. During this meeting, you can ask questions in order to clarify which of the information should still be used. If major decisions about the product are a work in progress, ask for an ETA.
Keep in mind that approaching this case varies from one project to another. Thus, before assessing the right course of action, assess the specifics of your project and setup.
c. Restricted documents: The project you are now working on is either top secret or maybe somebody just forgot to give you access rights to the documents. Either way, you are blocked and cannot continue with your work.
What can you do? There is only one way to gain access to the documents you need, and that is by asking for them. First, you can ask the others involved in the project, such as your Team Lead or Project Manager. If they can’t help you, reach out to someone from the project who is in a timezone close to you and can provide you the permissions to read the documents. Depending on the project and your team’s communication channels, you can use instant chat apps (such as Slack) or emails to contact the individuals who can grant you access to the documentation.
II. UNREALISTIC SCHEDULE
Setting an unrealistic schedule happens more often than you think. There may be countless reasons why production rushes to launch the product to the users, from the engineering availability to financial risks or current events. Even though all the reasons are valid, having a tight deadline doesn’t help you much with the testing process.
What can you do? Since you will need to work on a tight schedule, you won’t be able to go through all the testing phases you would normally go through. Because of this, you will have to take full advantage of the available timeline. This means that prioritization and estimation are important and helpful actions to resort to in these special cases. With testing prioritization, you can plan the testing process by ranking the tasks from mandatory to nice to have. Although it’s a subjective action, proper estimation can help with predicting how much effort (time, money, etc.) is required in order to accomplish the testing tasks. Gather the key people working on the project and perform a risk assessment together. Make sure that you all reach the same outcome; everybody understands the consequences of a rushed launch and has a backup plan if the worst-case scenario happens after launching the product.
III. DEFECTIVE COMMUNICATION
Before launching the product to the users, there is a lot of work that has to be done by the teams involved in the project. Each team has a specific scope, but in the end, they all must join forces and work together so that the final product is successful.
However, there are times when people fail to communicate effectively. Many factors can lead to miscommunication, from cultural differences to lack of context to poor or underdeveloped soft skills, and so on.
What can you do? There are easy ways that can help you improve communication between you and your colleagues. Apply the following strategies:
1. Involve yourself as soon as possible in the process. Ask if there are any meetings where QA could participate, even if there is little to nothing to test at the moment. By attending the meetings, you will be up to date in regards to the decisions and changes that impact the product, so you will be able to also adjust the Testing Plan and keep track of the latest resolutions. Use these meetings to ask questions and note down every little aspect that can be useful for your work. Don’t be afraid to raise concerns if you have any. Involving yourself during the meetings creates connections with your colleagues and they will appreciate your interest and engagement.
2. Ask the right questions. Try to avoid questions that might receive short answers and ask open questions. Open questions usually require long answers. Long answers might provide you with enough information so that you don’t have to come back and ask for more details. Experienced testers can also use their intuition and request information on areas that they already know may raise difficulties, based on their background knowledge.
Asking the right questions can also help when the people that share and exchange information are located in different time zones. This is especially important because miscommunication, besides causing frustration, can also lead to delaying the work for an entire day.
3. Provide constant feedback. Feedback is a crucial step toward growth and development, so why not use it to improve communication between colleagues? Giving and receiving feedback opens communication between people, but can also backfire if those involved in the project don’t deliver the feedback properly. Make sure your feedback doesn’t come off as accusatory or focused on any one individual. Instead, you can provide value in your feedback by being specific, issue-focused, and respectful. You can also provide suggestions for improving the communication between the teams. Try being objective rather than subjective when providing feedback to your colleagues.
The scenarios above might be helpful if the client is willing to make an effort to improve communication with the team. Unfortunately, there are clients that offer little to no information. Below are a few ways you can handle this difficulty:
1. Propose a testing process if there isn’t one already. If there is one, maybe it’s worth looking through ways of simplifying it. Try reaching an agreement that works for all the parties involved in the project. Keep it simple and focus the process around mandatory tasks.
2. Ultimately, if the client is not receptive to any of your suggestions to improve communication, you can write down a list of risks that can affect the success of the project. Explain some common risky scenarios, such as:
- Being unaware of deadlines is a blocker when it comes to test planning
- Misunderstanding the product can lead to potential escaped bugs
- A poor quality product will impact its success on the market in a negative way
- A product that doesn’t perform as it should will affect the revenue, the number of users will drop, and so forth.
Being faced with the risks might trigger a positive reaction from the client. But if this becomes too much of a challenge for you, it might be best to escalate this issue to your superiors. If nothing works, there could be bigger issues in regard to these particular clients and it might not be your place to fix them.
Practice, Grow, and Expect the Unexpected
There are many challenges a QA has to face and overcome, and the aforementioned are just a few. This is, of course, in addition to the main task, which is signing off on a high-level, quality product.
Whether the scenarios described are familiar to you or if you’re a beginner in the testing area, it’s always a good idea to expect the unexpected. Sure, being observant and thinking outside the box are two must-have qualities for a good QA, as they are crucial in finding issues of all kinds. However, a professional QA should always be open-minded in order to evaluate how to best respond to unpredictable situations.
Besides growing on the technical side, QAs should also expand and practice their soft skills. When you are working with various, diverse teams, soft skills become critical. Studying and practicing to improve the way you connect and interact with your colleagues will help you and the teams involved in the project deliver quality products that make the overall business successful.
