Thursday 13 December 2012

Testing, testing...

It is useful to have a table to describe the test plan that you create and implement for your software.  Please see the following handout from Dawson's book:

Link to testing from Dawson's book

Dawson's book at Amazon

In the seminar after today's lecture (week 11, Thursday 13 December) we looked at examples of tests, and showed how any problems were addressed. Not all tests are successful first time, so we need to identify and errors and explain what had to be done to correct them.
We also need to consider how the systems deal with error data as well as valid data:

if you are calculating wages:
  • 40 hours worked per week = OK
  • 60 hours worked per week = looks like overtime was involved
  • 80 hours worked per week = check if overtime was authorised
  • 200 hours worked per week = whoa!  There are only 168 hours in a week!
You do not want your system to calculate payment for 200 hours worked, as this is impossible.

You should also check whether your system can cope with invalid data types, such as what happens when a character is typed instead of a number - does the system crash, wait for more data, or display an error message?

Note that testing refers to the testing of your queries (including passing parameters, and the switchboard).

Checking the data that makes up the database will be in the organisation chart section if it refers to staff; in the case of all other data, any errors (and associated actions and corrections) will be included in the section of data cleansing.

  

11 comments:

  1. Hi Kay for the management decision do we need write everyone else's or just our own and merge the three together

    ReplyDelete
    Replies
    1. You should have the group section first, then the individual components from each team member after the group section to make one report. You will also need to attach the software so that it can be run.

      Delete
  2. Hi im confused on what do do for he test plan can you please hekp me

    ReplyDelete
    Replies
    1. Look at the link to the test plan for Dawson's book. We covered testing in the seminar after last week's lecture. Also read the post above in conjunction with the coursework specification. You need to be able to identify any bugs/problems/issues and explain how you dealt with them

      Delete
  3. Hi Kay, in the individual part do we have to put everyones individiual part with the whole report or do it serperatly

    ReplyDelete
    Replies
    1. Hi Marina

      Please see reply to earlier comment on this post; I think that answers your question.

      Kay

      Delete
  4. hi kay do we have to do the test plan for the whole of the system or for just our individual quieries and reports?

    ReplyDelete
    Replies
    1. You need to make sure the system works, so that means testing that the switchboard works, the queries/reports produce what you expect etc. Please see main post.

      Hope this helps

      Kay

      Delete
    2. basically Kay what im saying is that do each individual member need to do a testplan for the whole system so for each forms and the delete and add button within each form and also for our queries as well?

      Delete
    3. Each member of the team needs to test their own components for the items they have created. If you are assuming that data is migrated periodically from the transaction processing systems into your ODDS system, the insertion, amendment and deletion of individual records is less important (you need to consider who the users will be - will managers be updating records?). The assumptions you make will have an impact on your system. The main focus will be on the aspects relating to ODDS as a management support system for managers making decisions; the queries and reports must be demonstrated. It will be beneficial to test other aspects of the system, but you must ensure that the queries and reports produce what you have identified as information needs for managers.

      Kay

      Delete
    4. THANKS YOU KAY

      Delete