I have been working in Quality Assurance (QA) for more than 15 years. Over the years, I have learned that in the corporate environment, many people, including decision-makers, very often don’t understand the full essence, potential, and importance of Quality Engineerings.
One of my mentors, whom I admire, once told me, “Quality is not only QA’s responsibility; everyone- from development engineers to technical architects, to product managers need to share the responsibilities. In a QA role, if you want to be successful, you have to know the right amount of information from everyone and always ask questions.” I took my mentor’s advice very seriously. Since then, I started voicing my concerns—even if it is a technical architecture for developers’ design-related discussion. In the companies I have worked so far, most of my counterparts were male in the developer, product manager, and engineering leadership roles. At the same time, the majority of the QA engineers were female. When intense conversations happen for technical deep dive, many QA engineers keep their thoughts to themselves and think it may not be a good idea to ask questions in front of everyone. Quality becomes an afterthought instead of a well-planned and well-executed item for everyone. Shying away from conversation generates significant myths around the QA role, some of which I would like to address in this article.
“Anyone Can Do QA Test”
Is this true? I wonder why companies created the role in the first place if anyone can do the QA test. “Checks and Balances” is a fundamental mechanism for any system to perform efficiently—corporate governance is no different. The human tendency is to cut corners, even if cutting corners is not the intention, sometimes it is difficult to see your error. Especially when innovation and problem solving are the primary focus, ensuring functionality and accuracy from all points of view is just tricky. In software engineering, this is even more complex as individuals work on their specific areas of problem-solving. Ultimately, a large group of individuals’ work products are integrated into a final solution or product that a customer or end-user is going to experience.
From my experience, I have seen most of the developers only perform tests on their own software code, which we call unit tests. Each developer cares for his portion of the code most of the time. Since most companies nowadays have unit test coverage thresholds, developers are bound to have their unit test cases pass for code submission. Even if all developers have 100 percent unit test case pass rate, who will do the end to end testing for overall product functionality and integration? Who will take care of the regression testing to make sure new features did not introduce new failures or defects? Who will think about keeping track of all the test cases and update them as needed? Who will think about whether high-priority bugs are added to the test cases? Who will make sure those bugs are fixed before the product release? As you can see, software companies need to have QA engineers who will take a holistic approach to test end-to-end and ensure the overall quality of the product.
“QA Won’t Understand This, and They Are Not Technical People”
This one is my personal favorite. For most of the teams I worked with, I had to make them understand that yes, I am technical. QA understands technical architecture. QA needs to understand software specification documents, otherwise, how can they perform the tests? Testing is not just finding defects or finding a negative test case. Unless QA can think critically, the product quality will suffer. To all developers, product managers, and technical architects, please rethink when you say QA is not technical. QA takes the most time-critical tasks of verifying the product quality and getting it to communicate with other technical members at the very end of the product development cycle., Without being technical? This is not possible.
“QA Always Raise Critical/Show Stopper Bugs at the End”
This statement usually comes from upper management. Product development typically has a deadline with a release date. Until the development team enables product functionality and features, QA can’t start testing. QA engineers need to test the new features and execute regression testing, integration testing, and performance testing. Companies generally have QA entrance and exit criteria on the waterfall model. Testing duration is predetermined. All development activities should end on the code freeze date. However, developers continue to delay the code freeze date while wrapping up their check-ins, final and minor fixes, etc. Testing time always gets impacted since the release date is frozen. Also, in the Agile model, QAs observe this issue in the majority of the Sprints. Testing duration is often reduced since developers are fixing their unit test issues. The QA team starts late and executes their integration testing with the latest code. Hidden issues can only be found once an integration test is performed, which are not discovered in ad-hoc or modular functional testing. These critical show-stopper issues are always identified at the end—closer to the release date.
“QA Manager’s Job Is to Prepare Dashboard, Status Reports, and Share Those.”
This is also a fascinating myth. Many developers and even QA engineers themselves believe that QA managers just forward emails, report test results to upper management, and do nothing more. Interestingly enough, since I became a QA Manager, I have had to take care of planning the test strategy, which ensures that adequate test cases are planned and that the product won’t suffer quality issues at the customer site. But do we really need to spend so much time testing? Negotiating with upper management to have enough time for testing and convincing the leadership team to invest in test automation so that testing time can be reduced are among the critical tasks a QA Manager has to perform well. Test reporting, bug triaging, test case management, and managerial tasks like budget management, resource allocation, employee coaching, maintaining team morale, and helping the team unblock obstacles are just a few of the other tasks a QA Manager has to perform.
Everyone has their share of responsibilities. We should not assume that some functions are more or less important than others. We all have our seats at the table. There are many more myths about QA roles. In my opinion, we have to be our own brand ambassadors. We have to voice our opinions and not hesitate to ask the right questions. We have to respect our own role and influence others to understand it. Initially, many may think we are asking unnecessary questions and creating extra work, but gradually we will gain their trust. Our upfront work will reduce the amount of stress and time involved in making fixes as an afterthought. Once quality is designed and built into the products, it will undoubtedly increase customer satisfaction and produce better results for everyone. I hope that together we can bust these QA myths!
Originally published on StickyMinds.