Lecture 15 Term 2 week 4 Testing

1
Lecture 15Term 2 week 4Testing
INFO1409 Database Concepts
2
Introduction

• This presentation is designed to show you the
  importance of testing, and how it is used in
  testing database applications

3
Testing is Important!

• Programmers are human they misunderstand users
  requirements and make mistakes, so almost all
  programs contain bugs (errors)
• Testing is an important task, to identify as many
  bugs as possible
• It is not unusual for developers to spend 40 of
  total project time on testing
• For critical software such as airline flight
  control, testing can cost 3 to 5 times as much as
  the rest of the project.

4
The Purpose of Testing

• Ensure the user interface behaves as expected
• validation rules work correctly
• Ensure the user interface is usable
• cf HCI (Usability Testing)
• Verification
• ensure all functional specifications are
  accurately met
• identify bugs in the code (SQL)
• Validation
• show that the whole application meets the
  original formal specifications including
• speed timing
• report format and content

5
Test Plan 1

• It is impossible to test everything
• testing aims to systematically find as many bugs
  as possible in the shortest time
• Testing needs to be carefully thought out to
  achieve this
• Enter the test schedule
• composed of test plans for each of the components
  on the previous slide
• After a bug is fixed, the system should be
  retested
• fixing one bug can create a new bug in a
  different part of the system!

6
Test Plan 2

• The test plan for a big software development
  project is a major document, describing the
  approach and purpose of the testing work
• Writing a test plan provides a useful way to
  think through what is required - sometimes when
  the test plan is developed, problems are found
  with the requirements or design of an application
• A project test plan contains a series of test
  cases, to check how the application copes with
  different inputs
• The test plan contains tables to show which test
  cases check which requirements

7
Test Plan 3

• In this course you should
• test that your interfaces behave as expected
• see action chart testing
• design test data to ensure
• all validation works as designed
• all queries produce correct results
• report summary data is correct

8
Testing the Interface (Input Forms)

• The purpose of these tests is to ensure that the
  interactive parts of an interface behave as
  designed
• They are NOT concerned with verifying correctness
  of code
• All actions in all program states should be
  tested
• An Action Test Plan is a useful tool to aid
  designing and logging these tests
• Interface testing should also ensure that Printed
  reports match their designed layouts

9
Action Test Plan Example (scenario)

• The login form above is to be tested to ensure
  its actions work as specified
• Business rules
• Users enter name and password into labelled boxes
• Then press ltENTERgt
• They have three login attempts
• If correct combination login screen closes and
  main application starts
• If incorrect error message informs number of
  attempts left
• After last attempt message informs user system is
  closing down system closes 10 seconds later

10
Action Test Plan Example (planning)

• Only 1 interaction (click event of enter button)
• 3 states
• Entries correct
• Entries incorrect less than 3 attempts
• Entries incorrect all attempts exhausted
• A possible Action Test Plan

11
(No Transcript)
12
Functional Testing

• In database testing the purpose is to ensure
• All input validation works correctly
• All queries give correct results
• All calculations in reports are correct
• This is implemented by carefully choosing test
  data for each table to test all possible outcomes
• Various strategies exist for test planning but
  the most useful is
• Minimally Thorough Testing
• Read separate handout

13
Testing for Database Queries
Queryoutput
Input tables
SQL
Imagine you are testing someone elses query and
you cannot see what SQL they have written You
have to check that the query always gives the
correct answer for every possible kind of data in
the tables that the query uses.
14
Designing Test Data for Database Queries

• Output we expect It is easy to create test data
  which should appear in our output
• Output we do not expect We also have to think of
  other input data which could accidentally result
  in unwanted output
• (Have you heard of the system that kept sending
  out bills for 0.00? Nobody had thought of
  testing it with data for customers who owed
  nothing!)
• We need to notice the boundaries between data
  that should produce one output, and data that
  should produce a different output. These
  boundaries must be tested carefully.

15
Boundary Value Testing

• The most common boundary conditions are concerned
  with dates
• Suppose we want to test the following query for
  the phones scenario
• Find all contracts taken out between 3 April
  2004 and 25 April 2004
• The boundaries are 3 April and 25 April
• In our testing, we will check that contracts
  taken out on 3 and 25 April are included in the
  output
• We also need to be sure that contracts started on
  2 April and 26 April are not included in the
  output

16
Example of Functional Testing

• In the phones Scenario, suppose we have the
  following requirement
• Find all customers with a contracttype 2 who
  started their contract in May 2003
• How would we test that the query works?
• Using black box testing, we can design the test
  data even before we write the query
• We have two conditions
• Include agreements for contract type 2 (and
  exclude others)
• Include agreements started in May 2003 (and
  exclude others).

17
Example of Functional Testing

• Include agreements for contract type 2 (and
  exclude others)
• So test data needs to include
• some agreements for contract type 2, and
• some in other categories say 1 and 3
• Include start dates in May 2003 (and exclude
  others)
• What are the date boundaries? 1 May and 31 May
  so we want dates of
• 1 May and 31 May to appear in our output,
• but not dates of 30 April or 1 June
• Wed be wise to check that dates in May 2002 are
  excluded

18
Required Test Data

• Test cases
• We need agreements for phones for
• contract type 2
• with start dates of 30 April, 1 May, 31 May and
  1 June,
• and perhaps one in the middle May
• We need agreements for
• contract types 1 and 3
• with a start date in May 2003
• Lastly, test a agreement for
• contract type 2
• with a start date in May 2002.

19
Example of Functional Testing (Results)
X X X X X X x

• Here are the test cases we planned
• Mark the names you would expect to appear in the
  output if the query worked correctly
• Even with all these test cases, it is still
  possible that there could be a mistake in the
  SQL, but we have been as thorough as is
  reasonable.

20
Documenting Testing (1)

• As a minimum you should ensure that you include
• Annotated diagrams of input forms (noting
  interactive components their events)
• An Action Test Chart and log to test all
  interaction
• Printed output of all reports
• A brief explanation of how your data has tested
  that the SQL is correct

21
Documenting Testing (Writing up SQL Tests)

• Divide your explanation into two parts, like
  this
• Tests for expected output
• Contract number 4,5,6 with start dates 1 May, 12
  May, 31 May, all in 2003 for contract type 2
• Tests for unexpected output
• Contract number 1,2,3 start dates dates
  12.05.03, 30 April and 1 June 2003 for contract
  type 1
• Contract number 7 with start date in May 2002
  and contract type 2 ( wrong year)
• Contract number 8 and 9 with start date of
  30/04/2003 and 01/06/2003 with contract type 2
• Contract number 10 start date in may 2003 for
  contract type 3.

22
Key points to remember

• Testing is important and time-consuming
• Most programs have bugs the challenge is to
  find them
• Try to test database queries as if someone else
  wrote it and you cant see the SQL
• Test boundary conditions with care.
• Get a colleague to run your test plans and
  comment on their completeness

23
Summary

• We have covered methods for testing
• Input forms using action testing
• Query By creating Test cases
• Reports