When searching the web for “why software has defects?” the number one reason given is “Miscommunication or no communication”, which can clearly be broken down into 2 things:
- Lack of clear product requirements or no product requirements
- Lack of a product owner constantly “checking the pulse” by communicating with stakeholders and the delivery team to make sure they are building the right thing
After some brief web research we also learn the key factor for project failure is once again, the quality of requirements:
In this short article I would like to present to you my perspective on the effect that quality has on every product’s life-cycle.
As a Product Manager with an extensive background in Quality Assurance I believe that the natural evolution of a QA Engineer could span 3 ways:
- Software Automation Engineer – although in some companies this role is performed by a developer, the technical aspect of Quality Assurance is when someone is focusing on preparing automation testing. This helps foster a culture of planned and ad-hoc testing for new features and advocate the customer side perspective.
- Project Manager – Every good QA Engineer (especially in leading roles) has to deal with project management on some level (in some teams the Scrum Master is the teams’ QA), from making sure all parties are aligned in the daily stand-up meetings, having small iterations with developers to making sure that the features they are building are consistent with the feature specifications, up to and arranging meetings for quality aspect “lesson learned” workflows and procedure conclusions.
- Product Manager – after establishing that the key factor for Issues is a lack of definition or no feature definition and miscommunication or no communication, the natural person you have in the company for the Product Management role is your best QA Engineer. Beyond him/her being able to write better requirements documentations based on his testing documentation experience. Product Manager with an eye for detail and quality perspective on processes, workflows and procedures would also be the best focal point to sync all relevant parties and stakeholders to make sure all are building the right thing, also being a good QA Engineer s/he would be a good advocate for the user and even a solid expert in conducting A/B testing.
Some best practice standards we have for quality delivery assurance:
- We provide as small as possible product requirements in the form of User Stories, if needed we create an Epic and under it we link User Stories.
Example: Epic would be “Lighthouse Internalization”,
linked User Stories would be :
“Agent Layout Localization”
“Content Manager Layout Localization”
“Language Selection in Editor Screen” and so on - Constant sync between R&D and Product Manager
- Prioritization of Test documentation
- Constantly checking the market trends
- Gathering customer and partners feedback through a number of qualitative and quantitative methods
- Open and transparent communication to align partners and customers to what exactly will be delivered
At KMS lighthouse working on AI products with world-class, leading edge technologies we have to be agile as much as possible, yet keep a systematic and methodical work order to continually facilitate our growing customer base, who are pivotal to our R&D and in enhancing our products they use daily.
As we always look to develop and stay ahead of the curve, though still remaining agile, it was after long consideration that the Lighthouse R&D team have switched from Agile Kanban to Agile Scrum delivery methodology.
We utilize Lighthouse for internal knowledge, ‘practicing as we preach’. This ensures our whole team has access to all the necessary business information including technical support, customer success and the product roadmap. This usage ensures the whole company are aware of our products, potential use cases and aligned with new developments and functionality – all crucial for success!
