The application quality has a direct relation to the long-term success of your app. This can be measured in terms of a number of installations, user ratings, their reviews and engagement, and eventually user retention. Today’s app users expect high-quality apps and even more so if they spent any money on those.
A better app can go a very long way and the formula for the success is relatively straightforward: your better quality app will translate to higher ratings, that translates to better ranking, that translates to better visibility in the app market, and eventually gets your app more downloads. This cycle of impression-installation-ranking speeds itself up, and your app either ends up being awesome or – awful.
In this blog we’ll take a look at some of the testing tips and tricks that can make the difference for your app. We’ve discussed quite a lot about the importance of test automation, starting testing as early as possible during the development, and using the most robust platform for testing – those real devices. This time we’ll focus on getting your test cases right – not only in size but also in coverage.
When something fails in your huge test case all of your tests can fail. With smaller entities, results will be separated and some test cases will go through.
WHY SMALLER TEST UNITS ARE BETTER?
Some people are the fans of huge, highly detailed and all-covering test cases. For some types of apps those work, but it takes some time to create and maintain those types of enormous test cases. Three things should be considered when figuring out the best types of test cases for your app:
Smaller test cases are easier to create, maintain, read and modify
Smaller test cases can boost the creativity of testers. Smaller, focused test cases are easy to produce and maintain as the focus of those test cases is limited compared to large ones. Inputs and outputs are also simple and failing any part of the test are easy to observe. Also, smaller test cases are easier to debug and also understand by less tech-savvy team members.
The scope of testing is more accurate with small, targeted test cases
Those test cases are meant to be small and can be quickly created. The number of test cases is high while the outcome of one test case can seem irrelevant. However, combining these results can give you much better covered overall test of your app. For this, you need to create a lot of those test cases.
Small equals for better reusability and easier to extend your arsenal of test cases
Ideally, test cases should have full access inside an application and test all aspects of it: memory contents, data tables, file contents+system, and all internal program states to determine if the app is behaving as expected. For these, smaller test cases work better as they are focused on a certain aspect of your application. Those smaller test cases are also easier to reuse – directly or with modifications – as there are fewer dependencies to other resources.
PREPARATIONS FOR SPLITTING TEST CASES TO SMALLER UNITS
Smaller unit tests can ensure that your app gets thoroughly tested and works as intended. Despite you do significant refactoring those smaller test cases are more likely reusable and are ready for testing. Having a high number of test cases also means better coverage as anything can go wrong in large test cases and the rest of the test is not valid anymore. Here are some preparations to consider:
Plan – And Split!
There is no need to overlap or complicate your test cases. Before jumping into implementing those, plan your test cases and split them into scenarios. Every scenario should be created in a separated test method. As far as possible write your test cases in such a way that you test only one thing at a time. This will significantly help to create well-targeted, accurate and reusable test cases for your app.
Get Your Test Cases “Atomic”
A well-written test case could be described with five characteristics: Accurate, Efficient, Traceable, Repeatable, and Reusable. As long as we test only functions or interactions with no side effects, the creation of those test cases is really easy. Then it can get more challenging when your app has side effects but nevertheless, smaller is always easier to handle, implement, get rid of unused scenarios and is also faster.
FIRST – Fast, Independent, Repeatable, Small, Transparent
Your test cases should be very fast to implement and execute. All of those should be independent as well and easy to be repeated. Repeatability also means that your test case should be ready to be executed at any time and doesn’t require any other test case. Also, the result should be always the same – no matter how many times executed, what are preconditions and so on. Smaller test case also makes your test more predictable and obvious for what purpose it was created.
As an old compiler guy, shorter, smaller test cases are obvious to me. Smaller test cases have made the testing so much easier – despite the number of test cases can be sometimes huge. Nevertheless, smaller test cases work better in today’s mobile apps. As a summary:
– it’s easier to handle smaller test cases (finding bugs, fixing tests)
– it’s easier to get rid of unused scenarios
– it’s easier to focus on just one thing at a time (test case should test one simple functionality)
– small test cases are faster, so users can more quickly focus on failed ones
– it’s easier to make them test independent things
– the code is cleaner as users have an organized structure of their test cases
To learn more about this, please take a look at resources here.