Technology is changing every industry; we can all agree on this foundational premise. If you disagree, I believe the rest of this post is going to do nothing for you, so feel free to stop reading now. If you do agree, then you know that apps, the internet of things (IoT) and APIs are table stakes now. Businesses need strategies for each, and the forward-thinking executives are already adapting. The ones that aren’t risk alienating a channel in their overall digital strategy. It’s not all about strategies for building new types of functionality and partnerships; organizations also need to validate they will work specifically with their customers’ use cases in mind.
When we study software development, the history books teach us that waterfall strategies followed a linear path. In the past, this pace may have worked, but the future seems bleak with the evolution of technology and its disruption of traditional, manual business processes advancing at an exponential rate. Over time, the stages in the software development life cycle (SDLC) may remain the same, but organizations need to focus specifically on becoming more efficient at completing more work in less time. With this “do more with less” mindset, it’s no wonder many organizations see a backlog of work piling up. This point is especially true for quality assurance and quality engineering teams.
First, let’s unpack the software development stages from a traditional sense. Historically, organizations would get an idea and that idea could come from the businesses stakeholders (sales, marketing, customers, etc). The business would prioritize/stack rank all of their ideas by which carried the most merit and how much work those ideas would require for implementation. This is known as the “planning” phase. From planning, the idea would progress to be built. “Building” is the part of the life cycle where your artists/engineers live. You know, the creative people, the developers. They build the technology according to specifications that come from the planning phase. Most importantly, they are incentivized based on the project being delivered on time.
After the technology is built and packaged, it is passed on to the team that has been traditionally responsible for quality—quality assurance (QA). QA has their time with the product to validate the product works as intended, can scale to the appropriate demand levels, is secure and meets all the use cases without error before they pass it over to the team that will deploy it to the hands of their customers. Finally, the business is measuring feedback and customer sentiment, and then rolling that feedback back to the plan stage for improvement.
As time has passed, we have also seen another major trend develop. Organizations have developed agile/iterative SDLC strategies that are focused around bringing smaller chunks of functionality to their users/customers faster. Just like “lean manufacturing,” this concept has been focused predominantly around helping the developers get their projects completed faster. The primary challenge with waterfall development strategies is that by the time an organization brings the plan to market, the needs and priorities of the customer will have already changed. The speed of idea generation outpaces the execution of said ideas. That being written, while development has kept pace, quality has not, unfortunately.
Now I pose a simple, albeit, extremely important question: Who owns responsibility for ensuring quality of the finished product? If your answer is QA (like stated above), and I can see why that would be the instinctual response—the process is set up for failure. Here’s the fundamental reason why: if quality is so important to the process, then why is it the third phase in the SDLC? This implies planning and building without quality in mind is an acceptable process.
Quality should be owned by everybody in the process. QA/QE teams are your enablers of embedding quality throughout the SDLC. The distinction is more about instituting an ideology or culture based on quality.
With a culture focused on driving quality, when the planning team works on creating a specification for the idea, they should work with development and QA/QE as they are designing the flows, behaviors of the application. This allows for QA/QE teams to understand what to validate much earlier in the process. Teams are always looking for ways to factor more automation into the process. QA teams are also looking for ways to make their test environments more closely resemble the production environment where their customers interact with the business.
Unfortunately for QA/QE, they feel pressure from the business to execute within a constrained time frame with better results. This typically means inadequate windows of opportunity to start building automated tests or an incomplete environment that doesn’t quite resemble what the end user will face.
The last frontier to validate is performance which answers the important question: Will the app scale for the expected user population? This is often the last step before flipping the switch and shipping the product to your customers. But what happens if the application doesn’t scale? Organizations need to drive performance validation earlier. Better yet, they should engineer the application for the desired performance, and that means—yes, you guessed it—taking care of this earlier in the life cycle.
What if it were possible to drive more improvement?:
1. … To start building functional test plans and test automation at the time when planning happens?
2. … To ensure that development and test environments more accurately have access to the constrained downstream resources that cause unexpected “wait time”?
3. … To ensure that the automated testing that will be executed in the testing phase, has the right data to power the tests?
4. Finally, … to make sure that performance isn’t just an afterthought but a strategy to scale to the changing landscape of a digital business?
It’s more than possible. It’s obtainable. This process is known as continuous testing. It’s about the validation that needs to occur earlier—not just within a window of allotted time within an overall life cycle. It’s also important to understand that it’s a maturity curve, and it will take work to evolve your individual process.
Can your organization embrace continuous testing strategies? If not, what’s stopping you? If so, where can we begin to improve? Driving quality isn’t just about your company’s KPIs—it’s about your customers’ perception of your brand and what you do for them. You never get a second chance to make a first impression. Let’s build the right impression today!
