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.
Some of my customers are trying to design an automated script to perform specific workflows with a predicted outcome. Unfortunately, the automated workflow they want to execute has many variations in their environment, and they’re having trouble creating a dynamic, automated script that handles environment deviation.
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.
This week, I'm making what many consider a life-altering, religious change. I’m switching from Android to an iPhone.
Everything about software has changed—how it’s architected, developed and produced, what it does, what users want from it, and how often they expect new features. To keep up, organisations are turning to continuous delivery and DevOps. Yet product teams still do a lot of manual testing, which consumes a lot of time they don’t have, thanks to shrinking test windows. Incorporating automation into your testing approach is a great strategy, but figuring out where and how to start isn’t necessarily quick and easy.
This blog is only partially about our newest iOS Gateway 5.0 release with device and simulator support for Touch ID and Face ID (which is super cool, but more about that later). It’s also a blog about how testing has changed — a lot — in a short amount of time.
A new outlook, optimism, and wonder. For me, the start of the new year is always exciting and prompts a lot of questions about how our space and our solutions will evolve over the next 12 months.
Selenium is a popular open source test automation tool for lots of reasons. You can get started with it quickly. It’s widely used, so knowing it can be a marketable skill. And, because it’s not that easy to use right out of the box, testers who become well-versed in Selenium can advance into lucrative framework development.
In the past few weeks, I’ve been getting daily emails about early access to retailers’ Black Friday and Cyber Monday sales. Which got me thinking about two things: one, I hope retailers are prepared for the even earlier onslaught of online traffic, and two, the high stakes for site performance on the two busiest shopping days of the year.