This action might not be possible to undo. Are you sure you want to continue?
• • • • • Importance of Test Data Test Data Preparation Using BVA and EP for preparing Test Data Test case preparation Mapping Test data with the Test case
Test Strategy Test Plan Test Case Test Data Test Bed Setup Execute Test Cases Log Defects Status Report
Importance of data in testing
Why data is important during testing • How do we test abnormal conditions? • On what basis do we convey that there is a defect in the software?
usually used for back-end testing) or information that the tester will enter during testing (ex. which is usually used for front-end testing. • Should be cross-referenced in the Test Script.Test Data • Input and/or expected files used during test execution. password. • May be in the form of generated input files. 4 . username).
conditions as counters. flags etc – Test data close matching the real data : used during system testing – Real user data : used especially during UAT 5 .Test data • Types – Variable data : used normally in unit testing • used in program statements • Eg: Variable declarations. loops.
Limit values. Negative values. Values that are not within the normal range but are acceptable. they need special processing (e. Unacceptable values. Acceptable values : also called positive data values 2. Exception values. 6 . Values that are not normal but can occur.Test Data Creation Process In addition to normal positive conditions. 3. receiving an empty file as the input).. Data out of range 4.g. the test conditions address the following: 1.
one valid and one invalid equivalence class is defined – If an input condition is Boolean. one valid and two invalid equivalence classes are defined – If an input condition specifies a member of a set. one valid and one invalid equivalence class is defined 7 .Equivalence Partitioning • Black-box technique that divides the input domain into classes of data from which test cases can be derived • An ideal test case uncovers a class of errors that might require many arbitrary test cases to be executed before a general error is observed • Equivalence class guidelines: – If input condition specifies a range. one valid and two invalid equivalence classes are defined – If an input condition requires a specific value.
Equivalence Partitioning . 8 . – <100 – 100-999 – >999 • Test the system for numbers which falls in these classes – Any number between 0-99 – Any number between 100-999 – Any number between >999 • Typically boundary values is not considered.Example • Suppose a system asks for the input numbers between 100 – 999 • This gives three equivalence classes.
values just above and just below a and b – If an input condition specifies and number of values. test cases should include a and b. test cases should exercise the minimum and maximum numbers.Boundary Value Analysis • Black-box technique that focuses on the boundaries of the input domain rather than its center • BVA guidelines: – If input condition specifies a range bounded by values a and b. as well as values just above and just below the minimum and maximum values • Apply guidelines 1 and 2 to output conditions. test cases should be designed to produce the minimum and maximum output reports 9 .
1000 • Typically values which falls far away from boundary values are not considered.Example • Suppose a system asks for the input numbers between 100 – 999 • This gives two boundary values. 999.101 – 998.100.Boundary Value Analysis . 10 . – 100 – 999 • Test the system for numbers which falls around these values – 99.
Questions and Comments • What questions or comments do you have? 11 .
Test Plan • • • • • • • • • • • • Scope and Purpose Testing Strategy (Testing types/levels to be considered) H/w and S/w requirements Schedule and metrics to be collected Version control procedures Features to be tested/not to be tested Resources/Roles/Responsibilities Dependencies Risks and Mitigations Other Assumptions (If any) Tools to used Approval and Review procedures 12 .
test cycles will be executed A detailed documentation of the exact steps that a tester must follow to complete testing (i. and by whom. including the data that will be used for testing.Test Terminologies Test Approach Test Scenario Test Cases An analysis of all major aspects of the test phase that could affect the success of that phase High level description of functionality areas that will be tested. A list of items that must be tested to fully test the associated test scenario. therefore. details a low level test and will have a corresponding expected result A matrix defining when. to test all the conditions). 13 Test Cycle Sheet Test Steps .. and are derived from the specification that must be tested. each condition.e.
Test Case • • • • • • • • • Req ID Test Case ID Test Condition/Description Pre-Requisite Test Step (Test Script) Test Data Expected Result Actual Result Status (Pass/Fail) 14 .
etc. Example: “An invoice is created.” Requirement or design source Each test condition is derived from one requirement or design item. print. Example: “Create invoice.” For each test condition.Test Condition Properties Name and description of the test condition Expected result Begin these with an action verb: create. define a corresponding expected result. 15 .
Consider if the test data should be embedded (explicitly specified) as part of the Test Case document. Document test conditions using a table or spreadsheet.Test Conditions: Key Considerations 1. 2. 16 .
2. 4.Using the TC Creation Process 1. 17 . Derive TC from Requirements (and/or Test Scenarios). 3. 5. Trace each TC back to a specific requirement. Verify that detailed functional requirements have been met. Group TC logically by Test Cycle. Create TC during the Design stage and refine as the project progresses.
Cover all Test Conditions. step-by-step instructions. Should provide a high degree of detail. Follow a standard format.Characteristics of Good Test Case • • • • • • • • Provide explicit. Reference necessary input data. Both the Assembly Test Condition and the Expected Result should closely match the corresponding Test Scenario and detailed Functional Requirement. 18 . Are reusable. both in the condition and the expected result. Are highly detailed.
Discuss: Which example is better? Why? 19 . Read the sample Test Conditions and Expected Results below.Examples: Good and Bad TCs 1. 2.
Read the sample Test Conditions and Expected Results below. Discuss: Which example is better? Why? Figure 1b specifically addresses the stated requirement. 2. 20 .Examples: Good and Bad TCs 1. and includes all necessary criteria to ensure that the requirement is fully satisfied.
• How does one write a test step? – Detail the exact steps that a tester must follow to complete testing (i. 21 .Creating Test Steps • When does one write a test step? – In order to enable the tester to execute specific actions and compare actual results to expected results.. – Are documented using a table or spreadsheet format (or a test management tool). – Include the data that is used for testing. to test all the conditions).e. – After sufficient application details are gathered to aid in the writing. – Immediately prior to test execution.
• Follow a standard format. • Reference necessary input data.Characteristics of Good Test Step • Provide explicit. • Are highly detailed. • Are reusable. step-by-step instructions. • Cover all Test Conditions and Expected Results. 22 .
When a defect is identified.001 Action / Description Enter User Name Create User Password Input Data First Name: XXX Last Name: XXX Middle Initial: X Password: XXX Retype Password: XXX Expected Result Page displays the entered information Password is displayed as a series of asterisk (***) 1.002 The Step Number field identifies each step to be executed. the corresponding Step Number should be documented in the SIR. 23 .Test Step Fields Step Number 1.
and should only describe one action at a time.001 Action / Description Enter User Name Create User Password Input Data First Name: XXX Last Name: XXX Middle Initial: X Password: XXX Retype Password: XXX Expected Result Page displays the entered information Password is displayed as a series of asterisk (***) 1.Test Step Fields Step Number 1. Each of these steps should begin with an action verb. and should be based off of the existing Test Conditions.002 The Action/Description field provides detailed directions as to HOW to execute each step. 24 .
001 Action / Description Enter User Name Create User Password Input Data First Name: XXX Last Name: XXX Middle Initial: X Password: XXX Retype Password: XXX Expected Result Page displays the entered information Password is displayed as a series of asterisk (***) 1. 25 .002 The Input Data field lists each field for which the tester should input data to complete the Action/Description. Note that this field only lists the type of data to be entered (hence the “XX” format). the data itself is housed in a separate document.Test Step Fields Step Number 1.
002 The Expected Result field should be closely aligned with the existing Test Conditions and Expected Results. It should explicitly describe the result testers should see upon completing the action for that step.Test Step Fields Step Number 1.001 Action / Description Enter User Name Create User Password Input Data First Name: XXX Last Name: XXX Middle Initial: X Password: XXX Retype Password: XXX Expected Result Page displays the entered information Password is displayed as a series of asterisk (***) 1. 26 .
Test Bed setup • • • • • • • • Client environment and testing environment should be same First uninstall the previous build (if any) Use a separate test environment There must no development tools installed in test bed Ensure right OS and service pack installed Ensure right system configuration Ensure disks have enough space for application Carry out a virus check if needed 27 .
Test Execution Process • Prerequisites to Successful Test Execution • • • • • • Planning and preparation are complete Inspections have occurred Environment is well established and ready Test team is trained Migration procedures exist Test tools are used • Process to Execute the Test • • • • Execute the test case Compare the actual results to the expected results Identify and resolve any discrepancies Document the results 28 .
Paraguay. There is no postage surcharge for envelopes and post cards. Uruguay.The Postal Regulation The following postal regulation determines postage surcharges. Peru. Other postal items are envelopes and post cards. Chile. Guyana. not other types of postal items. Suriname.00 US: Table 1 . and Falkland Islands All weights $15 US Analyze the given requirement and prepare possible #Test Cases and test data 29 . French Guiana. For parcels which people mail to South America between December 1 and December 24 of each year.Country & Weight Surcharge between December 1 and December 24 Argentina Brazil Brazil Brazil All weights $11 US Weight > 33 pounds $21 US Weight = 33 pounds $19 US Weight < 33 pounds $17 US Columbia. Bolivia. Ecuador. and only to parcels sent to South America. Venezuela. This regulation applies only to parcels.An Example . the system will apply the surcharges in Table 1 in addition to the standard postage of $5.
Questions and Comments • What questions or comments do you have? 30 .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.