Co-Founder and Chief Solution Architect at PractiTest-Test Management. OnlineTestConf founder and chairman.
getty
Is there business value for the organization in the roles of testing and quality assurance? This question is becoming more relevant today as companies look for ways to streamline their development processes to release products faster, and "old fashioned" testing practices frequently serve only as unneeded hurdles slowing the team down.
Thriving in today's fast-moving environment.
You can open any industry report and see the adoption of DevOps and Agile methodologies increasing steadily across most industries and sectors. At the same time, we also see that both the service providers as well as their consumers are choosing to move to SaaS and mobile offerings for their personal and professional applications and services.
Another loosely related fact is that most products today have become extremely replaceable. To give you a personal example, it takes my kids less than a minute to switch from Netflix to Amazon Prime and then to YouTube when looking for something to watch, just as it takes me about three minutes to switch from Uber to Lyft if I can't find a quick ride home.
The same behavior is also apparent around the products and applications we use in our work-related tasks, with the barriers for moving being so low that, for most of us, they stopped existing at all.
Long gone are the days when companies would choose a system and stick to it for 10 or 20 years. Today, buying decisions are made with a three- to five-year usage forecast in mind.
How do organizations survive and even thrive in this dynamic and hypercompetitive environment?
They obviously invest many resources trying to keep ahead of their competition. Moreover, when looking at those companies making waves above their rivals, we see that a big part of their strategy relies on modeling how their users work and having a complete understanding of what makes them increase and decrease their usage patterns within the applications.
We don't live in the age of large releases anymore.
No longer are features only released once they're completed and finished, and we're no longer waiting for large versions and updates to be released only once every six or 12 months.
The reality of today's SaaS and DevOps ecosystems is one where we need to work based on a strategy of releasing minimum viable products (MVPs) to our customers, with the aim of understanding how real users react to the new features and changes and only then continuing to invest resources in the functionality around these validated ideas.
A similar approach is true for bugs, where we should find and fix only those issues that are critical and would cause real damages before releasing our products — and then have the monitoring and bug-fixing capabilities required to make additional fixes once these issues are found in production.
As mentioned by Dr. Mik Kersten in his book Project to Product, companies invest their time in either creating new features, fixing defects, ensuring security or closing technical debt. If we look at the average age of S&P 500-listed companies dropping from 60 to 20 since the 1950s, we can see that many customers, with their relatively low brand loyalty and their replacement options, should appreciate a company that releases more functionality and fixes issues faster over those that are more stable but with less innovation in their functionality.
Refocusing the aim of testing.
If we look back 10 years, the good testers in a team were the ones who brought up bugs that were relevant to our users. They would come up with realistic scenarios and not waste time on border cases with only theoretical repercussions and no business value.
This is no different today. The job of a tester is to provide business value by finding the issues that the team needs to solve before the product is deployed to production while understanding which areas and potential bugs are better left to be fixed only after they materialize in the real world.
The job of the tester is also to make sure the organization has the needed tools to do this, to detect issues as they happen and then to solve them quickly and with minimum disruption.
Quality past the bugs and fixes.
Returning to the idea of understanding how users work with a product and providing the functionality that will encourage them to use and recommend it more, we need to understand that fitness-for-use and alignment-with-needs are now seen by many customers as quality attributes, sometimes above stability and even lack of issues in the product.
In the end, the biggest factor determining whether a user likes our product or moves to a competitor is if they feel we are giving them what they need. The best way of understanding this is by measuring how users are working with the system.
We need to analyze what features they use and what features they don't, discover patterns and find the value streams within the system. Then, we need to enhance those value streams and either fix or drop the areas that are not providing value to our users.
Today, the job of the quality assurance person in a team has to encompass this new measurement of product quality. They must provide measurable proof and visibility into what users do with the system and how they do it, as well as demonstrate or refute the hypothesis of how a new feature increases the value generated to our users before we continue investing resources into it.
This is the way by which the new role of the quality assurance architect — that person we used to call the tester — can provide business value to the organization. Not only do they ensure critical bugs are found before we release our products, but they also help the whole organization understand the value we are generating for our customers so that we can invest in the areas where we increase this value. This allows us to avoid pouring resources into bottomless pits that will not generate any value to our business.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
