As you start to get test versions of the app (also know as ‘builds’) from the developer you will need to start testing them and closing the project ready for launch. For many people, this prospect is the least ‘fun’ part of the project but it is vital to test the app thoroughly and will ultimately save time and probably money too.
How often to test
There is likely to be some very intensive testing towards the latter stages of the project (you don’t want to submit an app to Apple with a bug in it and I’m sure your future users won’t appreciate it either) but as early as you can you should get into the habit of regular testing (on a daily basis if you are getting builds that frequently).
This habit of sending daily feedback (so-called ‘short-iterations’1) to your developer will speed up the process enormously, keep momentum and ensure the number of wrong turns that happen on the project are limited.
Using a dedicated tester or team
For a smaller app of just a few ‘pages’ you can do all the testing yourself (should you so desire) but if things are getting a little more complex than that there are a few ways you can structure it. Though there’s nothing wrong with testing the app yourself (I’m sure you will end up doing some either informally or formally anyway, however much you delegate) if you can get a dedicated tester (or team for a huge app) it will help enormously.
This does not mean he, she or they will be the only people that test it (it’s still important to get others involved as well, as I will explain), but having everything go through this formal process will give you the best chance of a bug-free app that matches the original spec as quickly as possible.
If you have a dedicated tester (or testing team) already then get them looking at every build as soon as it arrives. If you don’t have a tester already then look to put a dedicated member of staff on it. Preferably this should be someone with a track record of testing websites / software products or similar, but at least someone who is extremely thorough, patient and has good attention to detail.
If you’re a ‘one man band’ or the previous options are not going to work for you then you can either outsource this part too (hello Elance) or roll up your sleeves and put your testing hat on!
Involve stakeholders
You might have now have your superstar tester in place, but if you are producing this app for your employer or you have other stakeholders, it is important to involve them at an early stage too and not just before you are about to launch. That may mean passing builds to other departments such as editorial, sales, marketing and any directors as well. You may also want to include sponsors and other partners you have before the app gets too far down the line.
If you’re worried about showing something ‘half-finished’ to people then don’t be. Explain that it is a beta version but that you want to them to be involved. Chances are that even though they signed-off the spec and hopefully understood it all at the time, as weeks pass everyone has the habit of remembering things differently and expecting to see different things.
By keeping them in the loop you not only show them exactly where the project is headed so there are no ‘I thought this section was going to work like that’ surprises from them at the end. You also give yourself the chance to steer the project and change direction at an earlier, ‘easier to change’ stage if an app that sounded good and looked amazing on paper is not working quite how you want it to in reality.
Make sure also that any other stakeholders that may need to see the app at an early stage, are on your UDID List and that regular builds are sent to them (with clear instructions on how to install the app too).
So now you know who you’re showing it to, how do you actually test and make sure everything is checked?
1‘Groupon’s development philosophy: Really Short Iterations’
readwriteweb.com/hack/2010/10/groupon-development-philosophy.php
