Building consensus among Product Managers and QA Engineers

We would have encountered many a times when the requirements are understood in a different way and the delivery goes against what is required. We fix the requirement gathering and take a jab at understanding features so well and there are chances of missing out important customer case from a QA who is supposed to be customer’s advocate but takes care of engineering aspect rather than customer’s view. Let us see how a QA Engineer sees a feature : 1.Understanding the flow of story and services affected. 2.Creation of test cases and test data. 3.Execution of test [Automation + Manual]. 4.Ensure no regression bug comes up as a part of new change. 5.Test case maintenance and updation. Product Manager thinks about the below 1.Great design to get the customer using the product. 2.Success metrics of products (ex: # of registrations, GMV etc). 3.Making hard for competitors to copy (product & feature). 4.Potential risks & end to end functional flawless flow. It is very critical to bridge the gap each agile teams are facing today and I propose some thoughts on how each PM and QA engineers can work together to reduce the gap. Product Management Teams: 1.Writing user stories with end-to-end customer cases and mention of impacted systems. Follow standard way to write user story across all teams. 2.Share the performance of each feature which was released in a sprint , this motivates engineers as their work is rewarded by the customer. 3.Sprint grooming — we see very few questions or people distracted in grooming as they are occupied in ongoing sprint or loses interest(Credit goes to remote mode work). PMs should keep the team engaged with the crisp business details, launch plan of any new feature and why is the feature important to do now. 4.Ensure product related data is readily available in data management tools(ex:confluence) so Engineers needn’t request for data always. 5.Ensuring that every engineer working in the product understands the feature in the virtual mode of work and also a note of which business metric will move if this feature is developed. 6.Add a KPI to Product Managers on Tech-Debts which will make them explore the tech aspect of a product and learn why each Tech-Debts are picked up. Quality Assurance Teams: 1.Learn the personas involved behind each feature and create testcases for each persona. It should also mention product behaviour when feature is launched, data is created or if there is any issue how to encapsulate the feature from customer. 2.To QA Engineering Leaders : Add QA KPI so that each engineer looks for data/usage and writes a document on how the feature is performing after release and share in QA forums. Feature: Dunzo daily: Number of users who used the feature: 10000 Number of orders placed in past 10 days : 50000 Sharing this information will also help us derive the test dataset we have to configure in staging environments for the next release. 3.Weekly reviews of customer issues opened by Customer Support agent in the in-house tool to get a feel of user pain points. Also watch playstore/appstore reviews(mobile teams) and social media handles for customer feedback. 4.Introduce a practice to ensure that each QA Engineer writes the business impact of the bugs opened in QA/Staging phase. This will help the engineer think of how the bug could impact user. Proposed: Issue : Unable to place order in Dunzo Business impact : 25000 members are blocked in checkout Steps: Login to Dunzo, proceed to daily section, unable to place orders as product systems is giving internal server error Adding the business impact will also help the stakeholders to triage the bugs effectively. 5.Think of cases where a user can abuse the feature and if there are any, bring it to the attention of PM. 6.QA Leads to ensure features related to same module isn’t assigned to same engineer every sprint, so every release QA engineer gets new module to learn and test. 7.Understand the business need and envision user journey when reviewing the designs and critique the design.(Check for error scenarios, copy changes, whether design is reversible or not). Look forward for more insights and more ideas!