Jenkins is the most commonly used automation service used in software development. In many cases it’s first installed locally to automate everyday tasks of application building with each source code commit and launching a regression test suite after a successful build. Later as automation matures it’s made generally available or bought as a service from some cloud provider. This being said, Jenkins is the industry standard for defining software automation steps.
Already for years, our Testdroid Run in Cloud Plugin has been instrumental for many mobile app and game developers to enable test automation with real mobile devices on the cloud. As a Jenkins user, Testdroiders have had a chance to launch their test runs from the the Jenkins jobs and results have been delivered back in minutes. This enablement has been a profound shift for many developers to jump on board with real agile workflow and make continuous integration work for building and automating tests.
On daily basis, many of you are using Jenkins as your Continuous Integration / Continuous Delivery system while developing your mobile apps and games. We’ve had a Jenkins support from the beginning of Testdroid Cloud and have constantly made improvements and enhancements in it to make your local test environment work even more seamlessly with our Android and iOS devices. In fact, Jenkins has been used quite a lot to build and test your app and game projects.
In case you are new to Jenkins or currently don’t have it in use, I’ll walk you through the installation and how to configure things with Testdroid Jenkins CI / continuous integration plugin for real devices. And this will only take few minutes!
Using annotations in Android instrumentation tests
The Android InstrumentationTestRunner allows you to filter test runs from the specific Java package or class, and in addition, you can also use custom Java annotations in your test methods to filter tests runs.
Just couple of weeks ago we launched a new blog series of how to build in-house test labs for mobile apps. This blog has sparked some serious interest and we’ll be sharing one use case how Testdroid is used with continuous integration environment.
Today’s guest blogger is Mark Rosenberg from Y Media Labs, a mobile strategy and application development company based in the San Francisco Bay Area. They work on all major mobile platforms, with a special emphasis on iOS, Android, and Blackberry app development. Y Media Labs specializes in every stage of mobile projects from initial planning, conceptualization, prototyping, design development, testing, and analytics.
The name of the game in today’s competitive mobile application landscape is a speed combined with robustness. The ‘speed’ means time-to-market and how early developers can publish updates to their applications. It is also a known-fact that the first ‘robust’ application in its own category at Google Play tends to stay on the top of download rankings – that will then expose app to hundreds of millions of mobile consumers. Those later entrants, competitors to this first application in market place are always challengers. What should they do to get attraction for their application?
The old rule-of-thumb with bug-fixing is simple: Fixing a bug today costs less than fixing that very same bug tomorrow.
Regardless from which point of view you or your customers/end-users are taking, bugs are evil and at the very core of why your mobile application or game doesn’t get those 100 million downloads from Google Play or App Store.
To get the most out of your testing efforts, the selection of the most robust and often cross-platform automated testing method is truly the best way to ensure maximal test coverage, on time and with great results. It’s a well-known fact that automated testing methods can be used for both validating requirements and reducing the costs of testing through automated test case generation. However, the full automatization of large software entities also has a cost that many companies haven’t been ready to pay for. Historically, one of the reasons is the recurring concern of the lack of adequate integration with well-established development life cycles.