If you’re an online retailer, there’s a good chance you’re busy gearing up for the pre-holiday rush. Black Friday and Cyber Monday have been pushing retail sites to the limits of their ability to cope with surges in visitor numbers.
The weather, the tennis, the football — with all the distractions, you’d think those of us on the Real User Monitoring team would be kicking our feet up, right? Not a chance! I'm super excited to tell you about our latest release: a brand-new version of our Performance Trends Report.
On May 21, 2018, Bank of America announced that it was rolling out its chatbot, Erica, to all its mobile customers. On the surface, the premise makes sense. It’s making the bank more relatable. It’s providing real-time customer support to people where artificial intelligence (AI) assistants like Siri and Alexa are becoming the norm. It doesn’t have the limitations that some phone-based IVRs have, and it aims to provide immediate assistance instead of making us wait for a human (we’ve all shouted “representative” or pressed zero dozens of times to get a real person). Erica is a great way for Bank of America to optimize the customer experience.
But let’s pull back the covers and ask some basic questions. How does Erica know the customer so well? How does Erica pull from different sources of information? How does Erica know what products and services to offer? What systems, both homegrown and third party, does Erica need to be effective?
Quality assurance (QA) used to be a compliance activity. You were releasing a product and needed to test it and stamp it “approved.” QA was about testing that the code worked. You might manually test the code. You might have even tried some automation — coding a set of test scripts that would try to capture regressions or errors that you had eradicated in the past, but which somehow crept back in. All in all, you were reasonably satisfied that you achieved a level of test coverage that met your goals. Then, you put your code into production and crossed your fingers that nothing went wrong. And if it did, you tried to fix it as quickly as humanly possible.
It used to be that software testers could test their applications on just one platform, and only have to worry about testing that the code worked.
It’s no secret that the digital revolution is quickly changing the way businesses and customers interact with each other. Like Blockbuster, companies that don’t understand the evolving needs and tastes of their customers will die, while companies like Netflix that fail fast, quickly adopt technology, and evolve, will thrive.
This week, I'm making what many consider a life-altering, religious change. I’m switching from Android to an iPhone.
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.
Note: Test engineers Reena Kuni and Jeannette Smith also contributed to this blog.
We recently co-hosted a webinar with Bloor Research about the Future of Testing, and in it, we conducted an informal poll about artificial intelligence (AI) and testing. When we asked what everyone thought the biggest advantage was to incorporating AI into a test automation strategy, attendees overwhelmingly selected team productivity and efficiency.