By Daniel Zrymiak (Accenture), ASQ Fellow
Dynamic Software Test Planning was inspired by actual events from testing an integrated systems solution for a major telecom company. Due to slippage of key program milestones and financial restrictions, the following client expectations had to be managed:
- Fixed release dates with no outstanding issues nor production defects
- Delayed provision of requirements and designs for test references
- Workforces located at different locations worldwide, operating at different time zones
- Cost-pressures on project require reduction of idle times or delays for short-staffed teams
- Constant changes to requirements and design during testing required rapid communication and adaptation to test approach and test artifacts (i.e.test data, test designs, test scripts, defect resolution activities)
The traditional Waterfall software development model has a “Finish to Start” critical path, meaning that activities cannot start in a phase until its preceding phase is completed.
- Requirements define product quality, acceptance criteria, and test approaches
- Tests must replicate production and real-life usage in expected conditions
- Test execution needs completed test designs and test artifacts
- Test environments and integration are required for deployment
- Defect management (reporting, diagnosis, resolution, release of fixes, retesting) is needed for identified defects across all phases
By referring to the House of Lean Model, we can
- Identify wastes that could be reduced or eliminated
- Consolidate activities
- Standardize, parallelize, and expedite repetitive tasks
- Educate testers on objective software testing methods
- Use global staff distribution to ensure continuous work and handover
Software Test “TIMWOODR” Wastes can be specified for future reference
Software Testing operates in an imperfect world and must manage its own internal backlogs strategically to have a level and predictable workflow.
Software Testing can progress by moving work across internal backlogs by
- Responding to the availability of dependent configuration items
- Requirements, Designs, Code, Environment
- Working on a demand-driven basis through Backlogs
1: Test Design
2: Test Data
3: Test Automation
4: Test Execution
5: Defect Resolution
6: Integration
Each Backlog Phase is outlined, revealing the following traits:
Dependency: What is needed to begin or continue the phase
Demand: The work expected to be performed during the phase
Deliverable: Artifacts produced in the phase for downstream phases
Enables: How the work from this phase adds to the test effort overall
Backlog 1: Test Design
This is the initial phase
Once the requirements are available, the subsequent backlogs can be activated.
Backlog 2: Test Data
This phase enables test execution to simulate production environment use and real-life scenarios.
Test data is often necessary to activate certain features or conditions which demonstrate the functionality and reliability of the application under test.
Backlog 3: Test Automation
This is the phase which is done concurrently to Test Design and Test Execution.
Once tests are standardized and replicated, they can be programmed for rapid repetition and expanded to scale.
Consideration of cost-benefit and impact to schedule should be evaluated for the extent and complexity of automation. Some SW Test types (i.e. Performance) require automation for feasibility.
Backlog 4: Test Execution
This is the core phase of Software Testing. The success of this phase is dependent on the outcomes of prior phases.
This is where the value of Software Testing is applied.
Backlog 5: Defect Resolution
This is the rework phase, and is often the last phase prior to Integration and Release
Defect Resolution may cause redesign, and Software Testing should adapt to new development choices.
Backlog 6: Integration
This is the final phase
Once the product is integrated, the test artifacts are made available to the Product Maintenance functional areas.
In order to track and control the various backlogs, an integrated status is needed to ensure visibility and planning for all relevant configuration items and Software Test deliverables.
Waterfall model waits for completion of one phase before starting the next phase (Finish to Start Task Dependency),
Dynamic Software Test Planning starts the next phases concurrently with existing tasks (Start to Start +1 Task Dependency).
By changing the dependencies, the waiting and idle times are largely removed from the critical path.
Staffing will be flexible, but is highly dependent on having
- versatile resources capable of operating productively across all phases
- cross-trained and competent resources who can quickly adapt to changes in scope, schedule, and expectations.
In conclusion, the successful outcomes were demonstrated by:
- Identification and reduction of wastes and countermeasures,
- Determination of Value Streams, owners, and assignments,
- Compression of Software Test project schedules
- Adaptation and responses to unexpected changes in requirements, designs, conditions, and expectations
- Consolidated report across 6 Backlog Phases
Dynamic Software Test Planning compresses the critical path by reducing the distance and duration between test phases. Software Testing work can start on demand once sufficient dependencies and artifacts are provided to enable progress.
About the Author: Daniel Zrymiak is the ASQ Regional Director for ASQ Region 4, Canada, for the 2015-2016 term. He is a software quality practitioner and instructor in Vancouver, British Columbia, Canada. An ASQ fellow member, he received the Feigenbaum Medal in 2001, and is certified as a Six Sigma Black Belt, quality manager, quality engineer and software quality engineer. He also has lead auditor certifications for biomedical, hazard analysis and critical control point (HACCP), environmental, and quality auditing. Mr. Zrymiak has a business degree with honors from the University of Saskatchewan, and is presently pursuing post-graduate studies. He can be reached at daniel.zrymiak@accenture.com