In some cases, a client will know exactly what they want from an Android app testing project and this will help to define the project from the start. On the other hand, a client may come to me and say ‘test my Android app’, in which case, further information is required to find out the required scope of the testing project.
In order to define the project, we can discuss requirements via email, phone call, Skype call, Slack chat, MS Teams etc.
The aim here is to agree what the testing should focus on and on what devices the testing should be carried out on.
Other factors to consider are scheduling, the app delivery method to use, also where issues are to be raised and how test results are to be reported.
At this stage, the Android App is tested, according to the Project definitions and the device list agreed on. This will include all the testing types agreed on, plus the appropriate amount of Exploratory Testing to unearth bugs which may otherwise be left lurking in the Android App.
Issues are raised as they are found, in the method agreed: this could be in your own issue tracker – such as JIRA, DoneDone, RedMine etc – or within an Excel document, or perhaps a Google doc, or, where applicable, within my own hosted JIRA issue tracker.
Test results can be reported in many ways and the method used will often depend on the length of the test project. For example, a short half-day test could be reported on in an email that summarises all the results, whereas a longer test could be reported on in a full Test Summary Report.
A Test Summary Report includes sections such as Overview, Main Findings, Gap Analysis, Deliverables, Testing Types Performed, Test Devices, Bugs Statistics and Summary of Main Bugs.
At this stage, we can discuss if any further testing is required.
This may include further focussed testing, retesting of fixed issues, regression testing after changes or any other type of testing.
Other testing types I perform: iOS App Testing, Website Testing