Testing iPhone and iPad Applications

by tmhr consulting

Share it now!

In our last blog post we outlined the trials and tribulations of a recent iphone/ipad application development project. This week we are going to expand on that article and share our process for testing new ipad/iphone applications.

Testing applications can be a very daunting task and user testing can be especially troublesome. During the testing you are assuming that the programmers have written their code efficiently and that you are only testing that the functionality is working correctly.

ipad application testing

Here the Listing of the schedule items is being over lapped by the last three selection items. This is the type of things we want to find during our testing.

The good thing about testing iPhone and iPad applications is that you do not have to worry too much about multi-user functions because for the most part only one user will be using the application at a time.

Functional / User Testing
Functional/user testing entails making sure all the processes exist, all the entities are there and that the navigation and displays are as efficient and clear as possible.

Application Entities
For Correct Pills we have a number of entities:

  • Patient
  • Prescription
  • Medicine
  • Schedule
  • Medicine Renewal
  • Doctor
  • Pharmacist
  • History

Application Processes to Test
So during our testing we made sure that you could do the following processes:

  • Add, change, delete the Correct Pills Entities.
  • Keep track of the entire life cycle of the patients prescriptions Compare medicine to renewal of that medicine.
  • Keep track of different medicine taking schedules.
  • Keep track of medicine type, dosage, quantity and other criteria.
  • Provide a medicine taking alarm reminder.
  • Display and exportation of the history of the patients prescription medicine.

Normal Process Testing
So the first thing we need to test is that all those entities and their associated processes are included and that they work in the application.

The things you want to test are that they:

  • Exist.
  • Are easily added, changed and deleted.
  • Navigate easily and consistently between screens.
  • Have consistent and meaningful headings.
  • Have a consistent menu structure.
  • Do not cause errors or crashes within the application.
  • Are not missing any critical data fields.

Once you know that all the data and screens are there and the navigation is consistent you can now start doing your user and functional testing. You want to test that the normal processes as they were designed to be done:

  • Create a patient.
  • Create a doctor.
  • Create a pharmacist.
  • Create a prescription.
  • Create a medicine.
  • Create a medicine taking schedule.
  • Create a renewal of the medicine and accept it.
  • Display and export patient history.

This is the normal way a user would add the information into the application.

Abnormal Testing and Breaking
Once you know that the normal application function works you then want to test as many different combinations of functions that you can. In this second set of tests you are going to try and break the application instead trying to make sure that it works properly. So you will:

  • Add a patient and then delete it.
  • Add a patient edit it and save the changes and then delete it.
  • Add a patient, add a prescription, save it.
  • Add a patient, add a prescription, add a medicine and then delete them one at a time.
  • Try deleting a prescription without deleting the medicine.
  • Try deleting a patient without first deleting the prescription and medicine etc.

During this testing stage you are trying to find situations that the programmers did not think of or allow for. Be rest assured that if you do not find these issues your users will and they will complain about them.

Documentation of Issues Found
Whenever you find a problem or issue you want to try and get a screen print of the problem if you can. The one thing the screen print will do is not allow the programmer to say that a problem cannot happen. The other advantage of a screen print is that it is easier to describe an image than a occurrence. So The use of screen prints should save you time in documenting problems and issues and it should improve the communications between your testing team and your development team.

ipad application development
Communicate – Don’t Just Complain

When documenting problems and issues you need to convey the following information to your development team:

  • A basic description of what happened.
  • Description of what you were trying to do.
  • Location where you were trying to do it.
  • Why it is a problem.
  • What you think the problem or issue resolution should be.

It is important not to try and tell the developers how you want them to correct the problem. That is what they get paid to do. We are there to help them understand why an issue needs to be fixed, the priority for fixing that problem and what outcome you are expecting.

Provide Mockup When Necessary
It can sometimes be very helpful to provide mockup screens or examples for the developers so they can see what the resolution might look like. Mockups can help reduce a lot of ambiguity and clarify the resolution requirements.

This is a very high level description of how user/ functional testing can be done and how you can help your development team understand what problems need fixing, why and what the solution should look like.

Have you conducted any user testing for your iPhone applications? Did you find anything specific that helped in completing your testing?


Share it now!

Leave a Comment

Previous post:

Next post: