Testing and implementation planning

Ensuring that a system works is very important.

  • A company that builds systems has a reputation to protect. They do not want to damage this by producing products that get into the news for the wrong reasons! In some cases, it could cause the company to go bust.
  • They need customers to say good things about the product they bought because 'word of mouth' will generate new business. This will help the company make bigger profits.
  • A system that is unreliable will soon be avoided by users. They will find it frustrating to use and will stop using it. Their company can only suffer because they have invested a lot of money in a system that was supposed to bring benefits and a system that doesn't work often makes matters worse.
  • A system that causes accidents will leave a company open to legal action.
  • Testing is a stage in the life cycle. The deliverable is the test plan. Test plans are written to ensure that the product does what it is supposed to do, as laid out in the Requirements Specification. It is usually written just after the Requirements Specification has been agreed and should test all of the functions mentioned in the Specification using typical, atypical, borderline, extreme and silly data. It should also be tested to ensure the whole system works together to produce the correct output for some given input.

Testing of software products can be very difficult to do thoroughly because there are often so many permutations through software. A strategy to testing must be developed.

Implementation planning

Once a product has been built and tested, it needs to be implemented. It must be done in a way that ensures minimum disruption to the business.

  • Staff training on the new system must take place. This should include those who will use the system and those who will support others in the initial phases of implementation, for example the Network Administrator or the various managers. This has implications for the business. If staff are training, they are not working! The cost of this should be taken into account when the project is planned.
  • When a new system is to replace an old system, the data files kept on the old system needs to be transferred. Someone has to actually do this and this takes money, time and resources. In addition, any data transferred to the new system should be current. It would be of little use to transfer data from the old system to the new system one day but then not use the new system for a week. There would be one week's worth of data out-of-date!
  • The hardware and software must be in place. Any additional hardware and software must be bought and stored somewhere until they are implemented. They then need to be set up and checked.

There are 4 implementation strategies that could be used.

  • Parallel running. The new system is run alongside the old system. Both systems operate together. This allows the new system to prove itself before the old system is abandoned - data generated by the new system can be compared to data generated by the old system. It also means that staff can be trained and gain confidence in the new system. Of course, if you are running two systems together, that means twice as much work for everyone for a short time!
  • Pilot running. The new system is run alongside the old system, but only a portion of the data is actually used in the new system. This method is less of a drain on resources. Data from part of the new system can be checked with the old system, but you cannot check how the whole system will react until you have got the whole system up and running.
  • Direct changeover. The old system is stopped and the new system is started. This might happen over a weekend, for example. If something goes wrong with the new system, then it has to be sorted out because you cannot fall back on the old system. Staff training needs to take place in advance with this method.
  • Phased implementation. Parts of a new system completely replace parts of an old system, whilst the old system continues to be used as required. The part of the new system that has been installed can be used for staff training and can prove itself before the next part of the installation takes place. This method takes longer than the direct changeover method. A company with 10 branches may install a new accounting system in one branch first, for example. They run it in the branch until it has proven itself and possibly bring in staff members from other branches for training. Once the system has proven itself in one branch, it can then be phased into the other branches.


Systems | Business


QR Code
QR Code system_testing_and_implementation_planning (generated for current page)