Lecture 10 Flashcards
Test Planning (TP)
The process of effectively organizing the testing activities for all the components associated with a solution.
[TP] Test Plan
Documents the strategy that will be used to verify and ensure that a product or system meets its design specs and other requirements. (Acceptance test plan, Unit test plan, Integration test plan)
[TP] Master Test Plan
A single high-level test plan for a project/product that unifies all other test plans.
[TP Test Plan] Document
- Plan ID
- Test Items
- Risk Issues
- Features to be tested/not tested
- Test Approach
- Pass/Fail Criteria
- Suspension Criteria
- Test Deliverables
- Environmental Requirements
- Staffing/Training Needs
- Schedule of Test
- Planning for Risks
- Approvals
[TP Test Plan] Approach/Strategy (Strategy)
- Special tools to be used
- Metrics to collect
- Configuration Combos
- Levels of Regression Testing
[TP Test Plan Strategies] Risk Based Testing (RBT)
Testing the functionality which has the highest impact (freq. of use) and rate of failure, due to lack of time, $, etc.
[TP Strategy RBT] Details
- Starts early in project to ID risks to system quality
- Uses info acquired to guide test planning/prep/execution
- Idea: Organize testing to reduce product risk of a deployed system
- Testing to achieve product outcome that balances risks with quality, features, budget, and schedule (QUALITY TRIANGLE)
[TP Strategy RBT] Test Strategy
1: Business analysis to understand reqs/process
2: Risk analysis (based on biz knowledge + solution): Higher risk => more testing
[TP] Test Completion (Pass/Fail) Criteria
- @ Unit Test Level: more focused on test cases themselves (of all % of test cases completed, allowable % of defects, code coverage tests)
- @ Master Test Plan Level: focused on child test plans (ex: all lower test plans complete, % of test plans w/out defects)
- In General: What’s the % and severity of defects?
[TP] Purposes
- Communicate with project team
(Org. Test policies/motivations)
(Test scope, objective, critical areas)
(Proj/Prod risks, resource considerations and constraints) - Manage Change
(Plans revise throughout projects lifetime - risk based change management helps manage change)
Test Execution (TE) verification or validation?
Executing code and comparing actual with expected results (AKA VALIDATION)
[TE] Guidelines
- TE occurs in a test/qa environment
- occurs in 2+ cycles (all tests executed in each cycle to ID/report/resolve critical defects, and most high defects)
- Test Readiness Review determines if test item can move into Test Execution phase (more common in waterfall, but appears in agile too sometimes)
[TE] Process
1) Select a subset of tests for each cycle based on an overall risk management strategy
2) Continuously execute tests, report defects, capture test status
3) Resolve blocking issues as they arise
4) Report status, adjust assignments, and reconsider plans/priorities daily
5) Report test cycle finding & status
Defect Tracking (DT)
Tracking the logged defects in a product from beginning to closure, and making new versions of the product that fix the defects.
[DT] Process Flow
DIAGRAM
