How much Flutter Integration Tests can save you in costs.
Flutter has been consistently popular among developers because it provides an ability to ship beautiful production ready apps faster to users.
Despite the abilities of the framework, teams building with Flutter still face a deep rooted challenge of every software development lifecycle. And that is testing.
How testing is a big bottleneck in the development process?
In any software paradigm, testing comes coupled with every iteration of your code. Whenever a feature is added, dependencies are upgraded or an update has to be deployed, testing always has a major role.
Unfortunately, most teams today rely on manual testing which is slow, costly and still unreliable. Most devs are familiar waiting 2–3 days for a build to be tested and yet ending up with bugs in production.
This is where automated testing comes into picture. Automation tests, aka Integration Testing in our case can help you efficiently test all of your app features across multiple devices within a matter of minutes.
With Integration tests in place, you can iterate faster and release with confidence. Let’s do a deep dive to understand how much can this save your team in costs.
How much integration tests can save us in costs.
For fairness, we will be measuring costs in time and efficiency. Every team has their own costs to those, which could be calculated by filling in the respective (x, y and z) factors in the spreadsheet at the end.
1. Costs during building/updating a feature.
Developers after writing code, spend a majority of their time manually running the flow in an emulator. This creates a long feedback loop that can on an average take 15 mins per iteration.
With on an average of 7–8 iteration for a day worth of feature, 2 dev hours every day get lost in testing alone.
These iterations also take huge cognitive load which decreases developer productivity further. It takes 7 days to finish features which otherwise would have taken 5 days. This is how it reflects in hours lost and efficiency in a (2 weeks) sprint:
2. Pre-Deployment testing costs.
Once all development is done, usually 3 days per sprint is spent testing the feature and fixing the reported bugs. This is in the best case scenario where bugs are minimal and fixing don’t stretch to the next sprint cycle.
This time could be reduced to less than a day with automated tests in place. Here is how it reflects in further costs and efficiency per sprint.
3. Costs of bugs reaching users. (unexpected but often)
Even with considerable time spent in manual testing, it usually is still not enough to regressively test all possible cases. This leads to certain bugs making into production.
The entire team to now assembles to push a hotfix which takes precious hours of not just developers and QA team, but product managers and other stakeholders as well. This also induces delays starting the next sprint and pushing of critical feature timelines .
Looking at the actual reflection of the same:
This is excluding the cost of losing the trust of your users, which is invaluable.
Making the final calculations.
For a 2 week (10 days) sprint, teams end up spending 12 days for what could instead have been accomplished in 6 days. This is operating at 50% efficiency.
Evidently, teams can achieve a lot more by saving these wasted team hours by switching to automated testing. The saved developer hours and focus could be utilised to solve bigger problems critical to the product. You can ship features at double the velocity while ensuring a stable bug free user experience always.
Hope this article was helpful. Please find the spreadsheet here. You can fill your respective costs and team size to calculate how much costs will you be saving.
