Testing a Solution

You need to test that your solution works and that it meets the requirements of your end-user. Your testing will be taken into the exam with your analysis It is based around your analysis, so must match up i.e. user requirements, tasks and cell references, etc. It is split into two sections – the test plan and the test screenshots.

Test planning A test plan is usually drawn up when the solution is being designed. A test plan goes into depth, giving exact details of each test to be done and what data is to be used.

Formulas – That all the formulas work? There is no need to test every instance of formula or validation rule. What to Test Formulas – That all the formulas work? Validation – Check the validation rules work using normal, erroneous and extreme test data? User Requirement – check that the solution meets the user requirements. Outputs – that the spreadsheet prints out on one page, give finished system to the client to approve Usable by end-user or audience – give system to end-user or audience to test and give you feedback.

Testing Documenting your testing (evidence) Once the test plan has been drawn up, it should be followed methodically. The results of all tests should be recorded along with evidence such as screen shots. Any corrective action that was needed should also be recorded, along with evidence that it corrected the problem. All screenshots of tests should be referenced to the test plan to make it easy to follow.

Need to include test all types of formulas and show that they work. Testing Formulas Need to include test all types of formulas and show that they work. Some formulas are proved to work by results in another cell. You need to state which formula you are testing and the cell it is in. Then, what cells you expect to change as an outcome and what they will show.

Test Plan cont Each test must clearly show what test data is being used, e.g. Cell C9, “83” will be entered. Each test must show what the expected outcome is as a result of each test Do not produce test plans testing exactly the same thing – e.g. number of bikes hired – only test 1 in detail, then list similar tests (Examiners assume you do not understand what you’re doing if you duplicate tests).

Types of test data Testing Validation Rules needs to be chosen carefully to try to prove that the solution: works with data that should work copes adequately with data that is wrong (gives an error message) Normal data is data that would be expected. It should pass validation rules and the solution should work properly, for instance the data value that is on a lookup list. Extreme data should work but is at the edges of what the solution is designed to work with, for instance the first and last entries in the lookup list. Erroneous data should, if possible, be rejected by the solution and not cause it to fail, for example, a value that is not on the lookup list at all.

Normal Data – is the data you expect to be entered in the field. i. e Normal Data – is the data you expect to be entered in the field. i.e. in the birth date field where students have to be 16 to enrol in college a date of 16th February 1992 would be accepted. Extreme Data – this is where you test for data at either end of what is allowed ie where students have to be 16 a date of 31st August 1991 should be accepted.

Erroneous Data – this is where you enter data that is completely wrong which should cause an error. Ie entering text in a date field or entering the date in the wrong format.

Example This list is being used to look up product details via the primary key of Product Code: Product Code BY1734 BY1963 BY5006 BY5572 BY5641 BY9007 This value would be extreme data. These values would be normal data. This value would be extreme data. A value of BZ9781 is not on the list, so it is erroneous data. If possible the system validation should stop it being entered.

Testing User Requirements also known as Integration Testing You need to figure out how you’re going to test that each user requirement has been met. You should list each user requirement and produce a screenshot showing you’ve met it. For some of them, you may need the end user to be the one that tests your system.

It is useful to know about the following two types of test but you do not need to test for them at AS System Test This is where you check that your system can handle realistic amounts of data. For example, 20 quotes, 20 invoices, 20 members, etc. You need to draw attention to the fact that you are testing to see if it can handle the amount of data that the end user will be expecting it to handle.

End User Testing The end user needs to be involved in testing the solution to make sure it does what they wanted it to do. End users should look at: the user interface to make sure they find it easy to use. the output, making sure the correct information is included and the format is suitable for their needs. Questionnaires may often be the best way to record the opinions of ends users and audiences.

When testing formulas – Test Plan Each test must be numbered consecutively – i.e. start with 1 and keep going When testing formulas – the formula must be included in the test plan use a highlighter pen to show the formula you are testing

Test Plan format See booklet for examples Test No Test (inc cell ref) Type of Test Test Data to be used Expected Outcome Actual Outcome 1 2 3 4 See booklet for examples