6. Tester

Although the programmers will test that their own part of the system works and that it integrates with parts being developed by other programmers, they generally will not test the system as a whole.

testing softwareThis is the role of the testing team. They will try to discover any errors before the system is released.

Once an error is found, it is relayed back to the programmers for fixing. Once the fix is in place, that part is tested again to prove it works.

The testing team will follow the test plan written by the system designer.  They will test every aspect of the system and ensure that every part of it works together as it should.

They will check that the system deals properly with 'bad' inputs i.e. they will try to ‘break’ the system.

The tester may also check the user requirements document to see if the system passes the expected performance levels.

The tester will make decisions on how to test the system. This includes:

Choosing to test each part of the system as a 'black box'. A black box test does not care what is inside the module but only what outputs it produces given a set of appropriate inputs. This modular approach assumes that an error in one module will not create an error in another one, but it is an efficient way of testing as each part in turn is 'signed off' as working.
Choosing to test the whole system in detail. This is called the 'white box' approach. Very detailed but may take longer
Deciding on an effective set of test data. By 'effective' we mean the data set will test as much of the system as possible in the time available.
Documentation. The test result documentation proves that the system passed the test. This is an important document should a serious flaw be found in the system once released as it helps identify why something has gone wrong.

 

challenge see if you can find out one extra fact on this topic that we haven't already told you

Click on this link: System Tester