Your Journey – From Quality Assurance to Business Analyst
Role of QA / Tester has been a point of debate since long. A majority of world argues and defend the limited role of a QA / Tester, who normally supposed to contribute to test the quality of product. Name any software development life cycle model, be it V or iterative or any kind of Agile, in theory QA supposed to work closely with team from initial phase till release. In real world, most of the teams found utilizing QA at very last phase of the cycle with targeted goal “validate what has been developed”, and ensure the quality of the product. With my experience of over 10 years as QA, I found myself asking questions like
Is it justified and sufficient to test the product with just what has been delivered after development.
What if the requirement itself was not correct or complete or ambiguous,
How much responsible I should be for delivering quality product, so on and so forth.
And only answer to all questions is “Work with Team for quality product” rather than “Work for Team to verify and validate product”.
We got an opportunity to work for a product which was almost loosing its market share to their competitors due to compromised quality, and team was then asked to jump in and do whatever needed to revive the reputation and regain the market share. We started working and today client not only regained its reputation but proved to be a ahead of its completion. Dealer communities which were criticising the product since long, and fear of losing the business was main concern, now they are experiencing an exponential growth in sales.
While reading several appreciation mails from our client appraising the quality of product which actually helping dealers in their business, just came in mind that why dealers are now happy and excited with new releases. What actually we did differently, was it a just facelift to previous versions or what, and answer is, we just followed the process and culture of our organisation and rest is history.
Sounds strange but I mean it, let’s give it a shot and try to revisit the long journey:
Ready detailed requirement documents are always been a low hanging fruits, and ‘Testable Requirement’ always been an easy flow for QA and makes his life easier while developing test scenarios and actual testing. But ever given a thought what opportunity has been missed. Recent studies shows that almost 50% of total defects may avoided if identified before formal release of the document. In any software life cycle, cost of a defect always inversely proportional to its root cause, and if the root cause is requirement itself, it may severely impact the budget of the product.
As QA,we were always encouraged to be a part of this crucial phase, which not only make sure that you have the opportunity to understand the business needs but also have sufficient time to raise your voice. Your engagement with process since inception gives you an extra confidence to own the Business Requirement, to understand the feature from end-user point of view, to contribute with your brilliant ideas which definitely will add some value to product. Stakeholder always welcomes the great ideas, and if you found yourself contributing in the requirement itself, your voice would be respected and a feeling of “To be a crucial part” of the system and not just an entity who test the system.
And from here your journey starts, once you successfully placed yourself as part of the process you actually earned the “Right to be Heard” ( but not interfere in others domain). During the process, many a times many “What If” hits your mind like
What if my query is wrong or irrelevant
What if this was already been discussed
What if someone laugh on my question
What if I proved to have less knowledge
What if I raise this on later stage, etc etc etc.
which is certainly an indicator that you are not owning the product and process. Give a shot to understand, what could be the implication if your worries or hesitation results a heavy cost on later stage. Then certainly only one ‘What if’ would come in mind “What if I raised this earlier”. Point here is that you dare to own the product, which means you care for it and have curiosity to understand the minor details too. No matter what other things about your query, it is important for you to understand the product as you are the Owner not a user.
Owning the product ensures your involvement in design and development of the product. At design level, QA can make sure that all proposed components and flow are testable. A dry run to proposed flow will help the team to validate proposed approach and answer to the question if design is delivering the definition of done. Close coordination of QA team with Dev team during design and development certainly help in identifying exceptionally corner use cases. Test Pyramid theory may also be adopted for quality control as you are friendly with product at component level, and you can suggest scenarios which can be covered with unit and integration cases. A volume of test scenarios can be tested at code level during compilation of project, which definately not only can reduce the count of QA cases but at the same time ensure a quality delivery.
No development is possible without business queries from development team while writing the code, and what an opportunity for you to understand their concern and query. You are the owner of the product, try to solve the business query and if not why not initiate coordination with Product Management. Involving yourself in business and flow related development queries not only push you to learn and answer it but also you found yourself a bridge between Product Management and Development. Slowly and gradually, you found yourself an important team player where team looking at you whether for their query or brainstorming sessions or new ideas or what not.
You were part of requirement phase, you were involved with developers while design and development, now it’s time to invite everyone for testing. Sounds like a bad idea? believe me, it is not. Primary job of a QA is to make sure the quality of the product and you were working hard to achieve this since inception, and more eyes on the flow always been a high probability to uncover hidden or corner cases. That does not mean you force development team to execute your QA cases, hahahahaha. Well while you are busy with your QA cases, can you make sure that once you identified and report an issue, how developer is fixing the same. Are sufficient number of unit and / or integration testcases added around the area, and so on.
Yes, exactly this is what I did for all critical assignments, and now ready to ride with Project Management team, just started as BA.