SE401 · Test Cases · Annotated SlidesTest Cases
Original
Overview

Test Cases

Test selection, what a test case is and what makes a good one, the triangle example, why we write test cases, when testing is complete, test scaffolding (drivers, stubs, harnesses), test oracles, defect tracking and smoke tests.

How to read this page

Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed. Pick an answer to each question: a wrong pick tells you why it is wrong, so you can try again.

All 36 slides
  1. 1 Slide 1
  2. 2 • Testing • Test selection
  3. 3 • There is a massive misunderstanding about testing: that it improves software. It doesn't!
  4. 4 Slide 4
  5. 5 • A
  6. 6 • A test case is a description of a specific interaction that a tester will have in order to test a single behavior of the software.
  7. 7 • Test cases must be repeatable. • Good test cases are data-specific, and describe each interaction
  8. 8 • First you must understand the language fundamentals
  9. 9 • Test Cases need to be simple and transparent • Create Test Case with end user in mind
  10. 10 • Boundary Value Analysis (BVA)
  11. 11 While drafting a test case do include the following information • The description of what requirement is being tested
  12. 12 • Cover all possible valid input
  13. 13 • Beware of problems with comparisons
  14. 14 Let’s consider the triangle example • Cover all possible valid input
  15. 15 Let’s consider the triangle example • How to test the code?
  16. 16 • You cannot test every possible input, parameter value, etc.
  17. 17 Test Cases – Good Example
  18. 18 Test Cases – Bad Example
  19. 19 • Why we write test cases?
  20. 20 • Test one thing at a time per test method.
  21. 21 • The software testers begin executing the test plan after the developers deliver the alpha build, or a build that they feel is
  22. 22 • When is testing complete?
  23. 23 • Designing test cases and test suites is creative
  24. 24 • Test design often yields test case specifications, rather than concrete data
  25. 25 • Code produced to support development activities (especially testing)
  26. 26 • Test driver
  27. 27 Stubs
  28. 28 Drivers
  29. 29 • How general should scaffolding be?
  30. 30 • Did this test case succeed, or fail?
  31. 31 Comparison-based oracle
  32. 32 Self-Checking Code as Oracle
  33. 33 • Sometimes there is no alternative to human input and observation
  34. 34 • The defect tracking system records and tracks defects. • It routes each defect between testers, developers, the project manager
  35. 35 • A smoke test is a subset of the test cases that is typically representative of the overall test plan.
  36. 36 • Goal: Separate creative task of test design from mechanical task of test execution
Slide 1 / 36

Slide 1

Slide 1: Slide 1
Slide 2 / 36

• Testing • Test selection

Slide 2: • Testing • Test selection
Slide 3 / 36

• There is a massive misunderstanding about testing: that it improves software. It doesn't!

Slide 3: • There is a massive misunderstanding about testing: that it improves software. It doesn't!
Slide 4 / 36

Slide 4

Slide 4: Slide 4
Slide 5 / 36

• A

Slide 5: • A
Slide 6 / 36

• A test case is a description of a specific interaction that a tester will have in order to test a single behavior of the software.

Slide 6: • A test case is a description of a specific interaction that a tester will have in order to test a single behavior of the software.

Notes

  1. Test case: inputs, preconditions, expected results and postconditions for one test objective. Must be repeatable.

Slide 7 / 36

• Test cases must be repeatable. • Good test cases are data-specific, and describe each interaction

Slide 7: • Test cases must be repeatable. • Good test cases are data-specific, and describe each interaction
Slide 8 / 36

• First you must understand the language fundamentals

Slide 8: • First you must understand the language fundamentals
Slide 9 / 36

• Test Cases need to be simple and transparent • Create Test Case with end user in mind

Slide 9: • Test Cases need to be simple and transparent • Create Test Case with end user in mind

Notes

  1. Good test cases: simple, one thing at a time, traceable to requirements, with a clear expected result.

Slide 10 / 36

• Boundary Value Analysis (BVA)

Slide 10: • Boundary Value Analysis (BVA)
Slide 11 / 36

While drafting a test case do include the following information • The description of what requirement is being tested

Slide 11: While drafting a test case do include the following information • The description of what requirement is being tested
Slide 12 / 36

• Cover all possible valid input

Slide 12: • Cover all possible valid input
Slide 13 / 36

• Beware of problems with comparisons

Slide 13: • Beware of problems with comparisons
Slide 14 / 36

Let’s consider the triangle example • Cover all possible valid input

Slide 14: Let’s consider the triangle example • Cover all possible valid input

Notes

  1. Triangle problem: classify three sides as equilateral, isosceles, scalene, or not a triangle: include invalid inputs (0, negatives, a + b ≤ c).

Exam angle

PredictionQ1

Give three test cases for a program that classifies a triangle from three integer sides.

Compare with the model answer

(3, 3, 3) → equilateral; (3, 3, 4) → isosceles; (3, 4, 5) → scalene; plus invalid ones such as (1, 2, 3) → not a triangle (a + b = c) and (0, 4, 5) or (−1, 2, 2) → invalid input.

Slide 15 / 36

Let’s consider the triangle example • How to test the code?

Slide 15: Let’s consider the triangle example • How to test the code?
Slide 16 / 36

• You cannot test every possible input, parameter value, etc.

Slide 16: • You cannot test every possible input, parameter value, etc.
Slide 17 / 36

Test Cases – Good Example

Slide 17: Test Cases – Good Example
Slide 18 / 36

Test Cases – Bad Example

Slide 18: Test Cases – Bad Example
Slide 19 / 36

• Why we write test cases?

Slide 19: • Why we write test cases?
Slide 20 / 36

• Test one thing at a time per test method.

Slide 20: • Test one thing at a time per test method.
Slide 21 / 36

• The software testers begin executing the test plan after the developers deliver the alpha build, or a build that they feel is

Slide 21: • The software testers begin executing the test plan after the developers deliver the alpha build, or a build that they feel is
Slide 22 / 36

• When is testing complete?

Slide 22: • When is testing complete?

Notes

  1. Testing is "complete" when exit criteria are met (coverage, remaining risk, time/budget), never when all bugs are gone.

Slide 23 / 36

• Designing test cases and test suites is creative

Slide 23: • Designing test cases and test suites is creative
Slide 24 / 36

• Test design often yields test case specifications, rather than concrete data

Slide 24: • Test design often yields test case specifications, rather than concrete data
Slide 25 / 36

• Code produced to support development activities (especially testing)

Slide 25: • Code produced to support development activities (especially testing)
Slide 26 / 36

• Test driver

Slide 26: • Test driver

Notes

  1. Test driver: code that CALLS the unit under test. Stub: replaces a module the unit calls. Harness: drivers + stubs + tools.

  2. Seen again Unit Testing and JUnit, slide 4: unit testing

Slide 27 / 36

Stubs

Slide 27: Stubs
Slide 28 / 36

Drivers

Slide 28: Drivers
Slide 29 / 36

• How general should scaffolding be?

Slide 29: • How general should scaffolding be?
Slide 30 / 36

• Did this test case succeed, or fail?

Slide 30: • Did this test case succeed, or fail?

Notes

  1. Oracle: decides pass/fail (comparison-based with expected outputs, or checks of properties).

Slide 31 / 36

Comparison-based oracle

Slide 31: Comparison-based oracle
Slide 32 / 36

Self-Checking Code as Oracle

Slide 32: Self-Checking Code as Oracle
Slide 33 / 36

• Sometimes there is no alternative to human input and observation

Slide 33: • Sometimes there is no alternative to human input and observation
Slide 34 / 36

• The defect tracking system records and tracks defects. • It routes each defect between testers, developers, the project manager

Slide 34: • The defect tracking system records and tracks defects. • It routes each defect between testers, developers, the project manager
Slide 35 / 36

• A smoke test is a subset of the test cases that is typically representative of the overall test plan.

Slide 35: • A smoke test is a subset of the test cases that is typically representative of the overall test plan.

Notes

  1. Smoke test: a quick subset of tests to check the build is stable enough for further testing.

Exam angle

PredictionQ1

A quick check that a new build’s main functions work before deeper testing is a:

Slide 36 / 36

• Goal: Separate creative task of test design from mechanical task of test execution

Slide 36: • Goal: Separate creative task of test design from mechanical task of test execution