by Meenakshi Choudhary, QA Engineering Manager
Quality assurance (QA) is often assumed to be a thin slice of work—something that happens in between writing code and getting it deployed to production.
But in reality it doesn’t happen at just one point in time, and it encompasses more than the testing tools, the number of tests and a bug count.
QA is a mindset, it’s a culture that the team — and the entire company — should be involved in.
Creating the culture
A culture of QA is based on the premise that no single tool, test, or person can guarantee quality.
For quality to be a solid part of the company culture, everyone needs to support and contribute to it—from management and business stakeholders to engineers, designers and project managers/business analysts.
How we solve problems at LendInvest
Before we start any piece of work, the whole team goes through a series of brainstorming sessions together where we discuss the problem at hand and the possible solutions to implement. For every new feature or functionality that we build, we sit together and hear the voices from every function of the team.
A typical journey includes:
- Planning meeting
Planning meeting – or 3-amigos, as we call it – gives us a great opportunity to ask questions about the requirements and the solution before it is implemented. The most efficient and productive opportunity to find bugs is before code is written.
Oftentimes, organisations think this involves too many opinions and perspectives and happens too early in the process.
In reality, this is the best time to ask the questions that assure that quality will be achieved. During this meeting we split the work into smaller stories that will then be picked up for development.
- Technical Review meeting
This is the meeting to clear any last minute doubts about the requirements, the solution we’re going to implement, the completeness of acceptance criteria and any dependencies that we should be aware of before the piece of work is picked up for development.
- Self Testing
Our developers don’t just focus on implementing a technical solution or review their peers’ work, but instead they also support the QA by self testing their work and documenting the evidence of the scenarios they have tested before it’s passed on to the QA.
This builds a collaborative culture within the team and helps developers have a broader understanding of the overall feature.
- UAT Testing/Business Review
Once the story has passed QA, there comes the opportunity for our business stakeholders to get involved in the development cycle, to review the ongoing work before it gets released, where they test as an end user and analyse if the implementation is acceptable.
Often, in addition to this, the team presents their working solution which results in an instant feedback from all the stakeholders and helps refine it further and address any issues early on.
We have a decent QA team size here at LendInvest, a perfect blend of both automation and manual QAs. The whole QA team sits together every week where we discuss bugs, enhancements, or ongoing issues, features across teams and share ideas with each other which helps facilitate learning and strengthens awareness of quality between the teams.
We act as QA advocates for the end user and help the organisation avoid the temptation to defer issues that will impact quality. Whenever possible, we encourage the team to fix issues immediately since deferring known issues only leads to accumulations down the line.
How to build a culture of quality
The best practices and actions that have helped us building this culture at the organisational level:
- Define Ready
We have a clear definition of “ready” that includes criteria that describe whether requirements (acceptance criteria) are testable and clearly state the users’ expected experience before the team attempts to provide a solution.
- Test early & often
With testing at every stage comes the continuous feedback that is then used to mitigate as many risks as possible throughout the software development lifecycle. Moreover, it helps the team to continuously learn about the product and what can be done to increase quality and reliability.
- Automate everything that is feasible
In every team, we dedicate plenty of time to automate the regression tests which gives us confidence that we are not introducing any bugs as we add new features or products.
Automated tests can be executed significantly faster than manual tests, are less error prone and less labor intensive hence helps the QAs to focus on more important work.
- Define Done
We have a clear definition of “done” that includes criteria that describes whether all validation activities have been completed with acceptable results.
This includes that unit tests have been added, functional testing is complete, performance implications have been considered, data integrity validation has been completed, security validation has been completed, automation tests are passing, and regression implications have been considered before the story can be marked as done.
- Team work
After the release the whole team is again involved in monitoring the way the feature or application is being used using various tools that paves the way for enhancements that will further improve the user experience.
We recognise that quality is the responsibility of the whole team — not just the QA. This mindset is vital as it ensures that everyone has an eye on quality right from the initial design phase until it’s released to our customers.
At the core, this culture of quality assurance enhances our ability to build and launch high-quality products that meet our stakeholders’ needs—and that benefits everyone.