I have worked on many projects where there are been very different approaches to testing. At one end, I have worked with large companies where there has been a separate test team and at the other end, it has been solely the developer’s (my) responsibility. Other approaches have, for example, included outsourced testing and even relying on end users to test (and then fix quickly). Within these types of testing there are also multiple types of processes, tools and techniques. There isn’t ‘one way fits all’ and the actual approach often depends on the importance of the app, the skills sets available, the type of end-users and the available budget.
However, I have an observation that whatever the testing, there are always bugs in the code or unforeseen situations. This doesn’t mean I am advocating not doing testing. Testing is important. It’s just that you can’t do 100% testing. It impossible to test every scenario against every phone type and every network operator. It’s also impossible to know how the app might react to other unforeseen apps on the device. All this seems too obvious. However, it can’t be that obvious because I have seen too many projects where an app has been shipped and assumed to be 100% perfect and steps haven’t been taken to mitigate the risk that it isn’t perfect. An imperfect app can damage your reputation.
Here are four coping strategies…
- Think seriously about releasing to a restricted, more tolerant, subset of people first to soak test the app
- Put in place support mechanisms so you can quickly and efficiently respond to users
- Design in logging mechanisms so problems can be diagnosed as and when they do happen
- Ensure the developer is willing and able (resource wise) to fix problems quickly