Let’s go beyond QA and look at QE
In a previous post on LinkedIn, I’d briefly mentioned about the dramatic changes in the Quality Assurance function. From only coming into the picture at the very end of the development process to becoming an integral part of the software development lifecycle, quality as a function has evolved tremendously.
Customer demands and competitive pressure has changed product development. The arrival of development approaches like Agile and DevOps has brought about many changes to the quality function as a result. The rush to iterate often and release fast has placed quality at the center of all product development practices. This is, of course, a very good thing.
There’s never been any doubt that to build a high-quality product, development and QA teams must adopt quality as a critical component that’s integrated thoroughly across the software development lifecycle. The journey of the quality assurance function must begin from the product’s conception and go all the way to the release. Consolidating quality into each and every stage of the software development process creates a product that operates seamlessly and is delightful to use. But how can a product development team achieve that?
To keep quality at the center of all development efforts, software companies must move beyond Quality Assurance and leap towards Quality Engineering. This is certainly not easy, and working towards QE is a process in itself. Achieving QE requires the right mix of people, tools, culture, and processes. Here are some notes of how I believe this interplay will work:
I’d like to start by quoting Andy Hunt, Pragmatic Thinking and Learning– “In industries or situations where one is not allowed a full-blown strike, a work slowdown is often used as means of demonstration. Often this is called work to rule or malicious obedience, and the idea is that the employees do exactly what their job description calls for—no more, no less—and follow the rule book to the letter. The result is massive delays and confusion—and an effective labor demonstration. No one with expertise in the real world follows the rules to the letter; doing so is demonstrably inefficient.”You cannot achieve Quality Engineering if your developers and testers are simply performing tasks that are mentioned in their job descriptions. In order to excel and break the barriers of mediocrity, your entire team must contribute whole-heartedly towards creating a quality product. This is a fundamental shift in attitude. It calls for ownership, initiative, passion, and empathy.
Quality engineering requires your people to constantly question everything they’re doing- “Are we building a product that will truly make life simpler and add value to those who use it, if so, are we building it correctly?” They must consistently question all parts of the process to ensure the team is producing the best possible product.
- ToolsUsing the right set of tools makes a huge difference in the overall process of Quality Engineering. Explore solutions that extend the right balance between coverage, comprehensiveness, flexibility, and adaptability. For eg. test automation tools save a substantial amount of time and improve test coverage. Better processes make test data accessible in comprehensive reports to aid in identifying issues. Today, automated testing tools are vital to supporting overall quality. These tools also ensure that the application is functioning appropriately on multiple browsers and devices. They also enable teams to execute pre-scripted tests on a Web or Mobile app, thereby reducing dependence on manual testing and other inefficient testing practices.
The entire process of Quality Engineering can be made easier to implement if broken down into elemental bits and pieces. Just like software development, a blueprint of quality can be made. After breaking it down into smaller chunks, all potential breakpoints can be tested to ensure the entire process flows. This process enables teams to see what’s working and what’s not coming together.That apart, my own experience has been that some of the biggest problems arise from a somewhat counter-intuitive quarter. Doing too much is as bad or worse than doing too little when it comes to quality. Some of the challenges I have witnessed arose when software teams got over-ambitious and went overboard in their anxiety to create a world-class process. This can take many forms like baking in too many features, too much required test coverage, impossible test automation goals, and too aggressive deadlines. This grand vision tends to translate into an impossible set of requirements — each of which poses a threat of failure, thereby creating a roadblock in the path to move ahead. The story of Evernote, a recent Silicon Valley darling is a cautionary tale. Its current CEO has spoken of how the product’s “unique collection of bugs and undesirable behaviors” is primarily responsible for holding the company back. Stories like this are a sign that it is vital to keep the process simple. Set goals for each stage that are practical while still being focused on delivering value to the end-user.
Today, software companies are reaching out to customers with unique and tailor-made experiences. Since customers across the globe are spoilt for choice, the quality bar has dramatically risen for the software products they consume. Therefore, offering top-quality offerings and releasing bug-free products fast has become vital to business survival.
By integrating quality at every step of the software development lifecycle, companies can create products that set new standards of quality in the market. It’s clear that Quality Engineering is now a strategic function with the potential to deliver a competitive advantage.