Test Requirements: The Basis of Testing David Capocci, CQA, CSTE Sr. QA Systems Analyst SAFECO Corporation [email_address]
Agenda <ul><li>Defining Test Requirements (TR)  </li></ul><ul><ul><li>What, Why, Where </li></ul></ul><ul><li>Fitting TR’s...
Background <ul><li>“ Test Requirements Hierarchy” is a term coined from Rational’s SQA Team Test software. </li></ul><ul><...
Test Requirements <ul><li>What exactly is a Test Requirement?  </li></ul><ul><li>Why identify Test Requirements? </li></ul...
What exactly is a Test Requirement? <ul><li>Identifies the “WHAT” of testing </li></ul><ul><ul><ul><li>What needs to be te...
Example 1: Testing the inserting of a record to a table <ul><li>“ Validate that you can insert an entry” </li></ul><ul><li...
Why identify Test Requirements? <ul><li>It’s what QC “owns” in our workbench: Requirements-based or Function-based testing...
Where does a TR come from? <ul><li>Traditional: Business Requirements, functionality, internal logic… </li></ul><ul><ul><l...
How do Test Requirements  relate to the Test Plan? <ul><li>Traditionally, the Test Plan has represented “what” was going t...
Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><...
Drilling down:  Where test requirements fit into the picture   Business Requirement Test Requirement Test Scenarios/ Cases...
Drilling Down Business Requirement Test Requirement Test Scenarios/ Cases Test Procedure/ Script Fitting TR’s into the tes...
ATM Example: Practice Writing Test Requirements <ul><li>Business Requirements: </li></ul><ul><li>- “ATM must do withdrawal...
Example 2: Testing Withdrawals on an ATM <ul><li>“ Validate that a withdrawal option is available” </li></ul><ul><li>&quot...
Test Scenarios/Cases for -   “Validate that a withdrawal of a multiple of $20,  between $20-$300 can be done” What’s withi...
Test Procedure & Script for previous example <ul><li>Step 1: Insert Card </li></ul><ul><li>Step 2: Enter PIN  </li></ul><u...
Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><...
The Workbench Concept Generating TR’s Our workbench is called “Generating Test Requirements” DO DO Check Standards Tools R...
Entrance Criteria for  Business   Requirements  to generate  Test Requirements <ul><ul><ul><li>Visible ? </li></ul></ul></...
Exit Criteria for  Test Requirements <ul><ul><ul><li>Can another tester create test cases/scenarios from these? </li></ul>...
When creating  Test Requirements  (“Do”)... <ul><li>Use “action” verbs & words </li></ul><ul><ul><ul><li>“Validate that…” ...
Also... <ul><li>Maintain a level of balance between too much & too little </li></ul><ul><ul><ul><li>Too High level: won’t ...
Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><...
Distinguishing the types of testing…. <ul><li>I. Function-Based Tests </li></ul><ul><li>II. User Interface Tests </li></ul...
Organizing by Functional areas…. <ul><li>Most testers perform function-based, or requirements-based tests </li></ul><ul><u...
Organizing by Functional areas…. <ul><li>Most testers also perform User Interface Style Tests </li></ul><ul><ul><ul><li>Th...
Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><...
Remember this?…Drilling down Fitting TR’s into the testing picture
Decomposing: Drilling down within a Test Requirement Business Requirement Test Requirement Test Scenarios/ Cases Test Proc...
Test Requirement Decomposition Decomposing TR’s
Test Requirement Decomposition Business Function Tasks within the Function Data Entry Types for transactions Transactions ...
Test Requirement Decomposition <ul><li>You can start on the high level functional areas early into the project & build in ...
Business Function Level <ul><li>Try to identify “groups” of functions or functions connected by similar themes </li></ul><...
Business Function Level <ul><li>At this level, the idea is seeing the connections, integration, and interactions of the sy...
Task Level <ul><li>Break down each Function area into the tasks within the function </li></ul><ul><li>For complex tasks, i...
Transaction Level <ul><li>From this level down, we start to address the internal things that occur to make the functions a...
Transaction Data Type Level <ul><li>Identify which of the four types the transaction can become: Add, Change, Delete, Inqu...
Field Validation Level <ul><li>Most testers like to jump directly to this level. It’s the most obvious at times. </li></ul...
Field Validation Level <ul><li>Not all test requirements (especially at this level) fit well to be documented in this mann...
Example 3: Rental Car  Application <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.1 Check Customer polic...
Example 3: Rental Car  Application <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket...
Example 3: Rental Car  Application <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket...
What did you come up with? <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket </li></...
Possible Test Requirements... <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket </li...
Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><...
TRH Samples <ul><li>Let’s look at a few examples of how test requirements can be organized: </li></ul><ul><ul><ul><li>Samp...
Test Coverage Measures <ul><li>Test Requirements are the “what” of testing & are the basis for establishing the completion...
Summary & Recap <ul><li>Defined:  What, Why, Where </li></ul><ul><li>Described: How TR’s “fit” into the big picture </li><...
Upcoming SlideShare
Loading in …5
×

