How and Why We Moved to A Faster Release Schedule

Bitbar, the mobile devops company. Logo, large

Dear Testdroiders,

As we advocate an agile development and practices for any kind of mobile development, we would like to share with you some fundamentals and our thoughts on how we’ve built our products, what kind of processes we use internally to get things done efficiently and what has increased our capability to faster build and deploy new versions of Testdroid. This being a broad topic, let’s start first with a glance on how we changed our internal doing into yet more agile doing – enabling us to do faster releases. The part of that is agile process, agile regression testing and test-driven development approaches. Let’s deep dive into details!

Agile Regression Testing for Mobile Apps, Games and Web

Testing online cloud service – like Testdroid Cloud – isn’t that much different of how you test your mobile apps. Basically, testing mobile app software is pretty much the same: front-end (UI) and back-end (service, OS integration, HW integration etc.) can be tested with the same elements, frameworks and tools we use here at Testdroid team. Naturally, a big exception is the enormous farm of devices we host at Testdroid Cloud. For this we’ve built sophisticated monitoring system that makes sure up-time for each device would be close to 100%. Our DevOps team will explain more about this in these Testdroid Team Insight blogs during the year, but before that, let’s discuss a bit about our processes, our testing approach and how we’ve managed to utilize agile process to get features delivered to you on a bi-weekly basis.

Whenever developers change or modify their app software or logic, and we’re talking about even tiny tweaks in there, some unexpected consequences can occur. Testing mobile apps can be done in so many different ways but the goal eventually is the same: to ensure that a change or an addition to app/software hasn’t broken any existing functionality. That’s called agile regression testing and in these regressions a new build or release candidate must go through a serious testing pattern.

By running these test scripts again, again and again against each release we make sure that any new changes to our products haven’t resulted in a regression. First, something about the release schedule.

What We Learned from Moving to a Faster Release Schedule

Testdroid Cloud release process used to be rather slow – an almost one-month development cycle was followed by a lengthy testing phase before the release. Typically a release then was followed by several days of debugging and patching as bugs were found in production. This was shown in maintenance notifications – primarily in Testdroid Cloud – but the service was usable all the time.

The pros of patching releases of course is that you keep the service online all the time, up-time is maximal and people can carry on with their mobile app development and testing tasks as usual. However, there are cons in this kind of release-patching-another-release approach as well. For instance, the service may not be complete and provide full power of all features instantly. Some features and new things are even considered as bugs – and that’s actually where more faster release schedule can help.


Currently our product is released about every two weeks and release is over in a few hours before launch time. Changing to a faster release cycle has taught us a lot but there is still a lot to learn. Here are some of the findings in this shift and also some thoughts on what we’ll be trying out next.

How Test-Driven Development and Regression Testing Work for Us

Moving to faster release cycles brought some expected challenges but also some unexpected obstacles that we are still working on currently to create new cool features to our customers even faster than now.

Our Testdroid Cloud user interface is a very independent component allowing us to make major changes to the front-end without a need to make changes to our back-end. As significant majority of the logic is in the back-end, front-end changes should fully expose all those changes, improvements and add-ons we’re pushing for each release. This is naturally challenging and ever-changing front-end isn’t really great from the user experience standpoint.


How does the agile approach help us here? Well, again, it’s very important for mobile app developers but also for us, Testdroid developers and testers that even small changes to the front-end or back-end code can break things in pieces. The agile regression testing is highly important and as everyone knows even a little thing can break functions that seem completely unrelated to the recent modifications / regressions. When we run our regression tests, we always check and ensure that our modifications not only behave as we want them to, but that it also hasn’t inadvertently caused any issues to other parts of the product. Not a small thing, but test automation provides a fantastic foundation to spot these issues right after the staging build.

It was anticipated that releasing often would bring us challenges in keeping our test automation up with the new release schedule. To improve our automation process we now write our requirements using a test-driven development (or TDD) approach. The requirements feature files can be executed with minimal updating by the testing team using Python’s Behave test automation framework. As test automation improved, additional effort was put in getting testing environments (integration, staging & acceptance) also configured automatically.

With a slower release cycle, documentation was updated in separate mini projects where the user documentation was updated to match the current running version of the service. The documentation would stay valid for some time or would even be forgotten as it was not part of the release process.

Agile Regression Testing and How it Serves Our Customers


Clearly, we’ve had some issues with our product documentation. It’s been distributed all over the places – Testdroid pages, blogs, help and some other forums. So obviously something needed to be done to maintain our online documentation. This time we are trying out an approach where documentation is part of the definition of done of each feature. Everyone in the company, or outside the company for that matter, has the rights to propose updates to the documentation. Currently it is not yet online, but as soon as it has been used for some time we’ll blog about how it’s working.

New release cycle has increased the communication needs from product management perspective towards other parts of the company. There is a constant need to advertise the (smaller) features that are coming out. Big features get built from smaller stories, each of which is valuable to the end customer but also for sales and customer support too.

In retrospective it seems obvious but we didn’t realise that having faster and smaller releases will slow down our internal development. We give customer requests greater priority compared to internal requests in our feature backlog. As a consequence some of our important internal development tasks have been delayed. We are still learning how to balance between internal and customer requests.

What is Next

Overall the benefits of a faster release cycle have been great. Stress levels have gone down at all levels of the company. Smaller stories are less risky and better understood by all. The number of mishits has dropped greatly. Automation at every stage is key to success and brings confidence and stability.

Our roadmap includes continued improvements in creating and testing releases such that each single feature can be released independently as it becomes ready.

Also, please let me / us know if there are any future features or issues you’d like to see as part of the Testdroid product family. Please email me at niko dot cankar at bitbar dot com to discuss of features you’d like to see in the future releases and I’m more than happy to discuss with you on those requests.

Happy Testing!

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.