On June 18, many Google Calendar users worldwide got an unexpected surprise when logging into the app—an error message. The issue was resolved approximately three hours later but, as anyone who lives and dies by their calendar knows, three hours is plenty of time to wreak scheduling havoc. The same day, restaurant chain Taco Bell also made headlines for tech issues, when heavy traffic in response to its free Taco giveaway caused the app to crash.
Eggplant Blog
This week, I'm making what many consider a life-altering, religious change. I’m switching from Android to an iPhone.
Pop the Champagne and celebrate with us! We're honored to be named by Gartner as a visionary in its 2017 Magic Quadrant for Software Test Automation. More specifically, the report recognized our technology-agnostic, cross-platform, automated testing approach that focuses on the user experience. Dowload your complimentary copy of the Gartner MQ report.
In my last post, I described a test team structure that I've seen several companies (which I think are real thought leaders in testing) successfully implement over the last few months. Included in that structure is the sometimes controversial statement that scrum teams should have dedicated, professional testers; that is, we shouldn’t make developers responsible for all testing (though they should be responsible for white-box unit testing).
How should we structure our test team? This is probably the most common question I hear when talking to test leaders about what's on their minds.
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.
You can find 28 million apps on Google Play and 22 million in Apple’s App Store. Yet, nearly one in four people who download an app use it only once. Apps are incredibly slow under certain circumstances, don’t work in key parts of the workflow, and have less-than-optimal usability. The app scrap heap is growing because many organizations are still testing to ensure code quality, not a superior user experience (UX).
A new study of 600 testers reports that 91 percent of test teams are struggling to meet increased user expectations compared to 12 months ago, and 66 percent said that test automation needs to expand beyond just test execution to keep up with business demands. The new study, conducted by Kickstand across the U.S. and U.K. on behalf of Testplant, generally identified that app dev teams are feeling the pressure to innovate and deliver high-quality user experiences quickly.
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.)
A lack of environment management is one of the most common reasons for unreliable test execution. People remove devices from the test environment, change app versions without notification, change OS settings, two tests try to use the same devices at the same time, a manual tries to use the same device at the same time, a backup runs on the middle of a test run, insufficient user data is provided, and the list goes on.