Sometimes I feel as if I’m the Forrest Gump of quality assurance (QA). Since 1998, I’ve been through the beginning of automated integration testing and service virtualization through being a co-founder of Class I.Q. (now IBM Greenhat). I’ve been through the first phases of an automated testing center of excellence (ACOE). I’ve been there for the start of risk-based testing, and I’ve been a part of the transformation of QA from a somewhat necessary function to something that is now the core and chief concern of any company putting out quality software and apps.
Most important, I can remember advocating taking QA from a stagnant phase of the software development lifecycle to shifting left and making it a part of PMO task and charter reviews. Then, as that started getting traction, I advocated for pushing QA right so applications could work well together and get to production faster. Shift left, shift right, ACOE, COE, federated testing models, parallel computing, cloud. We’ve even changed the names so that they sound more assertive and developer-oriented, like quality engineering and performance engineering. The names and initiatives have been different, but it has all revolved around making sure the applications meet business and technical requirements like they should in the fastest way possible. Lost in the mix are the traditional terms that started it all: QA and quality control.
A couple of years ago, a mentor of mine recommended that I get out of QA. I remember the conversation well. The last thing you want to do in midcareer is to be stuck in QA. So, taking his advice, I got into digital monetization. This was an eye opener for a number of reasons. Instead of looking at how software was being tested, I was looking at how it was being used. How the most critical of business functions (getting paid and providing great customer service) was actually defining how IT was done. I got to see internet of things (IoT), edge computing, facial recognition. I was able to look at how artificial intelligence (AI), and cognitive computing were starting to anticipate customer behavior and driving business decisions through analytics.
This got me thinking.
I promise, dear reader, this is all going somewhere.
Shift left and shift right were new, breathtaking, and needed, primarily between 2006 and 2014. That, according to what I’ve seen, was the growth, peak, and descent of both movements. Yes, transformation initiatives are still being spawned. Shift left and shift right are still adding tremendous value. Companies are still experiencing tremendous ROI from implementation; consulting companies are still making loads of money implementing transformation programs.
But in 2018, shift left and shift right are table stakes — they’re great if we only care about releasing flawless software quickly. They don’t take into account all of the advances in user experience, user delight, the focus on net promoter score (NPS) or customer service. Shift left and shift right don’t take into account the mental state or physical movements of a 75-year-old person at a scan-and-go cash register vs. that of an 18 year old with 6 social networking accounts.
We need to revisit the work of Frederick Winslow Taylor and Maslow. We need to integrate subjects such as chaos theory. We need to look at the behavioral, cultural, emotional, and physical states of the person trying to interface with the application or system. We need to understand the strategic business outcomes. We need to understand if the organization building the application wants a transactional or persistent relationship with the customer.
We need to shift up.
Shifting up is really looking up from our focus of getting further left in the IT value chain or getting further right and getting the application to production faster. It is listening, advocating, and accounting for your customer. Doesn’t matter if it is a B2B, B2C, C2C, or C2B relationship. Applications mean everything to the financial well-being of a company dependent upon or transitioning to digital.
It’s taking a look at people, process, and tools from a fresh perspective. There are tools out there that will validate against UI standards. There are companies that will find people with a certain target demographic and have them test against an application, prerelease. Neither of these approaches simulate user behavior. For that, we need to integrate machine learning, AI, and cognitive computing, among others, into the mix.
This is one of the reasons I went to work for Eggplant. The Eggplant Digital Automation Intelligence Suite is driving this shift-up approach. Like a suspension bridge, where the base, span, and suspension framework work together to create a strong bridge, so does shift up require shift left and shift right to create an even stronger, holistic approach to QA.
Being able to simulate real user interactions, behaviors, and emotions is key. Not just to build out software that’s appealing, but in moving QA to the corporate boardroom where new strategies can be simulated to determine if changes will create the desired business outcome.
Software being flawless and correct is now considered the norm by your customer. Now we need to ensure that every interaction your application or system has with your customer satisfies their physical, mental, and emotional needs. We now need to ensure that your application or system supports your company’s desired business outcomes.
We need to shift up.I’d love to hear your thoughts on the topic. We’ll be at STAREAST (April 29 to May 4, 2018), booth #302. You can also leave feedback in the comments. I’ll be writing more about shift up in the coming months.