QA engineers often become frustrated with developers as a result of differences in priority. Developers pay particular attention to writing code designed to address a specific function, oftentimes failing to address how their processes fit into the bigger picture of the overall experience. QA on the other hand focuses on quality by taking into account the user perspective.
Agile teams can foster alignment between QA and developers, but they encounter pitfalls nonetheless. There are however key practices QA teams can employ to achieve successful collaboration with developers. Below, we will explore the reasons for the conflict between the two and the various ways to improve the working relationship between QA and developers.
1. Quality testing over quantity testing
Most times, the tests run by QA engineers are completed as if there is a quota of tests to be met. QA engineers need to remember that testing is not simply a means to an end, but that its ultimate goal is to improve product quality.
QA engineers need to ensure that they understand the needs of their customers and test based on those needs. Ensure that the application makes sense from the customer’s perspective.
For example, an application with an error-reporting feature must clearly indicate where an identified problem is. Even if the application has a great look and feel and passed all of the functional tests, if customers complain that the reports are not easily understood then the application fails to meet customer needs.
Don’t simply test to say that a test was performed. Always think of the users. They do not care how many tests were performed on the application, all they care about is that the application meets their needs. The ultimate goal is always for product quality to satisfy the needs of its customers.
2. Quality is a shared responsibility
When it comes to product quality, everyone should be responsible. There must be no more “us’ and “them”. Developers should take responsibility for their code and ensure that the relevant unit tests are written, and QA is responsible for testing the whole system.
While it is true that QA serves as the gatekeeper, in an agile team everyone should have equal responsibility for product quality.
3. Fight for what matters
Even as a gatekeeper, QA needs to understand that not every single defect is worth fighting over and that there are times to let go. If not then a lot of time will be spent fixing things that are of little or no importance.
A good tip would be to define your boundaries. Develop a list of things you absolutely will not compromise on and focus exclusively on them.
It is for this reason that many teams institute a “defects committee” which is tasked with predefining showstoppers versus other bugs before releasing every sprint or version. This ensures that everyone’s efforts are focused accordingly.
4. View lessons learned as constructive
It is almost impossible to achieve zero defects. Even rigorous testing misses some defects which are then later discovered by external users. What is important is learning from those missed defects to improve your next release.
A question that Developers frequently ask QA engineers is “How did you miss this? Didn’t you test?” The truth of the matter is that because software is sometimes so complex, it is not always possible to test every single scenario and configuration. Risk-based testing and user flow tests are conducted based on common occurrences, their level of importance, and the amount of time available for testing.
Sometimes QA consults with commercial stakeholders, project management, or at times the customers themselves to determine what was missed in order to create an automatic test for that specific missed defect.
5. Create adequate visibility in your QA reporting
Visibility makes data insight available to stakeholders. Visibility in QA reporting is key as it not only helps identify problems, but it also improves collaboration and trust among team members–agile teams are no exception.
When QA shares their work with developers, they are given the opportunity to pay attention to pertinent matters down the line. Participating in bug-hunt days with relevant stakeholders not only broadens the scope of testing efficiency but also allows for better scrutiny of the product. When you publish important lessons learned from customers, you receive the added benefit of being renowned as a specialist on the subject matter–one who represents the end-user.
6. Every new feature is worthy of release
There are many times when QA threatens to not approve a feature due to its low quality. This is, however, in my opinion, the worst thing a tester can do. Think about it: Turning down a feature alienates the developer, and worse, deprives users of the chance to use it.
Rather, consider a few other things that can be done in case of low quality. For example, perhaps only release the part of the feature with sufficient quality or dedicate a task team to improving quality. A commonly used tactic is marking a feature as “alpha”, “beta”, or “early access” so that users understand the extent of the incompleteness of the feature. This, in my opinion, is a win-win because the users receive the feature, QA receives feedback from the users, and quality is not misconstrued.
The main takeaway
Instead of waiting for everything to magically ran smoother, skilled QA engineers take initiative and develop better collaboration with their developers, making a high-quality user experience of paramount importance.
