CBOK Skill Category 6.B.2.b – Test Program Development
i. Test Strategy:
• “Describes the overall approach that the test team will use to test, in each phase and in all.”
Ø A Game Plan
• The game plan to implement
“What is to be tested, when, how, how long and till what happens?”
Test strategy helps the overall test effort estimation.
Test Strategy Considerations
Ø Product Requirements
Gather product requirements to identify strategies. This could include portability, compatibility and maintainability issues.
Ø Nature of product
This can identify the kind of tests to perform. E.g.: A single user application doesn’t need load testing, where as a web application requires one.
Ø Product Lifecycle
An incremental, multiple release product, requires planning on regression testing.
Ø Milestones
Product milestones and testing effort have to match. You can’t be testing ever.
Ø Repeatability considerations
Does the test design require this to be incorporated. Decision to use Automated tools can reduce planning on this note.
Ø Environment
Product environment plays a key role in deciding the nature of tests, types of tests and number of tests to execute.
Ø Feedback
• Process improvement.
• Change in strategy, if required.
• Mechanism to re-visit test plans, if required.
• Give pointer on
Metrics
Provide for statistical control process.
Ø Cost
Is the strategy “within budget?”
Evaluation of a test strategy
Ø Plan Early
• Start working out a Test Strategy during the requirements phase of SDLC.
• Map Test Strategy with the final goals of the product.
• Revisit strategy to see whether it fits Quality goals.
Ø Formal Reviews
• Conduct formal reviews of Test Strategy with product teams.
• Identify effort and check feasibility.
Ø Discuss with Project team/user
• Identify clashes of Test Strategy with product delivery patterns and product expectations.
• Identify feedback mechanisms and set a process.
• Identify and agree on Resources/Environment needs.
Ø Involve user ( in case of acceptance tests)
• Identify whether testing strategy meets user needs.
Other Resources:
ii. Test Planning
Ø Test Planning definition
. “To prescribe the scope, approach, resources and schedule of testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan.” -ANSI/IEEE standard 829/1983 for software Test Doc
Ø Goal
• Communicating to the test team
Intent, expectations, understanding of the testing
Ø Expectations
o Purpose
o Must be based on Product specifications to be tested.
o Quality and the reliability goals
o Based on the Test Strategy.
Ø Resources
• Personnel
• Hardware, Software, Test Bed requirements
Ø Test Scope
o What will be tested and what will not be tested?
Ø Assignments
o Individual assignments to test teams
o Work Break down structure on testing activities.
Ø Schedule
• Map project schedule to Test schedule.
• Deadlines.
Ø Bug Reporting
o Set a process
Ø Others
o Metrics and Statistics
o Risk and Issues
o Purpose
- Organize and Describe the testing.
- “Refine the test approach defined in the test plan”
Ø Test Design Considerations.
• Descriptive.
• Defines Purpose.
• Has a clear Identifier
• Reproducible
• Criteria for Pass/Fail
• Exit Conditions.
iii. Cases.
Ø Test Cases
o Documents the actual values used for input along with the anticipated output.
Ø Contains
Ø Identifier
Ø Input specification
Ø Output specification
Ø Environmental needs
Ø Pre-Conditions
Ø Post-Conditions.
Ø Pass/Fail criteria
Ø Exit Conditions
iv. Procedures.
Ø Test Procedures
o Identifies all steps required to operate the system and exercise the specified test cases, which implements the specified test design.”
Ø Contains
o Purpose
o Environmental needs
o Procedure steps
o Log
o Contingencies
o Pre and Post test conditions.
Ø Test Data
o “Creates a set of static re-usable test data that can be preserved during regression and use for reproducing defect.”
Ø Contains
o Identifier
o Purpose
o Environmental Requirements
o Basis for generation
o Usage Mapped to test cases.
o Initialization parameters
o Static content
vi. Specifications.
For each test case, the coverage item, the initial state of the software under test, the input, and the predicted outcome.
vii. Scripts.
Commonly used to refer to the automated test procedure used with a test harness.
viii. Analysis techniques.
Following are the typical tasks involved after the testing has been performed:
- Record Defects
- Perform Data Reduction
- Develop Findings and Recommendations
- Finalize Test Report
- Test Report Quality Control
- Test Defect Report
- Test Defect List
- Test Defect Log
Typical Test Metrics
- Defect Reports
- Requirements Implemented
- Backlog of Defects (Not Corrected)
- Status of -
- Project, Tests, Schedule, Budget
- Resources Consumed in Testing
- Effectiveness of Testing
The QAI Test Toolbox [1]
Data Modeling, Boundary Value Analysis, Capture/Playback, Cause-Effect Graphing, Change Control, Trackers, Checklists, Checkpoint Review, Code Comparison, Compiler-based Analysis, Complexity-based Analysis , Compliance Checkers, Control Flow Analysis, Correctness Proofs, Coverage Based Analysis, Data Dictionary, Decision Tables, Defect Trackers, Desk Checking, Equivalence Partitioning, Error Guessing, File Comparison, Flowcharts, Help Desk Trackers, Inspections, Instrumentation, Integrated Test Facility, Mapping, Model Animation, Model Balancing, Network Analyzers , Performance / Timing , analyzers, Population Analysis, Risk Matrix, Scoring, Snapshots, Symbolic Execution, System Logs, Test Case Generator, Test Data Generator, Test Scripts, Test Stubs and Harnesses, Test Suite Managers, Tracing, Walkthroughs, Test Tools , Boundary Analysis , Types of Functional and, Structural Tests , Population Analysis, Checklists
Source:
[1] www.sasqag.org/pastmeetings/napier.ppt
Incoming search terms for the article:
- example test procedure report pdf
- mapped tested
- questions and answers to afaa ptc test
- skill working category a b and o
Related posts
Uncategorized
