Functional testing is fundamental to any mobile app testing regime – it is testing that the software works as it should. Testing that the design and requirement specifications have been met. This is testing created from the perspective of the end-user of your app.
Note that this post is not about individual platforms or vendors or automated vs manual testing, but best practices that can apply to all environments. With that said, what are the best practices for functional testing?
- Collaborate on the requirements for testing
This is vital. Without being clear on what needs to be tested, there can be no test plan. And without a test plan, there should be no testing.
It may sound obvious, but best practice is not to work out the requirements in a vacuum. The development team (and the Operations team if you’re in a DevOps scenario) will have a handle on which user commands, integrations, processes and screens that will be most critical. And from that collaboration, you can start to work on the test plan.
- Create your test plan and prioritize your tests
It is surprising and worrying that we sometimes see this step missed out entirely. The test plan is not a boring thing where you write down what you already know. It is a plan for working out what you will actually do. The hard work is typically the mental gymnastics that goes into the test strategy, rather than physically writing it down.
Briefly though, a best practice testing plan should incorporate the objectives and scope of testing, the test resources required (including people, software tools and hardware), as well as a test schedule.
Also in the plan, prioritize and rank the test cases that will be developed. Not every test is of equal importance to every other test.
- Determine what can be automated
This could just as easily be considered to be part of the test plan creation. However, it is so critical to monile app development and testing strategies that it deserves its own section. Simply put, automate as much as you can.
Testing automation is there to improve software quality while reducing time-to-market. But be sensible about what you automate. That means, do not automate things that a manual tester could do more cheaply or more effectively.
Having said this, think about the long-term. While test automation may cost slightly more in the short-term, the long-term financial benefits can be significant, even massive. As a guide, we have found that with the right support, most enterprises can comfortably automate 80% or more of their testing.
- Execute your tests under real user conditions
With mobile app development, more than any other type of development, find a way to test under real user condition. Web developers don’t have to concern themselves with what happens when you go out of data coverage or what happens when you receive an SMS, but you do.
Of course this does make the number of test cases larger, but that is just the way it is in mobile. And going back to the previous point about test automation, it will be incredibly helpful to have it in place when you start to look at the functional requirements under various app conditions.
- Manage defects with appropriate sophistication
At a basic level, an issue tracking system will help any team with the simple task of centralizing the test repository. It can help with the assigning of the tasks, and can provide a simple one to one relationship with an issue or bug and its test case.
Depending upon the level of sophistication in your organization, it may be enough. Though in a more sophisticated scenario, where there are multiple configurations, different workflows and different data sets, the issue tracker is unlikely to be sufficient. If this is your situation, investment in a mature mobile test management system will be required.
- Make reporting your results simple
In theory, the management of results should be one of the easiest elements to handle in the process. Though this really depends on the test management tools that you use.
A sophisticated test management system will make the abstraction and presentation of test results very straightforward. It will be done for you and a dashboard will be available to stakeholders at any time.
Meanwhile an Excel-based system will typically require hours or even days of admin with formatting at reporting time. In an Agile set-up, a distinctly un-agile method of reporting is hardly the right fit.
Overall, whatever system you use, the reporting element needs to communicate both the status and progress of testing, in a way that development and management can understand. And it needs to pave the way for useful analysis…
- Analyze your test metrics
Again, depending on the sophistication of your testing or the scope of the project, this can be a smaller or larger task.
In a much smaller set-up, the analysis requirements are simpler. It won’t go far beyond presenting what has been tested and what doesn’t work.
In a sophisticated operation, the analysis should highlight problems and opportunities in both the development and testing processes themselves. This can be the source of constant improvements to ensure the operation becomes much smarter over time.