| Back to Home |
| ICT1 |
| ICT2 |
| ICT3 -Excel Project |
| ICT4 |
| ICT5 |
| ICT6 - Access Project |
| Contact |
| Testimonials |
| ICT Module 3 |
SECTION D – TESTING Section D – Testing (12 Marks)
Testing should really be an on-going process throughout the implementation of your project. You should test each module as it is completed to ensure there are no major design flaws before moving onto the next module (see appendix F). This is particularly important in the design of a relational database where seemingly minor faults in a module design can have wider implications later on. Testing is included as a separate section of your project documentation because many students fail to fully understand its importance and as a consequence fail to provide sufficient evidence that they have produced a workable solution to their problem. Preparation
Before embarking on your testing: 1. Read appendix F and make sure that you understand the different types of testing you will need to carry out and the reasons for these tests. 2. Make sure you understand the nature of “good” testing. Read or reread Heathcote pages 188-189 (2nd Edition). Pay particular attention to Heathcote’s words “…it’s not sufficient to think up a few tests you are fairly sure will not make your program crash or give a wrong result; you must use tests and test data which has been carefully thought out to test all parts of the program”. 3. Make sure that you understand the distinction between normal, extreme and erroneous test data. Start thinking about how these concepts apply to your project and try to draw up data sets that will test how your database performs under different conditions. 4. Look carefully at the system requirements of your project and/or your designs. Try and identify the operations your database is expected to perform – calculations, opening a form or report with data already in it. How are you going to test these operations? 5. Does your project include any validation rules? If so these need to be tested. Identify wherever validation and/or input masks have been used and consider what type of type of data you could use to test the validation. 6. Consider your original qualitative objectives. One of them should have been the creation of an intuitive, user-friendly system. Only the end-user can test whether you have achieved this. Draft an interview pro forma or questionnaire for your end-user to complete when they have tested the finished system. Paperwork
You could use the following outline plan to write up your testing section. Hard copy evidence of test runs (referred to in the last column of the table) should be included in your appendices, should be clearly cross-referenced in the test plan and should be clearly annotated to show evidence of a successful test run. 1. Testing 1.1 Module Testing Appendix F uses the example of one module to show how you can use tables to organise module testing. Note: It does not include a full set of tests or test data and is for illustration only. You will need to test all modules and include more tests for each module. Make sure that the evidence referred to in the tables is fully annotated and where possible cross-referenced to your test plan. Printouts with “… no annotation and no cross-referencing to the test plan are virtually useless!” – Heathcote
Most, if not all, of your modules can be tested in isolation. Once all the modules are complete you need to test the entire system with a realistic set of test data. You need to provide some evidence that your modules work together.
Include a copy of your questionnaire completed by the end-user in your appendices. Restate your qualitative objectives and any other requirements the end-user asked for in the original specification and produce a short report (no more than one side of A4) cross-referenced to the end-user’s comments. Don’t be afraid to include “negative” criticism! In the real world projects like this might take months, or even years, to get right – you’ve had 2 months! There are many reasons why an objective might not have been achieved:
In Section F – Evaluation you are credited for recognising the limitations of the solution you have produced. Get the end-user to sign and date your report to show that (s)he agrees with your evaluation of the end-user testing.
|