Practical Project: System Testing
System Testing is worth 12% of your overall mark, it is also very easy to get top marks if you follow all the guidelines. You should have made a test plan in your design, we are now going to follow the plan and provide evidence to show that our system works (or doesn't!).
You might have implemented some things in your technical solution that weren't covered by your initial test plan, don't leave them out, add them to this test plan.
If you didn't manage to complete all of your functionality your test plan might test for things that don't work. Don't worry, this is testing after all. Show the feature not working and explain why. If you can use a trace table and show how you fixed the issues
Ideally you need to show screenshots for every test that you perform.
Let's get started.
Building a test table
[edit | edit source]| Test Number | Description | Data type | Expected result | Pass/Fail | Cross Reference |
|---|---|---|---|---|---|
| 1 | You will describe what the test is looking for and how you will perform it | This will be Typical, Erroneous or Extreme. If you don't know what this means read below | How are you expecting the system to respond to your input data? Should it give an error message? Will the response be any different to a normal one? | Did it succeed or fail? You are aiming for the vast majority to be passes | link this test to your screen shot that proves it works |
| 2 | The average price of all the chocolate bars is calculated on the Choc Form | typical | When we have 5 chocolate bars at 20,25,20,25,30 pence the average will be displayed as 24p | Pass | See screen shot 2 |
| 3 | Passwords must contain numbers | erroneous | When I enter the password "letmein" it will bring up an error box | Pass | See screen shot 3 |
| 4 | Passwords must contain numbers and letters | typical | When I enter the password "letme1n" it will let me register a new user | Pass | See screen shot 4 |
| 5 | When ball collides with the paddle it increases the score and bounces in the correct direction | typical | The y component of the ball vector is reversed | Pass | See screen shot 5 |
Typical, Erroneous, Extreme
[edit | edit source]So what are typical, erroneous and extreme data? The answer lies mostly in their name, let's take a look at this example where someone has created a secondary school registration system which lets students register themselves. We don't want people who are too young attending, and we don't want students who are too old. In fact we are looking for students 11–16 years old.
- A Typical Student will be 12,13,14 or 15
- An Erroneous (or wrong) aged student will be 1045, 6 or any age outside those allowed.
- An Extreme (or boundary) aged student has just started or is just about to leave, they will be 11 or 16
If you are testing data that has Typical, Erroneous and Extreme data, show tests for all three. Some tests might only have typical and erroneous, for example entering a correct password. Some things might only have typical testing, such as if a button to a next page works or not, or if a calculation is correct.
Expected Result
[edit | edit source]Describe what you are expecting to see, this is what your result screen shot should show happening. If you are showing the result of calculating something then describe the data going into it and if possible include a screen shot of this data in you evidence.
Pass/Fail
[edit | edit source]Explain whether it passed or failed, if it fails you need to explain what went wrong, if it works explain that it works.
Cross Reference
[edit | edit source]This is where you need to link to your screen shots to prove that you completed these tests. Without these screen shots you lose marks. A few hints:
- Try to include a screen shot for every test
- Make sure that your screen shots show the test passing and they aren't too small (learn how to crop images!)
- where the result isn't immediately obvious try to include annotation on your screen shots.
Trace tables
[edit | edit source]You should include at least 2 trace tables covering some of the more complex elements of your code to prove that the code performs as you are expecting it to. Trace tables lend themselves to loops. So if you have a loop then make a trace table to prove it works. This section should include:
- Code you are testing
- Description of expected outcome, this may include hand written calculations
- Trace table proving that the code works
What to Test
[edit | edit source]You will need to try and test all of your system, here are a few pointers to help you make sure everything has undergone a thorough test:
- Test that all navigation works
- Test that all algorithms you design function correctly in all circumstances
- Test that all buttons/sliders/drop downs/etc function correctly
- Check that your SQL or other data model loads, inserts, updates and deletes
How much testing to perform
[edit | edit source]If you have written a particularly complex program there is an awful lot of testing to do. You don't have to show every test, but you do have to give a good sample including screen shots and trace tables.