Test Requirements

1,854 views

Published on

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,854
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Test Requirements

  1. 1. Test Requirements: The Basis of Testing David Capocci, CQA, CSTE Sr. QA Systems Analyst SAFECO Corporation [email_address]
  2. 2. Agenda <ul><li>Defining Test Requirements (TR) </li></ul><ul><ul><li>What, Why, Where </li></ul></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><li>What’s within our testing process </li></ul></ul><ul><ul><li>Generating TR’s </li></ul></ul><ul><li>Organizing & Decomposing TR’s </li></ul><ul><li>Test Requirements Hierarchy Samples </li></ul><ul><li>Setting the stage for measuring test coverage </li></ul>
  3. 3. Background <ul><li>“ Test Requirements Hierarchy” is a term coined from Rational’s SQA Team Test software. </li></ul><ul><li>The principle of identifying, organizing, and measuring test requirements is universal to many test processes and methodologies </li></ul><ul><li>Much of this in-service is distilled from: </li></ul><ul><ul><ul><li>Rational methodologies (we are an SQA Team Test house after all) </li></ul></ul></ul><ul><ul><ul><li>QAI Workbench model </li></ul></ul></ul><ul><ul><ul><li>Seminar topics from </li></ul></ul></ul><ul><ul><ul><ul><li>19th annual International Software Testing Conference </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Star ‘98 West Conference </li></ul></ul></ul></ul><ul><ul><ul><li>Ed Kit’s “Software Testing in the Real World” </li></ul></ul></ul>
  4. 4. Test Requirements <ul><li>What exactly is a Test Requirement? </li></ul><ul><li>Why identify Test Requirements? </li></ul><ul><li>Where does a Test Requirement come from? </li></ul>Defining TR’s: What, Why, Where
  5. 5. What exactly is a Test Requirement? <ul><li>Identifies the “WHAT” of testing </li></ul><ul><ul><ul><li>What needs to be tested, AND </li></ul></ul></ul><ul><ul><ul><li>What are you going to validate about it </li></ul></ul></ul><ul><li>Includes both normal and error conditions </li></ul><ul><li>Covers business rules, functionality, non-functional standards </li></ul><ul><li>Do NOT have case specific data values assigned to them yet (data appears in test cases, the “How” of testing) examples … </li></ul>Defining TR’s: What, Why, Where
  6. 6. Example 1: Testing the inserting of a record to a table <ul><li>“ Validate that you can insert an entry” </li></ul><ul><li>“ Validate that insertion fails if entry already present” </li></ul><ul><li>“ Validate that insertion fails if table already full” </li></ul><ul><li>“ Validate that you can insert an entry to an empty table (initial)” </li></ul><ul><li>These are test requirements NOT tests because they do not describe the data element being inserted </li></ul><ul><li>The data is irrelevant at this level, it will appear in the test cases used to cover these test requirements </li></ul><ul><li>“ Validate you can insert ‘John Doe’” is a test case not a test requirement </li></ul>Test Requirements Identified (among others): Defining TR’s: What, Why, Where
  7. 7. Why identify Test Requirements? <ul><li>It’s what QC “owns” in our workbench: Requirements-based or Function-based testing </li></ul><ul><li>It’s the basis for establishing the completion of testing </li></ul><ul><li>Helps determine the scale of the testing effort </li></ul><ul><li>Governs the types of resources you will need </li></ul><ul><li>Serves to identify automation strategies you can use </li></ul><ul><li>Becomes a roadmap for your testing effort </li></ul><ul><li>Can be a tool for leverage and dialog with developers and business analysts </li></ul><ul><li>Dev Team can sign off on them (Verification!) </li></ul>Defining TR’s: What, Why, Where
  8. 8. Where does a TR come from? <ul><li>Traditional: Business Requirements, functionality, internal logic… </li></ul><ul><ul><li>Marketing specs, Functional specs, Technical specs </li></ul></ul><ul><li>Reality: </li></ul><ul><ul><li>“Interview Analysis”, Non-Functional Checklists (standards & compliance), Use Cases (from business scenarios and users), Discovery during testing, any other deliverables from previous workbenches (diagrams, modeling, flowcharts, etc.) </li></ul></ul>Defining TR’s: What, Why, Where
  9. 9. How do Test Requirements relate to the Test Plan? <ul><li>Traditionally, the Test Plan has represented “what” was going to be tested, even including test cases. </li></ul><ul><li>Paradigm is shifting: Test Plan should relate what your testing process (and deliverables) will be for a particular project. </li></ul><ul><li>A Test Plan should build confidence in the testing process for a project, making approaches clear. </li></ul><ul><li>A Test Plan can include the Test Requirements </li></ul><ul><li>However, if the Test Requirements are too lengthy, they should become their own document: A Test Requirements Hierarchy </li></ul>Defining TR’s: What, Why, Where
  10. 10. Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><li>What’s within our testing process </li></ul></ul><ul><ul><li>Generating TR’s </li></ul></ul><ul><li>Organizing & Decomposing TR’s </li></ul><ul><li>Test Requirements Hierarchy Samples </li></ul><ul><li>Setting the stage for measuring test coverage </li></ul>
  11. 11. Drilling down: Where test requirements fit into the picture Business Requirement Test Requirement Test Scenarios/ Cases Test Procedure/ Script Fitting TR’s into the testing picture Generates 1 M Generates 1 M Executes/Runs 1 M
  12. 12. Drilling Down Business Requirement Test Requirement Test Scenarios/ Cases Test Procedure/ Script Fitting TR’s into the testing picture First, Let’s look at this relationship: What’s within our testing process Then we’ll look at this relationship: Gernerating TR’s from what feeds into our testing process
  13. 13. ATM Example: Practice Writing Test Requirements <ul><li>Business Requirements: </li></ul><ul><li>- “ATM must do withdrawals” </li></ul><ul><li>- “Withdrawals are between $20-$300” </li></ul><ul><li>- “Withdrawals are in $20 multiples” </li></ul><ul><li>Group Exercise! </li></ul><ul><li>1. Limit the scope to these 3 requirements. </li></ul><ul><li>2. What will you validate (test for)? </li></ul><ul><li>3. Are there any implied requirements that may not be written out? </li></ul>What’s within our testing process
  14. 14. Example 2: Testing Withdrawals on an ATM <ul><li>“ Validate that a withdrawal option is available” </li></ul><ul><li>&quot;Validate that a withdrawal of a multiple of $20, between $20-$300 can be done&quot; </li></ul><ul><li>&quot;Validate that <$20 is not allowed&quot; </li></ul><ul><li>&quot;Validate that >$300 is not allowed&quot; </li></ul><ul><li>&quot;Validate that $20 multiples >$300 is not allowed&quot; </li></ul><ul><li>&quot;Validate that non-$20 multiples between $20-$300 not allowed&quot; </li></ul><ul><li>&quot;Validate strange numeric amounts/combinations not allowed (all zero's, all 9's, 20.0000)&quot; </li></ul><ul><li>“ Validate that the withdrawal received is equal to the amount requested” </li></ul><ul><li>&quot;Validate that a valid withdrawal amount must be below the account balance” </li></ul><ul><li>These are test requirements NOT tests because they do not describe the data element being used (like $20, $40, $60, $1) </li></ul><ul><li>The data is irrelevant at this level, it will appear in the test cases used to cover these test requirements </li></ul>Test Requirements Identified (among others): What’s within our testing process
  15. 15. Test Scenarios/Cases for - “Validate that a withdrawal of a multiple of $20, between $20-$300 can be done” What’s within our testing process
  16. 16. Test Procedure & Script for previous example <ul><li>Step 1: Insert Card </li></ul><ul><li>Step 2: Enter PIN </li></ul><ul><li>Step 3: Select Withdraw option </li></ul><ul><li>Step 4: Enter dollar amount </li></ul><ul><li>Step 5: Validate amount received </li></ul><ul><li>Do until EOF ‘until end of data file </li></ul><ul><li>Input data record </li></ul><ul><li>Senddata CARDINFO to “Cardfield” </li></ul><ul><li>Senddata “Enter” </li></ul><ul><li>Senddata PIN to “PINFfield” </li></ul><ul><li>Senddata “Enter” </li></ul><ul><li>Senddata “W” to “SelectionField” </li></ul><ul><li>Senddata AMOUNT to “DollarField” </li></ul><ul><li>Senddata “Enter” </li></ul><ul><li>If ErrorMsg > 0 then print ErrorMsg </li></ul><ul><li>Print “DollarAMTgiven” </li></ul><ul><li>Loop </li></ul>Procedure: Script: (in pseudo-code ) What’s within our testing process Think Manual ! Think Automated !
  17. 17. Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><li>What’s within our testing process </li></ul></ul><ul><ul><li>Generating TR’s </li></ul></ul><ul><li>Organizing & Decomposing TR’s </li></ul><ul><li>Test Requirements Hierarchy Samples </li></ul><ul><li>Setting the stage for measuring test coverage </li></ul>
  18. 18. The Workbench Concept Generating TR’s Our workbench is called “Generating Test Requirements” DO DO Check Standards Tools Rework Entrance Criteria Exit Criteria Product Input Product Output
  19. 19. Entrance Criteria for Business Requirements to generate Test Requirements <ul><ul><ul><li>Visible ? </li></ul></ul></ul><ul><ul><ul><li>Clear? (unambiguous) </li></ul></ul></ul><ul><ul><ul><li>Complete? </li></ul></ul></ul><ul><ul><ul><li>Consistent? (conflicting requirements must be prioritized) </li></ul></ul></ul><ul><ul><ul><li>Reasonable? (achievable) </li></ul></ul></ul><ul><ul><ul><li>Measurable? (quantifiable) </li></ul></ul></ul><ul><ul><ul><li>Modifiable? (will it change or is it stable?) </li></ul></ul></ul><ul><ul><ul><li>Traceable? (the source is known) </li></ul></ul></ul><ul><ul><ul><li>Dependent requirements identified? </li></ul></ul></ul><ul><ul><ul><li>Testable? (given current environment, resources, skills) </li></ul></ul></ul>Generating TR’s
  20. 20. Exit Criteria for Test Requirements <ul><ul><ul><li>Can another tester create test cases/scenarios from these? </li></ul></ul></ul><ul><ul><ul><li>Does a Test Requirement specify what is being tested and what about it we are validating? (Clear?) </li></ul></ul></ul><ul><ul><ul><li>Are the Test Requirements… </li></ul></ul></ul><ul><ul><ul><ul><li>Complete? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Consistent? (conflicting requirements must be prioritized) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Reasonable? (achievable) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Measurable? (quantifiable for measuring test coverage) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Modifiable? (will it change or is it stable?) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Traceable? (the source is known) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Testable? (given current environment, resources, skills) </li></ul></ul></ul></ul><ul><ul><ul><li>Do the test requirements cover the complete scope of the project? </li></ul></ul></ul><ul><ul><ul><li>Are all the test requirements verified and signed off by the Development Team? </li></ul></ul></ul>Generating TR’s
  21. 21. When creating Test Requirements (“Do”)... <ul><li>Use “action” verbs & words </li></ul><ul><ul><ul><li>“Validate that…” </li></ul></ul></ul><ul><ul><ul><li>“Check for…” </li></ul></ul></ul><ul><ul><ul><li>“Test that…” </li></ul></ul></ul><ul><li>Trace them back to the source </li></ul><ul><li>Remember that different applications arrange in different ways </li></ul><ul><ul><ul><li>Think of MF, batch, C/S, web, e-commerce, GUI, etc. </li></ul></ul></ul><ul><ul><ul><li>Use “testing considerations” checklists that generally cover what kinds of things should be considered when testing your specific situation </li></ul></ul></ul><ul><li>Make your Test Requirements document a “living document” </li></ul>Generating TR’s
  22. 22. Also... <ul><li>Maintain a level of balance between too much & too little </li></ul><ul><ul><ul><li>Too High level: won’t be useful, vague, can’t generate test cases from it. </li></ul></ul></ul><ul><ul><ul><li>Too low level: Over-process, over documentation, no productivity </li></ul></ul></ul><ul><ul><ul><li>General rule: 5-7 levels deep in an outline format </li></ul></ul></ul><ul><li>Organize them! </li></ul><ul><ul><ul><li>Outline/Hierarchy format recommended </li></ul></ul></ul><ul><ul><ul><li>Look at how the BA breaks down the project into areas </li></ul></ul></ul><ul><ul><ul><li>Look at how the PA breaks down the project into areas </li></ul></ul></ul><ul><ul><ul><li>Organize by functional areas </li></ul></ul></ul><ul><ul><ul><li>Organize by “types” of testing (Function vs. System vs. Non-Functional) </li></ul></ul></ul>Generating TR’s
  23. 23. Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><li>What’s within our testing process </li></ul></ul><ul><ul><li>Generating TR’s </li></ul></ul><ul><li>Organizing & Decomposing TR’s </li></ul><ul><li>Test Requirements Hierarchy Samples </li></ul><ul><li>Setting the stage for measuring test coverage </li></ul>
  24. 24. Distinguishing the types of testing…. <ul><li>I. Function-Based Tests </li></ul><ul><li>II. User Interface Tests </li></ul><ul><li>III. Security Tests </li></ul><ul><li>IV. Installation Tests </li></ul><ul><li>V. Configuration Tests </li></ul><ul><li>VI. Performance Tests (Response) </li></ul><ul><li>VII. Load Tests (simultaneous users, lots of small transactions) </li></ul><ul><li>VIII. Volume Tests (Big transactions) </li></ul>IX. Stress Tests (breaking point: memory, resources) X. Resource Usage Tests XI. Documentation Tests XII. Compatibility Tests XIII. Recovery Tests XIV. Serviceability Tests and others… *III - XIV are all “Systems-based tests” Organizing TR’s
  25. 25. Organizing by Functional areas…. <ul><li>Most testers perform function-based, or requirements-based tests </li></ul><ul><ul><ul><li>Tests on functionality that the system will provide </li></ul></ul></ul><ul><ul><ul><li>Usually scenario/case based </li></ul></ul></ul><ul><ul><ul><li>includes normal and alternate (invalid) cases </li></ul></ul></ul>Organizing TR’s
  26. 26. Organizing by Functional areas…. <ul><li>Most testers also perform User Interface Style Tests </li></ul><ul><ul><ul><li>These are generally separate from the functionality that the software will provide </li></ul></ul></ul><ul><ul><ul><li>Usually encompass the architectural standards & compliance (like Windows Design Standards) </li></ul></ul></ul><ul><ul><ul><li>Also includes tests of navigation, menus, admin functions (like printing, saving) </li></ul></ul></ul>Organizing TR’s
  27. 27. Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><li>What’s within our testing process </li></ul></ul><ul><ul><li>Generating TR’s </li></ul></ul><ul><li>Organizing & Decomposing TR’s </li></ul><ul><li>Test Requirements Hierarchy Samples </li></ul><ul><li>Setting the stage for measuring test coverage </li></ul>
  28. 28. Remember this?…Drilling down Fitting TR’s into the testing picture
  29. 29. Decomposing: Drilling down within a Test Requirement Business Requirement Test Requirement Test Scenarios/ Cases Test Procedure/ Script Fitting TR’s into the testing picture Keep the function-based perspective in mind! Business Function Tasks within the Function Data Entry Types for transactions Transactions to perform a task Field Validation
  30. 30. Test Requirement Decomposition Decomposing TR’s
  31. 31. Test Requirement Decomposition Business Function Tasks within the Function Data Entry Types for transactions Transactions to perform a task Field Validation High level Functional Areas: usually from “ Functional Spec” type docs, or BA work Lower level Functional Areas: usually from “ Technical Spec” type docs regarding internal logic, or PA work Decomposing TR’s
  32. 32. Test Requirement Decomposition <ul><li>You can start on the high level functional areas early into the project & build in lower level areas as they become available </li></ul><ul><li>Any level can contain a test requirement which can also be made up of (or broken down into) lower level test requirements </li></ul>Decomposing TR’s
  33. 33. Business Function Level <ul><li>Try to identify “groups” of functions or functions connected by similar themes </li></ul><ul><ul><ul><li>file management functions, printing functions, help functions, car rental functions, reservation functions, ticket purchase functions, claim reporting functions </li></ul></ul></ul><ul><li>Be sure all areas of the system are covered. If something is left out or doesn’t fit into a group, it becomes its own group. </li></ul><ul><li>It may be easier to identify functional areas by “window” instead of by function. </li></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  34. 34. Business Function Level <ul><li>At this level, the idea is seeing the connections, integration, and interactions of the system’s functionality. </li></ul><ul><li>May not necessarily be identifying a test requirement at this level as much as just identifying the functional area. </li></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  35. 35. Task Level <ul><li>Break down each Function area into the tasks within the function </li></ul><ul><li>For complex tasks, it is possible to break them down further into sub-tasks </li></ul><ul><li>Some Business Functions can not decompose into further tasks (example: Check Writing function) </li></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  36. 36. Transaction Level <ul><li>From this level down, we start to address the internal things that occur to make the functions and tasks happen </li></ul><ul><li>Identify any logical transactions that ties the task to the database or any other transactions necessary to perform the task. </li></ul><ul><li>Identify any data processing, calculation, data formatting type transactions </li></ul><ul><ul><ul><li>Note: A screen or window may cause the execution of several different logical transactions </li></ul></ul></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  37. 37. Transaction Data Type Level <ul><li>Identify which of the four types the transaction can become: Add, Change, Delete, Inquire </li></ul><ul><li>It is entirely possible that a transaction can be multiple types. </li></ul><ul><li>If a transaction is only one type, you can wrap this level up into the higher level. </li></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  38. 38. Field Validation Level <ul><li>Most testers like to jump directly to this level. It’s the most obvious at times. </li></ul><ul><li>Field validation covers all edits & cross edits on fields and data. </li></ul><ul><li>Be careful of the detail you document at this level. Remember the separation between test requirement and test case. </li></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  39. 39. Field Validation Level <ul><li>Not all test requirements (especially at this level) fit well to be documented in this manner. </li></ul><ul><ul><ul><li>Example: Testing all the stated properties of windows objects </li></ul></ul></ul><ul><ul><ul><li>Use “Validate that the properties of all the objects in this window match the properties listed on the Object Properties Reference Table in Appendix B upon initialization of the window” </li></ul></ul></ul><ul><ul><ul><li>Don’t list each property check as a separate test requirement if it can be summarize under one test requirement </li></ul></ul></ul><ul><ul><ul><li>This is a judgement call YOU make for your given project. </li></ul></ul></ul>Decomposing TR’s Function Task Transaction Trans Data Type Field Validation
  40. 40. Example 3: Rental Car Application <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.1 Check Customer policy coverage </li></ul><ul><li>1.2 Query Car availability </li></ul><ul><li>1.3 Query Car rates </li></ul><ul><li>1.4 Open a Rental ticket </li></ul><ul><li>1.4.1 Validate that a customer record can be entered </li></ul><ul><li>1.4.2 Validate that credit card approval is obtained </li></ul><ul><li>1.4.3 Validate that status on the car record is changed </li></ul><ul><li>from “waiting” to “rented” </li></ul><ul><li>2. Billing Function </li></ul><ul><li>3. Reservation Function </li></ul>Let’s look at the lower levels for this one Decomposing TR’s Then we’ll try it on this one
  41. 41. Example 3: Rental Car Application <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket </li></ul><ul><li>1.4.1 Validate that a customer record can be entered </li></ul><ul><li>1.4.1.1 Validate that a new customer can be added to the customer table </li></ul><ul><li> 1.4.1.1.1 Validate that the first name is all alpha </li></ul><ul><li> 1.4.1.1.2 Validate that the age is > 21. </li></ul><ul><li> 1.4.1.1.3 Validate that the phone number is numeric </li></ul><ul><li> 1.4.1.1.4 Validate area code is an existing area code number. </li></ul><ul><li>1.4.1.2 Validate changing an existing customer </li></ul>Decomposing TR’s
  42. 42. Example 3: Rental Car Application <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket </li></ul><ul><li>1.4.2 Validate that credit card approval is obtained </li></ul><ul><li>… fill in the lower level test requirements! </li></ul><ul><li>First , Identify any sub-areas (further tasks, or even </li></ul><ul><li>separate transactions within this) </li></ul><ul><li>Then , Identify the lowest level field validation test </li></ul><ul><li>requirements (think about what is typically </li></ul><ul><li>involved with credit card authorizations) </li></ul>Decomposing TR’s
  43. 43. What did you come up with? <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket </li></ul><ul><li>1.4.2 Validate that credit card approval is obtained </li></ul><ul><li> _________________________________________ </li></ul><ul><li>_________________________________________ </li></ul><ul><li>_________________________________________ </li></ul><ul><li>_________________________________________ </li></ul><ul><li>_________________________________________ </li></ul><ul><li>_________________________________________ </li></ul><ul><li>_________________________________________ </li></ul><ul><li>_________________________________________ </li></ul>Decomposing TR’s
  44. 44. Possible Test Requirements... <ul><li>1. Validate that a Rental can occur. </li></ul><ul><li>1.4 Open a Rental ticket </li></ul><ul><li>1.4.2 Validate that credit card approval is obtained </li></ul><ul><li>1.4.2.1 Validate the expiration date is a valid future date </li></ul><ul><li>1.4.2.2 Validate the expiration date is not within 1 month of </li></ul><ul><li>expiring. </li></ul><ul><li>1.4.2.3 Validate that the CC# is 12 digits </li></ul><ul><li>1.4.2.4 Validate that the $ amount is <= credit balance available </li></ul><ul><li>1.4.2.5 Validate that an authorization # is received. </li></ul>Decomposing TR’s Function Task Transaction
  45. 45. Agenda <ul><li>Defining TR’s: What, Why, Where </li></ul><ul><li>Fitting TR’s into the testing picture </li></ul><ul><ul><li>What’s within our testing process </li></ul></ul><ul><ul><li>Generating TR’s </li></ul></ul><ul><li>Organizing & Decomposing TR’s </li></ul><ul><li>Test Requirements Hierarchy Samples </li></ul><ul><li>Setting the stage for measuring test coverage </li></ul>
  46. 46. TRH Samples <ul><li>Let’s look at a few examples of how test requirements can be organized: </li></ul><ul><ul><ul><li>Sample 1: Excerpt from a Personal Finance app </li></ul></ul></ul><ul><ul><ul><li>Sample 2: actually organizing Function requirements, but good representative of the concept </li></ul></ul></ul><ul><ul><ul><li>Sample 3: QBS, from Rational’s sample project (adds types of testing into the hierarchy) </li></ul></ul></ul><ul><ul><ul><li>Sample 4: another view of the Personal Finance app </li></ul></ul></ul><ul><ul><ul><li>Sample 5: A mainframe batch system </li></ul></ul></ul>
  47. 47. Test Coverage Measures <ul><li>Test Requirements are the “what” of testing & are the basis for establishing the completion of testing </li></ul><ul><li>TR’s give us the point of measurement for test coverage </li></ul><ul><li>Each TR should receive a Priority, Risk, and Weight </li></ul><ul><li>Each TR should be tracked for Verification (  ) and Validation (%) </li></ul>Test Coverage Measures
  48. 48. Summary & Recap <ul><li>Defined: What, Why, Where </li></ul><ul><li>Described: How TR’s “fit” into the big picture </li></ul><ul><li>Decomposed: Organizing TRs & Generate TR’s into a measurable format </li></ul><ul><li>Demonstrated: Sampling some TRH </li></ul><ul><li>Determined: The Measurement Connection </li></ul>

×