In the last year, iOS took the prize for the glitchiest platform on the mobile market. The National Vulnerability Database dropped a bombshell by reporting it to have almost three times more bugs and flaws than Google Android! Crucially, in 80% of cases, 3rd party applications are to blame.
The mind boggles.
If your business is related to iOS development, you surely don’t want your app to join the hall of dishonor. It’s better off to weed out as many bugs as possible as soon as possible, both reputation and cost-saving wise.
Find out how to make your test cases super-efficient with these guidelines.
1. If you can’t test it, you need to change it
There is a saying among developers: “It’s working as coded”. We’d like to expand it to “It’s tested as coded”.
Here is the hard truth many can’t realize: There is no such thing as untestable performance. If you find yourself being puzzled by how to test any of your app’s features or behaviors, you have to ask yourself two important questions:
- “Why can’t it be tested?”
- “What should I change to make it testable?”
Maybe your code is too complicated. That’s when you need to refactor it.
Is it because your classes are too big? Coding gurus suggest the developers of mobile apps to keep their classes as short as 150 lines each. Besides, check that your methods aren’t overloaded with actions, and divide them if needed. Your tests will become dozens of times more effective. And you’ll see which exact procedure fails particular verification.
Were you overly excited by the breath-taking solutions and features you were keeping in your head, that now your app code looks like a bowl of spaghetti?
Then you need to bring some structure, make it more legible and neat—not for the future users of your software product but for your own good.
Users will see is the eye-candy: the app’s interface, shiny features, and trinkets. It’s you who will be dealing with all the ugly stuff under the hood when it comes to post-production and patching. And since you have troubles as early as on the pre-launch testing stage, imagine all the gore of supporting an app with code that messy!
Don’t be lazy today for the sake of saving time and nerves later.
2. Stick to 3 SOLID rules
There are several golden, time-proven pieces of advice on programming and design that a lot of young developers forget to follow. All that knowledge is gathered under the easy to memorize acronym – S.O.L.I.D. It stands for single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion.
Speaking of quality assurance, S, L and D are the most useful letters of it to make your test cases solid:
- Single responsibility – each of the classes of your mobile app must have one and only one responsibility.
- Liskov substitution – you should be able to replace the objects of the app’s code with other instances. Use mocks to test a specific action of objects.
- Dependency inversion – in the case of iOS, the best idea is to divide a class into several parts and test them independently. You can do it by using protocols.
3. Test it in the field
Emulated testing is arguably the most convenient and fast approach to walking through all the potentially weak places of your app. But it won’t do the trick for eliminating bugs and nasties that are related to physical device usage.
You must run the tests on real iPhones or iPads to spot the critical vulnerabilities mobile app users may face.
- Test how your iOS app performs offline, as well as how it works under low network speed;
- Check your app appetites: how fast does it drain device’s battery, how much data does it use, how much memory does it consume. If your product is too greedy with the owner’s device resources, it won’t be welcomed;
- Ensure the app’s agility and responsiveness. It has to look consistent throughout different screen sizes, screen resolutions, and window expansions.
4. Don’t try to automate everything
“It’s automation, not automagic” – the software testing veteran Jim Hazen says. While automating your test cases is a decent, sound-minded approach, don’t abuse it, and don’t rely on automation alone.
The best practice is to mix both automated and manual techniques all along the testing process since each of them has its strong points and its weaknesses.
When planning your app test drill, bear in mind that:
- Automated tests can’t evaluate user experience. It won’t be able to spot the nuisances that may become a turn-off for your future customers. Your product will be used by living human beings, not
- Pesticide effect is a well-known issue in the QA world. Automated tests become less effective the longer you use them, and eventually, the costs you invested into them stop paying off. The longer you go through the same test routine, the more suspicious you have to be towards its effectiveness.
5. Master your tools
Don’t be shy to use the ready solutions to check how your app performs and responds to user input. In the iOS universe, we’ve got two amazing frameworks for testing in a behavior-driven development fashion:
- Specta – a spectacular library for Objective-C, which makes writing unit tests effortless.
- The younger brother of Specta; well adapted both for Swift and Objective-C – the Quick framework.
To escalate your test cases’ effectiveness you should also add some of these apps to your testing toolkit:
- Calabash – feature-rich platform for testing native iOS and Android application. It provides a massive number of libraries. You can perform user-end tests, take screenshots etc. The cherry on top—it’s free and open source!
- Appium is a great framework for test automation. It suits both native and hybrid app In the case of an iOS app, Appium will drive it through the WebDriver JSON wire protocol. This tool is open source as well.
- Frank is yet another handy tool that also allows you to run parts of tests for the iOS-based app while it’s still in the course of development. You can use it for creating acceptance tests and creation of requirements with some help from Cucumber.
Now, with a handy list of tips and tools, you can be sure that the customers of your iOS app will not be finding the bugs before the QA. Good luck!