Why Quality Is Now Aligned With Development at the Outset of Projects

Historically, quality in a process was something that was done at the end of the line. You inspected your widget once it was made, and if it had flaws, you fixed it or threw it out.

[ad:32102]

As in many modern manufacturing environments, quality in software has become a process you do from start to finish. Moving from that end-of-line quality control mindset to a more user-focused, whole-team quality advocacy helps deliver a better product where quality is baked in from the start, and part of the job of all roles on a software team.

Quality advocates start on the first day of a software development project and are now part of the development process from idea to final deployment. With the strengthened emphasis on quality, the title for quality professionals has rightly been designated as “advocacy” to display that someone is working hard, from conception to shipment, and is determined that a software development team will deliver a superior quality product or solution for the customer.

In other words, quality advocacy is now more of a broad-ranging activity.

This allows quality advocates to think about the end user early in the process, and how he or she will use the product, app, or website that is being developed. To help with this, quality advocates use various tools to help understand the end user. One tool is the test persona.

Test personas help identify factors such as, “Are they a farmer with big hands in the middle of a field in bright sunlight with no Wi-Fi?” “Are they a healthcare provider in a dimly lit corridor of a hospital in the middle of the night?” These personas bring quality advocates closer to the end user and help us figure out the highest priorities of the client we’re working with.

The more we can find out about the end user and the domain of the app, the better we can build the right product, using the right process. The domain could be anything in support of any business-to-business activity or transaction such as managing car rentals, organizing pizza delivery, or utilizing meeting tools. For example, if you know from the start that your app will be used in Quebec, you can build in French language support from the start, instead of trying to retrofit it at the end. This of course saves time and money while enhancing quality.

At the same time, as developers are thinking about languages, libraries, and frameworks, quality advocates are thinking about how to prove if the software is doing what it should do, and equally important, not doing what it shouldn’t do. Every piece of software gets used under conditions that are far from ideal, and quality advocates are here to help prepare and accommodate for these challenges.

Every quality advocate has a set of war stories to draw on, projects where something went wrong, or requirements that were changed late in the process. We use these to make recommendations as early as possible. The job of the quality advocate is to tease out the assumptions in the requirements, items that would be obvious if you were a domain expert but aren’t always explicitly spelled out.

Along with developers and quality advocates, a software team typically includes many roles, all of whom work together to produce something of superior quality. Pairing can play a big part in helping to make the team a success. For quality advocates, they often pair with a developer to get a tool created that will make testing easier or to estimate how much work a feature will take. They can pair with user-experience designers and front-end engineers to think about workflow, accessibility, and ease-of-use. Quality advocates often pair with other quality advocates to get a fresh set of eyes looking at the app. And they might pair with product owners to help write out the feature requirements.

What makes for a good quality advocate?

The first trait of a quality advocate is curiosity. Quality advocates are tinkerers and enjoy testing, solving, and exploring. But this isn’t a random, scattershot curiosity, but rather curiosity backed by the scientific method. We make a hypothesis, construct an experiment, and test that hypothesis. Then we change one variable and repeat the test, always knowing which blind alleys we have travelled down in our quest to find defects.

The second trait is that a good quality advocate has the mind of a learner. We work in a world where the ground is constantly shifting with new versions of browsers, operating systems, and languages. If we stop learning, we have fossilized in place. Quality advocates enjoy learning about new technologies, tools, and methodologies.

The third trait that makes for a good quality advocate is teaching. Good learners can make excellent teachers, and one of the responsibilities of a quality advocate on a development team is to teach. We learn a new way to test to expose a weakness in the application. We learn how that weakness is shored up and teach that to the rest of the team and to other quality advocates. Then we learn about a new potential weakness from another quality advocate and repeat the learning and teaching process over again. Moving from testing a web app to an iPhone to JavaScript requires ongoing learning of new tools and practices, and sharing that acquired knowledge.

One item to point out. I often need to explain to people that quality advocates are not pessimistic, miserable nitpickers in a state of grim tedium. A lot of us do this because we find it to be quite enjoyable. You crash an app on your phone? That’s interesting; what caused that to happen? Can I make it happen again, and how will we go about fixing this issue?

A found defect is cause for excitement from the rest of the development team, because we work together to get something completed that will delight and assist the user. If we’re able to crash a product in development, we believe it’s our duty to find out what caused that to happen and how can it be corrected. Everyone contributes to that. We take a whole-team approach to quality, with the understanding that the quality advocate is not the only person who cares about quality, but rather is the point person and subject matter expert, marshalling group testing efforts and researching best practices along the way.

Methods and tools

Along with possessing the right traits inherent in a solid quality advocate, having the right portfolio for methods and tools is essential as well.

The first question quality advocates often ask is: “Does this feature work the way it is supposed to work?” It is a question with a simple yes or no answer. However, the more interesting question is, “Will it still work if I put the phone in airplane mode? Or if I take a call? Or if we run the battery down, exceed the data limit, or quit out of the install partway through?” These types of “what-if” questions come from the realm of nonfunctional testing, which is less about individual features and more about how the app behaves in its ecosystem of other devices, data sources, and browsers.

The second test is internationalization testing and accessibility testing, both of which are part of nonfunctional testing. Unless you can guarantee that all the users of your app will have flawless vision, perfect physical bodies, and a strong network signal, you will likely have users with vision defects and physical limitations or other external constraints to compete with. We need to delight all these users to make their lives easier. You will have users who prefer a right-to-left text direction over a left-to-right, and users who want to use your app in a different language than the one you wrote it for. There will be users who can’t see a difference between red text and green text, and users who want an emoji in their user name and password. All of these scenarios need to be accounted for.

Another essential test used by quality advocates is test automation. Test automation is a force-multiplier—enabling us to execute more tests and cover more ground than manual testing could do alone. We automate what makes sense to automate, thinking about both the cost and benefits of automating a feature and maintaining that test.

Automated test suites allow you to run a soak test, which will help us find defects such as memory leaks. You start a soak test running on Friday and set it to repeat over and over. On Monday, you examine the logs and servers, and what was a tiny problem has been magnified because you did the same actions hundreds or thousands of times over.

Customer on our mind

The bottom line is that quality advocates want the worst possible event to happen to a piece of software or product before it ever gets deployed. Quality advocates will stress and poke at an app throughout its life cycle to end up with a better product. We do it because the rigor of experimentation and the fun of exploring are what drive us to pay attention to minute details and broad workflows. And in the end, our customer is the true beneficiary of our quality advocacy.

About The Author