Monday, July 16, 2007

System testing

System testing
Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focussed, although specialist developers known as systems testers are normally employed to do it. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In effect it is one giant component. System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements:
Performance - Are the performance criteria met?
Volume - Can large volumes of information be handled?
Stress - Can peak volumes of information be handled?
Documentation - Is the documentation usable for the system?
Robustness - Does the system remain stable under adverse circumstances?
There are many others, the needs for which are dictated by how the system is supposed to perform.
Acceptance Testing
Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus:
Systems Testing checks that the system that was specified has been delivered.
Acceptance Testing checks that the system delivers what was requested.
The customer, and not the developer should always do acceptance testing. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgement. To help them courses and training are available. The forms of the tests may follow those in system testing, but at all times they are informed by the business needs.
Release Testing
Even if a system meets all its requirements, there is still a case to be answered that it will benefit the business. The linking of "Business Case" to Release Testing is looser than the others, but is still important. Release Testing is about seeing if the new or changed system will work in the existing business environment. Mainly this means the technical environment, and checks concerns such as:
Does it affect any other systems running on the hardware?
Is it compatible with other systems?
Does it have acceptable performance under load?
These tests are usually run the by the computer operations team in a business. The answers to their questions could have significant a financial impact if new computer hardware should be required, and adversely affect the "Business Case". It would appear obvious that the operations team should be involved right from the start of a project to give their opinion of the impact a new system may have. They could then make sure the "Business Case" is relatively sound, at least from the capital expenditure, and ongoing running costs aspects. However in practise many operations teams only find out about a project just weeks before it is supposed to go live, which can result in major problems.
Regression Tests
With modern systems one person's system, becomes somebody else's component. It follows that all the above types of testing could be repeated at many levels in order to deliver the final value to the business. In fact every time a system is altered.

No comments: