Why QA consulting needs a holistic engineering view?
“How did QA miss this?”
Traditionally, this question arises from every quarter when there’s an issue with post-release product quality.
However, an inefficient QA process is not often the sole reason.
In fact, the problem can be more complex than that and may have started before the product was even released.
Let’s see an example:
Let’s point our fingers at QA!
Does it apply in this scenario?
A successful release requires coordination between different teams, including design, development, QA, and others. When these teams aren’t aligned on what they’re trying to accomplish, it can lead to pesky defects in your product development cycle—which means defective software and unhappy users!
And that’s why today, through this blog we want to share: why quality needs to be viewed from a holistic engineering lens, a lesson we learnt from our experience of working with clients across the globe and of varying sizes.
Why is there a drop in product quality?
Why are our users reporting critical defects?
Why is our QA not able to spot defects earlier?
…These are the questions we often get to hear from our clients.
While these “Why’s” help to uncover what went wrong with respect to product quality, we think that it only presents the tip of the iceberg picture and there needs to be a deep dive into the engineering processes to uncover much more important components that are directly or indirectly related to software quality.
Now, why do we think this hasn’t been made as a standard approach to looking at product quality? While there can be many reasons, it all boils down to one core issue – tech leaders take a siloed approach to quality and are not looking into the problem/quality from a holistic engineering point of view.
At Zuci, we understand quality is an ongoing process. And that’s why we have built our QA consulting approach with CARE (Check, Act, Refine, Evolve) to identify issues at the root and help fix them.
Good software quality is not about testing alone but encompasses other software engineering practices such as clarity in requirements, estimation, code quality, documentation, software maintenance, individual skills, team competencies, and other allied areas. – Zengineers
The characteristics of QA consulting exercise are unique. Let us traverse the characteristics of consulting through the five key aspects: technology, product, people, process, and culture.
Here’s the approach Zuci takes to understand the five key aspects.
Test engineering & QA
The main objective here is to review the technology and capabilities of the client based on the following premises:
Quality of the software product stems from the quality of the process used to create it.
Technology that supports the quality of the software process.
Level of technology used in software engineering product development.
Software engineering process maturity.
Consultants should perform these exercises in the early stages of consultation and get as many details as possible and document these observations which would help in the next steps of consultation.
Consultants should gain a complete understanding of the product. It can be done through a series of meetings, whiteboard, brainstorming sessions, and looking at different parts of the client’s suite of applications in project management tools; not just from a QA standpoint but also from a software engineering processes perspective, by taking a bird’s eye view of their architecture, code, infrastructure, technical debt, and other relevant areas.
The core-product review should include:
Product Defects and Pattern Analysis
Sprint Planning and Delivery Review
Review of Manual and Automated Tests
API integrations – Tools, Test Approach
Hardware, Software & External Integrations
Product Change Management Practices
Product Management & Production Support Integration
When diving deep into the product, you can’t miss the ‘Technical Debt’ associated with it.
Technical debt is a phrase originally coined by software developer, Ward Cunningham, who describes it as,
“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”
Engineers who contribute to the various lifecycle phases of product building possess not only deep engineering skills but also a ‘Product Quality Engineering Mindset.’ An effective quality assurance (QA) consulting practice must be grounded in the product quality engineering mindset.
This mindset is a unique set of principles, methodologies, and practices that consists of self-learning, collaboration, teamwork, perpetual experimentation, exploration, asking precise questions and seeking answers, commitment, and focus.
When talking about people and collaboration, one can’t emphasize the significance of empowering people through training and development programs. This serves as a knowledge base and is crucial when there are geographically dispersed teams working together.
It is essential to recognize the role of QA consultants in this regard in order to create a strong foundation for any organization. The key is getting everyone on the same page so that they understand how each part of their job fits into the whole picture in building quality applications.
Interested in a solution that shows a clear picture of quality of the product for people across the organization?
Typically consulting teams follow homegrown processes or lightweight processes. Many of them follow Agile or Lean-based methodologies.
The main objective of the process assessment is to review the software engineering practices followed by the client. Predominantly it requires consultants to have:
Discussions with Product Management
Discussions with Engineering team(s)
Discussions with Professional Services team
Discussions with customer facing teams
Collaboration between Product Management, Engineering, Solutions & Production Support teams
Production Support Practices
Zuci’s way of looking at ‘process’ is by reviewing three core areas that gives an overview of overall engineering processes and effectiveness which includes:
Not sure of your QA process maturity? We’ve covered in detail about QA maturity and laid out a road to achieve it and more. Get it all here.
Software quality is huge. It can make or break a company. It is very aggressive and action-packed.
Some companies prefer to build quality into their products from the start, while others focus on fixing bugs after the product has launched. Some companies make money by building high-quality products; others make money by fixing problems after a product has been shipped.
It all comes down to the company ‘culture’ .
The role of a consultant here is to enable a shift-left culture that eliminates the siloes and helps improve the collaboration among the teams.
Key elements of Shift-left
Include testers early on: Make QA part of the SCRUM team. QA should go through the user stories and work with the product managers to understand and get clarified. QA then defines acceptance criteria along with the product managers and analysts. QA will decide on the manual tests that need to be done before the start of the Sprint.
Bring developers into testing activities: Bring in more Unit, Integration & Static code analysis for their code before pushing it to the main branch; the merged code is cleaner and less error-prone. Individual code units are easier to test because they are smaller and more navigable.
Introduce testers to coding: QA will work with the developers to automate the acceptance tests based on the acceptance criteria.
Keep testability in mind while coding: Successful Shift Left Testing also requires a team effort. When writing code, developers should ask themselves, “How do I make it more testable?” This might mean exposing a hook or creating a unique ID for an element
Find an opportunity to automate any repeatable process: Automation should cover Unit/ Integration /Acceptance testing covering application functionalities, integrations, configurations, deployments, performance, capacity, and security testing.
Supplement automated tests with exploratory testing and usability testing.
We at Zuci thoroughly enjoy every QA consulting exercise and hope you’d enjoy reading about it too.
It’s important to have a holistic engineering view of the product. Sometimes, the “bigger picture” points us in the direction of what’s wrong with an area of the product; other times; it simply helps us identify potential opportunities for improvement across multiple areas.
To figure out areas of improvement, you can simply start with a product quality scorecard or even take a QA maturity quiz that will move the needle in your product lifecycle process.
So what sets a product apart? The answer is simple but not easy: quality.
Quality is built on the core code writing skills of the developers. Great products won’t have a pile of technical debts accumulated in them. They have clear documentation for each of the teams and make it easier to collaborate. They take into account the end-user experiences. And it doesn’t leave quality to chance.
Want a free copy of the consulting report that we made for an F500 e-commerce giant?
Test automation framework is the architectural backbone of any automation testing as it structures the entire workflow with a set of guidelines, practices, and tools that streamline and standardize the process of automating tests.
Despite being in an Agile-driven SDLC, test automation often remains treated as a distinct process. The seamless integration of the test automation team and developers largely depends on selecting the right test automation partner. This article attempts to give key factors that be considered and taken care of before choosing your test automation vendor.
Flaky tests are a common challenge faced by development teams in their quest to ensure software quality. These intermittent tests produce inconsistent results that may pass or fail unpredictably, even with no changes to the code.
A user's expected behavior when interacting with an application is documented and designed into the application using the agile software development methodology known as Behavior-driven Development (BDD). BDD assists in avoiding bloat, excessive code, unnecessary features, and lack of focus by advising developers to focus solely on the desired behaviors of an app or program.