Software projects fail for many different reasons. In most cases it’s not actually down to the software itself, but because the requirements weren’t correctly specified. Companies don’t always spend as much time and effort as they should in ensuring that requirements are correct, but in fact testing requirements is just as important as testing the software itself.
Finding the Problem
Part of the issue is development projects can be complex, leading to large and unwieldy specification documents. This means that it’s easy for wrongly or badly specified requirements to be overlooked. It’s also the case that requirements testing doesn’t follow the same rule set as software testing, so there’s more scope for error.
Developing software means finding out what the users need and translating this into a formal specification document that sets out the requirements for the job. Testing should occur at this point to ensure that the project is on track and that nothing has been overlooked. However, research specialist Forrester points out in a recent report that poorly specified requirements can lead to a loss of customer satisfaction. It’s a particular problem in the mobile field where the pace of development tends to be quicker.
Solving the Problem
Checking software requirements is often seen as something that happens once in the development process. In fact it should be something that gets returned to several times by the mobile software testing company to ensure that the work is keeping on track.
So who can help with mobile software testing? You need a specialist who can sit between the IT team and the business unit. They need a clear understanding of the requirements, but also need to be sympathetic to the developer’s position. It’s important that they can properly log and keep track of all feedback on the project as it progresses – both good and bad – and be able to turn this into necessary action. For example a PDF to Excel converter would need to be tested to ensure that all areas of the PDF are successfully converted and that the user would have to key in as little information as possible.
Mistakes in setting out software requirements can prove costly, both in financial and resources terms. Companies therefore need to recognise that the requirements are just as important as the software and treat them as something to be tested, revised and retested in parallel with the software. This doesn’t mean that they should be allowed to dominate the project, but that they should be seen as key driver of successful delivery.
