April 2021 Product Update: Better ways to create Appium scripts & more
Adam Creamer
We’ll even give you some pointers for ensuring failure in a bit. But if you want to adapt to the massive changes and competitive pressures following the spread of DevOps and Agile, read on.
The embrace of DevOps, Agile and Test Automation is pushing testing teams to work harder, faster, smarter. In this post we will discuss some reasons for changes in the way people test, how these changes impact life for testing teams, and how you can build a fully automated testing engine that works faster, better and smarter.
First, what’s causing software testing to become so complex and costly?
Enterprises Spend 26% of their IT Budget on QA and Testing
Yikes. What the heck is happening???
The Product Owner/Sr. Test Engineer’s job description just got a whole lot longer, thanks to a boom in enterprise mobility, wearables/IoT – driven by more mobile sensors, No-Download/Insta-Apps, Security/Data Access Concerns – e.g., apps gaining access to other apps, AR/VR-based applications, AI in testing, Low code/No Code app development. So many more mobile apps to test, with markedly higher expectations for deployment times and fast bug fix times. Just perfect.
Unfortunately, this extra heat on testers means that fewer browsers are being tested, and incomplete data or time-consuming manual processes are being employed in a frantic rush to release faster. Most importantly, the communication gap between Dev and Testing is widening, which has pissed away time/budget which Engineering could otherwise use to improve software, rather than fix glitches.
According to recent survey, as of 2017, about half of enterprises worldwide are combating these challenges with automation testing and cloud-based test environments.
A fully automated testing cloud enables these organizations to find more defects early, communicate effectively between teams, deliver higher-quality apps (native, web and hybrid) without additional skill sets or code, and accelerate time to market.
What about the other half? Well, it makes us wonder…
#1: Create communication gaps between Dev & Testing.
DevOps strives to get the left hand talking to the right. With 88% of organizations having adopted DevOps or considering it, your opportunity to sabotage that effort is huge. Think of ways to shut down collaboration and communication between pre-production and production systems. There should be no visibility into configuration drift and no cross-functional Kumbaya. Build a wall. Make software testing great again!
There are platforms out there trying to take this away from you. Kobiton, for instance, uses a set of rich test logs and sophisticated test automation capabilities to keep issues transparent between Dev/Test so that the moving parts on both sides remain in sync. It even offers public, private, local and hybrid cloud options so that any size organization can use it.
This will only result in super-fast debugging and a successful release. Ugh. What’s even worse is that Kobiton integrates seamlessly with open-source tools like Selenium, Appium, and other tools your developers already know and love. Using a proprietary IDE/automation framework that is difficult to plug into existing environments will ensure maximum confusion and delay.
#2: Use more testing tools than you need.
Today’s mobile app testing platforms are getting irritatingly efficient. If you’re not careful during platform selection, you might end up saving a bunch of time and money for your organization. Kobiton, for instance, has a consolidated test platform for web, hybrid and native mobile apps. In the good ‘ole days, this would’ve required a number of separate tools. Now, testers can carry out a poop-ton of functions inside a single platform that costs a fraction of mainstream options AWS and Xamarin, in Kobiton’s case. Keep your eye on the prize here; if your goal is to @#*% up a release, more tools is always better.
Further, beware of mobile app testing platforms that kick ass in the integration department. Kobiton supports integrations with popular tools like Jenkins, JIRA,, etc. – and with various IDEs including Visual Studio, Eclipse, and Android Studio, which means developers can access their desired devices right within the dev environment and deploy their apps as needed. Not cool.
#3: Rely on speculative tests & incomplete data because ‘you didn’t have the time.’
In a recent worldwide survey, one-third of all app abandonment in 2017 happened because of Dev/Test-related issues. Well there’s an easy one; just use the excuse that your testers “didn’t have the time” to test on all browsers and all devices, only the most common ones.
Horrifyingly, some cloud testing platforms can capture automated and manual test scripts with remote access to real devices. Yep. You can easily execute tests and monitor test session details for websites, native apps and hybrid apps on all devices, even the devices you own. Kobiton automatically records your manual testing actions and stores them as test Session Details. With all the dirty Session Details at hand, complete with screenshots and videos, testers can resolve issues faster and know for sure that the app will behave well under any condition.
We can’t think of a better way to @#*% up a release than to ignore crucial test data and just make up your own. After all, the Dev threw it over the fence; it’s not your job to go the extra mile. Your job has always been to break stuff for developers. Now you can break stuff for Users, too! Embrace your inner Dr. Evil. Muhahahahaha!
#4: Fail to set up automated test scripts.
Make sure modifications cannot happen automatically within the app, but rather require updates to local servers. It seems unthinkable, but testers are actually out there doing this! While most testing clouds cannot support Continuous Integration and Continuous Delivery, some have CI/CD integrations that allow you to set up automated test scripts in the platform so that updates on remote servers happen automagically. Parallel automation execution with mobile testing tools such as Selenium Webdriver, as is forthcoming in the Kobiton product roadmap, will reduce the run time of your test suite and accelerate build times/release cycles. No bueno.
To ensure that new changes break old functionality that has already deployed, use a testing cloud that does not have a built-in test compatibility suite – such as Xamarin, AWS, SauceLabs, Browserstack, SOASTA, Keynote, etc. Your product will really suck and your team will hate you because these programs do not allow users to install, uninstall, launch and run fuzz on the app. They’ll need to go back to the local server every time there’s an update. And voila – maximum time and energy lost; maximum product crappiness.
We saw this happen recently with a very large financial institution. They failed to integrate their local testing environment with the Kobiton cloud (which is ridiculously easy to set up, BTW). When a change was deployed to a login feature on the web app, millions of users everywhere were locked out of their online bank account for days. Weeks, maybe. Engineering had to go back to the test scripts and make updates to the local server. Oh, the beauty! If only every release could go that well.
#5: Overspend on testing.
Finally, this one seems obvious, but just to be crystal clear… Pricing for mobile app testing clouds is all over the board, so be careful. If you want to exhaust as many of your resources as possible – leaving nothing to put toward improving product – Kobiton is not for you.
The cost of Kobiton is only 10 cents per minute compared to other brands that charge up to 55 cents per minute. People don’t realize it, but some of the most expensive platforms charge much more and deliver much less in terms of performance and configurability. For instance, some platforms do not allow you to include your own devices in the platform (that’s just about everyone except Kobiton). Or they limit the number of devices you can test to just a few hundred.
Kobiton charges an average of 30% below market on price per minute, with no hidden costs. Unlike the others, Kobiton does NOT count upload time for scripts, time lost managing scripts, or run time for manual tests (lag/latency in completing a test case) in its price per minute. Nor does it include carrier charges for testing network connectivity. All very common with most mobile cloud testing labs.
So go for it. Burn that budget, baby. People love surprises and your CFO will, too!
In All Seriousness
Hopefully we’ve made our point, even if you think we’re nuts. We’re not really (that) weird. But we are curious. If you’re one of the organizations that hasn’t yet tried Kobiton, why not? We offer the best performance and flexibility at the lowest cost, so you can meet increasingly complex build cycles faster.