Lack of communication is often cited as the biggest problem Business have when implementing DevOps. This would be communication between co-located teams where the team just doesn’t talk, teams across geographies where time zones come into play, even where the IT and Business just will not discuss things. Indeed, there are many places where a lack of communication can cause DevOps to fail.
On July 23, 2019, Antony Edwards, COO of Eggplant, and Diego Lo Giudice, VP Principal Analyst at Forrester, conducted a webinar on “Putting Intelligence into your Continuous Testing.”
Daniel Priestly points to “Illusion of Limited Resources” as the number one limiting factor to holding you back from becoming a Key Person of Influence. It is the same fallacy that holds organizations back from progress.
Forrester has recently heralded the rise the of the ‘Business Tester’ in response to consumers increased demand for flawless digital products. We believe this is more than just a trend, it is an uprising!
Click. That’s the sound of a customer seeking out your competitor because your point-of-sale (POS) system didn’t deliver the experience they wanted or expected. You know that your QA teams tested the code and it worked. So, what happened?
It’s not often you hear dev teams shouting from the rooftops about a relatively minor software release. (Actually, developers rarely shout in the first place, except when playing a lively game of foosball.) But we think this one is pretty cool.
We recently commissioned a study of 750 development team leaders in the UK and the U.S. to gauge the extent of the pressure today’s organizations are experiencing with respect to app development. On the same day that we announced our App Gap research results—revealing that almost half of businesses feel the pressure to launch often untested apps—we hosted the first in our series of our Digital Automation Intelligence Roadshows.
TestPlant released eggPlant v16.1 this month, and I’m writing to talk to you about my favorite of the marquee features: support for Gherkin, the language of the Cucumber BDD framework. (Cue the vegetable puns!) Throughout our internal beta and in our v16.1 webinars, I’ve heard some great questions about Gherkin and our implementation of it that I’d like to share here. (I will also unabashedly share my preoccupation with Pokémon Go.)
Some of you may have attended our “Getting Started with Performance Testing” webinar a couple of weeks ago. The event was such a success, we’re doing it again! For those of you who missed it, make sure to sign up for the next session here. In the meantime, I’ll give you a taste:
In this webinar, we will run through the basics of performance testing. For a lot of folks just introducing test automation into their company (or even those who are already doing functional test automation), performance and load testing can be daunting.
To help alleviate the stress and clarify some first steps, we decided to run this webinar to help break down the basics for getting started. Steps for getting started include planning and preparation, test architecture, constraints, test creation/ recording, execution, and results.
I recently presented at the Northern Lights conference in Manchester. This conference was hosted by the BCS (British Computing Society), and my talk was “Tools. Techniques. Trouble? Why test automation is getting more difficult, and what can be done about it.” You may have seen my blog post from ahead of the show, but if you haven’t yet, you can find it here.
I focussed on automating user interactions with the System under Test (SUT) and automating the creation of test scripts but not the automation of the testing process itself. I addressed both functional and load testing.
For those who weren’t there, here are the key points that I covered in my presentation: