Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

of

Test Driven Requirements Slide 1 Test Driven Requirements Slide 2 Test Driven Requirements Slide 3 Test Driven Requirements Slide 4 Test Driven Requirements Slide 5 Test Driven Requirements Slide 6 Test Driven Requirements Slide 7 Test Driven Requirements Slide 8 Test Driven Requirements Slide 9 Test Driven Requirements Slide 10 Test Driven Requirements Slide 11 Test Driven Requirements Slide 12 Test Driven Requirements Slide 13 Test Driven Requirements Slide 14 Test Driven Requirements Slide 15 Test Driven Requirements Slide 16 Test Driven Requirements Slide 17 Test Driven Requirements Slide 18 Test Driven Requirements Slide 19 Test Driven Requirements Slide 20 Test Driven Requirements Slide 21 Test Driven Requirements Slide 22 Test Driven Requirements Slide 23 Test Driven Requirements Slide 24 Test Driven Requirements Slide 25 Test Driven Requirements Slide 26 Test Driven Requirements Slide 27 Test Driven Requirements Slide 28 Test Driven Requirements Slide 29 Test Driven Requirements Slide 30 Test Driven Requirements Slide 31
Upcoming SlideShare
Efficient Point Cloud Pre-processing using The Point Cloud Library
Next
Download to read offline and view in fullscreen.

1 Like

Share

Download to read offline

Test Driven Requirements

Download to read offline

Test-driven development (TDD) is one of the new breed of "agile" software development techniques. At the core of TDD is the simple philosophy that the test cases for a new feature should be designed before the feature is implemented. Advocates of TDD claim that it results in shorter development times and better quality code. They cite early defect detection and the ease of regression testing as the main drivers for this improvement.

As TDD grows in popularity, many practitioners are beginning to realise that the core concepts of TDD can be applied to the other phases of the development life cycle. This session explores how the TDD philosophy can be applied to the requirements analysis phase.

The session commences with a brief overview of TDD that is followed by a detailed discussion of the concepts behind test-driven requirements (TDR). The discussion focuses on the abstract nature of software requirements and how this leads to difficulties with validation. It is argued that, in contrast, test cases provide concrete examples of requirements that are by nature self-validating.

The session concludes with a demonstration of the FIT acceptance test framework designed to support TDR in much the same way that the xUnit test frameworks support TDD.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Test Driven Requirements

  1. 1. Test Driven Requirements Phil Robinson LonsdaleSystems.com LonsdaleSystems.com 1
  2. 2. Software Development Trends LonsdaleSystems.com 2
  3. 3. The Software Development Life Cycle Co n str t en u cti Trends on ym lo propagate ep D backwards ign through the Op Des development er at life cycle io n Requirements LonsdaleSystems.com 3
  4. 4. 80’s The Structured Trend Structured Co Programming ns tru t en cti on ym lo ep D Structured ign Op Des Design er at io n Requirements Structured Analysis LonsdaleSystems.com 4
  5. 5. 90’s The Object-Oriented Trend OO Co Programming ns tru t en cti on ym lo ep D OO ign Op Des Design er at io n Requirements OO Analysis LonsdaleSystems.com 5
  6. 6. 00’s The Test-Driven Trend Co Test First n str t u en cti on ym lo ep D Test-Driven ign Op Development Des er at io n Requirements Test-Driven Requirements LonsdaleSystems.com 6
  7. 7. Brief Overview of Test-Driven Development LonsdaleSystems.com 7
  8. 8. Functional Non-Functional Requirement Requirement Test-Driven Development Test Design Refactor Code Test LonsdaleSystems.com 8
  9. 9. Requirements LonsdaleSystems.com 9
  10. 10. Use Case Model Hotel Enter Reserv ation Record Reserv ation Check In Record Check In Hotel Clerk Record Walk-In Check In Record Check Out LonsdaleSystems.com 10
  11. 11. Use Case Record Check Out Main Scenario 1. The hotel staff enter the guest’s room number 2. The system displays the guest’s stay details 3. The system calculates the room charge Alternate Scenarios a) Late check out and no prior arrangement at step 3 a1. The guest is charged for an extra night b) Check out the same day as check in at step 3 b1. The guest is charged for one night Business Rules number of nights = today’s date – check in date room charge = number of nights x room rate Normal check out time is 12pm Guests may request a later check out time Late check outs must be before 6pm LonsdaleSystems.com Validation 11
  12. 12. Testing Requirements LonsdaleSystems.com 12
  13. 13. Normal check out Verification «verify» Late check out no Record Check Out prior arrangement «verify» «verify» «verify» Check out same day as check in Normal check in No matching guests «verify» «verify» Test Cases Record Reserv ation Check In «verify» Guest has no current reserv ation Hotel «verify» Guest’s room preference not LonsdaleSystems.com av ailable 13
  14. 14. Today = 17/8/2006 Requirements Verification Record Check Out Check in Checkout Late Room Charge Comment date time checkout rate time 12/8/2006 11:30 am None $120 $600 Normal check out 12/8/2006 5:30 pm None $120 $720 Late check out no prior arrangement 17/8/2006 11:30 pm None $120 $120 Check out same day as check in LonsdaleSystems.com 14
  15. 15. In-Depth Testing • Maximum length of stay? • Maximum and minimum room rates? • Check out same day as check in – With late check out no prior arrangement? – Check in after 12am? LonsdaleSystems.com 15
  16. 16. Test Case Design Techniques LonsdaleSystems.com 16
  17. 17. Test Case Design Techniques Black-box Glass-box • Equivalence partitioning • Statement testing • Boundary value analysis • Branch/decision testing • Syntax testing • Condition testing • Decision table testing • Linear code sequence • State transition testing and jump (LCSAJ) … testing • Basis path testing • Data flow testing … LonsdaleSystems.com 17
  18. 18. Equivalence Partitioning Hotel Check Out Check in date beginning end of time today - 30 days today of time Charge smallest 1 night x cheapest 30 nights x most largest number 0 room rate expensive room number Late check out time 12 am 12 pm 6 pm 12 am none LonsdaleSystems.com 18
  19. 19. Today = 17/8/2006 Equivalence Partitioning Hotel Check Out Test Partitions Check in Checkout Late Room Charge Comment Case date time checkout rate time 1,4,10,13, Invalid check 1 8/7/2006 11:30 am None 120 4800 18 in date 2,4,10,13, 2 12/8/2006 11:30 am None 120 600 17 3,4,10,13, Invalid check 3 27/8/2006 11:30 am None 120 -1200 15 in date 2,5,10,13, 4 12/8/2006 5:30 pm None 120 720 17 2,5,8,13, 5 12/8/2006 2:30 pm 3:00 pm 120 600 17 2,6,8,13, 6 12/8/2006 4:30 pm 3:00 pm 120 720 17 LonsdaleSystems.com 19
  20. 20. Equivalence Partitioning Hotel Check Out Who “tests the test cases”? Today = 17/8/2006 Test Partitions Check in Checkout Late Room Charge Comment Case date time checkout rate time Invalid late 2,4,7,13, 7 12/8/2006 11:30 am 10:00 am 120 600 check out 17 time Invalid late 2,5,9,13, 8 12/8/2006 2:30 pm 8:00 pm 120 720 check out 17 time 2,4,10,11, Invalid room 9 12/8/2006 11:30 am None -120 -600 15 rate 2,4,10,12, Invalid room 10 12/8/2006 11:30 am None 10 50 16 rate 2,4,10,14, Invalid room 11 12/8/2006 11:30 am None 240 1200 18 rate LonsdaleSystems.com 20
  21. 21. • Confirms agreement of test outcomes – Expected Test Oracle – Actual • Human test oracle • Automated test oracle – Stakeholders – Spreadsheets – Users – Automated test frameworks and tools – Business analyst But is this testing But is this testing or validating or validating requirements? requirements? LonsdaleSystems.com 21
  22. 22. Test-Driven Requirements LonsdaleSystems.com 22
  23. 23. Requirements vs. Test Cases Requirement Test Case • Abstract • Concrete • “What should be” • “What should be • Validated by • “What should not be” stakeholders • Validated by test • Validation difficult to oracle automate • Test oracle can be automated LonsdaleSystems.com 23
  24. 24. Test-Driven Requirements Identify Develop test requirements oracle Develop test cases [discrepancies between expected and actual] LonsdaleSystems.com 24
  25. 25. FIT Automated Test Framework LonsdaleSystems.com 25
  26. 26. Framework For Integrated Tests (FIT) • fit.c2.com/ • fitnesse.org/ LonsdaleSystems.com 26
  27. 27. HTML table checkinDate checkoutTime lateCheckoutTime roomRate charge() 1/07/06 11:30 AM None 85 error 18/07/06 11:30 AM None 250 error 12/08/06 11:30 AM None 85 425 12/08/06 12:30 PM None 85 510 12/08/06 11:45 PM 11:30 AM 85 error 12/08/06 2:15 PM 2:30 PM 85 425 12/08/06 2:15 PM 7:30 PM 85 error 12/08/06 7:30 PM 2:30 PM 85 510 12/08/06 11:30 AM None -85 error 16/08/06 11:30 AM None 10 error 22/08/06 11:30 AM None 85 error Target system StayColumnFixture stay + checkinDate: var = "" - checkin_date: var + checkoutTime: var = "" + lateCheckoutTime: var = "" - room_rate: var + + roomRate: var = 0 typeDict: var = array( ... FIT + check_in(var, var) : var - test_stay: var + check_out(var, var) : var + charge() : var LonsdaleSystems.com Test fixture 27
  28. 28. start eg.HotelFixture press check in enter room rate 85 enter check in date 12/08/06 press ok press check out FIT enter check out time 11:30 AM enter late check out time None check charge 426 press ok HotelFixture + checkInDate: var = "" + checkOutTime: var = "" + lateCheckOutTime: var = "" + roomRate: var = 0 stay + typeDict: var = array( ... - test_stay: var - checkin_date: var - press_type: var - room_rate: var + checkIn() : var + check_in(var, var) : var + roomRate(var) : var + check_out(var, var) : var + checkInDate(var) : var + ok() : var + checkOut() : var + checkOutTime(var) : var + lateCheckOutTime(var) : var + charge() : var LonsdaleSystems.com 28
  29. 29. start eg.MScalc press clear enter number 2.99999999999999999999999 press add enter number 3.00000000000000000000001 press equals check result 6 press subtract enter number 2 press equals check result 4 press clear enter number 4 FIT press multiply enter number 2 press equals MScalc + number: var = 0 + typeDict: var = array( ... - obj: var + __construct() : var + clear() : var MS Calc Auto IT + number(var) : var + add() : var + subtract() : var + multiply() : var + divide() : var + equals() : var LonsdaleSystems.com + result() : var 29
  30. 30. FIT Demo… LonsdaleSystems.com 30
  31. 31. Questions? Phil Robinson LonsdaleSystems.com LonsdaleSystems.com 31
  • ConnieWright2

    Apr. 10, 2017

Test-driven development (TDD) is one of the new breed of "agile" software development techniques. At the core of TDD is the simple philosophy that the test cases for a new feature should be designed before the feature is implemented. Advocates of TDD claim that it results in shorter development times and better quality code. They cite early defect detection and the ease of regression testing as the main drivers for this improvement. As TDD grows in popularity, many practitioners are beginning to realise that the core concepts of TDD can be applied to the other phases of the development life cycle. This session explores how the TDD philosophy can be applied to the requirements analysis phase. The session commences with a brief overview of TDD that is followed by a detailed discussion of the concepts behind test-driven requirements (TDR). The discussion focuses on the abstract nature of software requirements and how this leads to difficulties with validation. It is argued that, in contrast, test cases provide concrete examples of requirements that are by nature self-validating. The session concludes with a demonstration of the FIT acceptance test framework designed to support TDR in much the same way that the xUnit test frameworks support TDD.

Views

Total views

7,114

On Slideshare

0

From embeds

0

Number of embeds

499

Actions

Downloads

53

Shares

0

Comments

0

Likes

1

×