A guide to the Testing and Documentation phases NSSCO Testing Phase The testing phase should focus on all

objectives and not the data input only. Screenshots are a must and will act as evidence of the progress made. This phase is divided into 2 parts namely; Test strategy Test results

a) Test Strategy - Data to be tested, expected results and how linked to the objectives they are. - This should be done for all the modules that were mentioned in the Design stage. (this should act as your checklist for accomplishment of objectives) - It is best to test multiple items of data (different fields in case of databases) with multiple values. - You also need to include the expected results of inputting your test data. e.g.
Objective Storage of customer records data in a computerised database
Fieldname Invoice number Invoice number Date Date Data to be tested 67 xy12 21/7/2008 87/1/2008 Normal/abnormal/extreme Normal Abnormal Normal Abnormal Expected result Data accepted Data rejected/error message Data accepted Data rejected/error message

b) Test Results - These are the actual results obtained from a running system which include the Normal, Extreme (2 extremes i.e. upper and lower) and Abnormal data. - Within this section you should include the results of using your test data from the test strategy (previous section). - Your test results should match your test strategy. - They should be outlined clearly through screenshots for each of the 3 test data.

- testing of normal data - 'invoice number' - value 67 - data accepted

- testing of abnormal data - 'invoice number' - value xy12 - data rejected

i. Normal Data Normal data is data which is normal value, and would be expected Normal data refers to that data which is expected to be entered in the cases when things are standard and no errors expected. The system should be able to process normal data to give results which are meaningful. E.g. for a payroll system, the Normal data could be when hours worked per day to be 5, 10 or 20 etc.

ii. Extreme Data Extreme data should show how your system deals with data on the boundaries. It could be the minimum possible value or the maximum possible value. For a payroll system we expect the system to take values of Hours worked per day by an employee to be between 0 and 24. So the extreme data in this case is 0 and 24 and it should be in the test strategy and also be tested. iii. Abnormal Data This is data which would not be expected and should not be accepted by the system. Abnormal data is the data which is out of range. Does your system recognize this? This has to be tested for each objective in each module. E.g. In a Payroll system, one would be expected to calculate the Salary of an employee after input of Number of Hours worked and Rate. Your system should recognize the number of hours input and only allow processing (calculation of salary) to take place if reasonable values are entered. Abnormal data could be if one enters Hours worked per day as Jerry, Texas, -100, 30 000 or ***** etc. Your test strategy should show what abnormal data that you intend to test. The test result should now show what you will actually view on your system once that abnormal data is entered.

Documentation Phase This phase can be divided into 2 parts namely; Technical Documentation and User Documentation. Technical Documentation This section is meant to give useful information to a technical person on improving, correcting or modifying the system in your absence. The technical documentation must contain algorithms, top-down structure, flowcharts, pseudo code, annotated code, macro structures, table relationships, DFDs etc. for all the modules. List all you have done, even if you think it is trivial. This is the spot where you can show (and prove) your computer skills. User Documentation Here you show the User Manual for an inexperienced user of your program. In general that should be describing what functions your program has, how to use the program (start, open, sort, search, print, quit, etc. etc.). Screenshots for all steps followed will give a more understandable manual. All steps should be explained clearly no matter how trivial it might seem to you.

N.B to capture a screen shot, use Fn + insert, then Paste the image, you can then Crop (Right click on the image and select Crop then adjust the height, width accordingly) it so that only the parts that you want appears. Some of the areas to address in the User Documentation are;

the hardware and software requirements of your solution how to install your solution how to enter, edit and save data (in your solution) how to process and output data (in your solution) how to avoid problems with your solution - what to do if problems or errors/mistakes happen while using your solution