Any bespoke system needs to be tested thoroughly before you sign the project off and begin to use it in a ‘live’ environment. This article looks at what testing involves, whose responsibility it is, and how to implement your own testing programme.
Isn’t up to the developer to test the software?
The obvious answer would be yes, but this is not the case. Testing should be part of the developer’s mandate, but the client also plays a key role. The client is the one who knows the business processes involved, and is the only one who can truly say “this works”.
What to ask for from your Developer
Making sure you and your developer follows some standard processes can help reduce the time taken for testing, and the time taken for making modifications as a result of that testing. Some of the things you should ask for are:
- Full specification – having a detailed specification document before you start can help reduce misunderstandings with the functions required in the system.
- Delivery of Prototypes – splitting the development into phases and requesting working prototypes during the development process means you can test parts as they are written, and catch any misunderstandings at an early stage. Although these prototypes would not have been fully tested by the developer, and won’t be completely free of bugs, they allow the client to test the general functionality.
- Error logs and exception handling routines – Exception handling is something programmers can implement to deal with errors when they happen. A common technique is to log an error when it happens. Although this doesn’t stop the error from happening again, it records all the information needed for the developer to fix the cause of the problem at a later date.
- Production of test data – you can’t test a system unless you have some data to test with. Along with the client, the developer should load data into the system for testing purposes.
- At the end of the development process the developer should have implemented all the validation checks requested and also been through the system to iron out any problems, or bugs, caused by errors in programming. It is up to the client to then test the system further.
What should I do?
The client should also take part in the testing, both during the development to make sure the functions are added as expected, and also at the end of the development so they are happy the system is doing what they expect and there are no bugs causing the system to crash or produce inaccurate results.
The first golden rule for testing is to test EVERYTHING, including the features that will only be used from time to time. Most developers can tell stories of how 3 months after a project has been signed off they receive a frantic phone call from the client because the report they need for that afternoon isn’t working.
Testing can be broken down into some key procedures:
- Functionality Testing – does the system contain the features required, and do they work in a way that is easy to use and produces the correct results?
- Validation Testing – can all the differing types and ranges of data be entered, and does invalid data get blocked?
- Error Handling – does the system recover from problems gracefully (i.e. it doesn’t crash or freeze up)?
- Performance Testing – does the system respond fast enough when being used, and how does the system perform when multiple users are logged on simultaneously?
How long does testing take?
This really depends upon the complexity and size of the software. However, a rough estimate is that you should allocate a further 25% of the development time to testing. It is surprising how many systems miss their ‘go live’ date because the client did not have the resources to test the system at the crucial time.
Testing is a vital part of any software development project, but it is often an area that is overlooked. The temptation is to rush the application into a ‘live’ environment, but this can cause all kinds of problems if it hasn’t been tested thoroughly.
Testing is the responsibility of the client, as well as the developer, and time should be allocated specifically for the testing process in any planned timescales.