Reading Time: 12 mins

Why QA consulting needs a holistic engineering view?

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?

No!

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!

Here's a recent consulting disaster: Accenture sued for $32 million over Hertz website redesign

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.

Our President, Vasudevan Swaminathan briefs "Holistic approach to quality" in this 2-min video. Check it out

Ideal QA consulting

"Quality is everyone's responsibility." 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.

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.

Whereas,

  1. Engineering practices
  1. Core product
  1. Customer releases
  1. Test engineering & QA

Technology

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.

Product

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.”

This may interest you

Technical Debt – How HORUS handles it?

People

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?

How HORUS benefits every stakeholder in the engineering organization?

Process

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.

Culture

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.

If it interests you to know more about our work, and to get a comprehensive consultation report, click here.

Final thoughts

In conclusion, 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.

The bottom line is that improvements in quality will be short-lived without this holistic approach as ever-increasing competition forces product owners backward in quality, features, and functionality.

Like to know more about the topic? Shoot your questions to sales@zucisystems.com and we’ll get back to you in a day.

Keerthika

Keerthi Veerappan

An INFJ personality wielding brevity in speech and writing. Marketer @ Zucisystems.