Water Fall 2.0

Defending Waterfall.

I believe that there are projects that need the thought and planning up front. Where the delivery and integration components require Requirements and Designs to be locked in up front.

I also believe that waterfall needs to move on from the document and process heavy methodology of the 90s and early 2000s, to a more efficient and effective life cycle.

The following page is a page under development at the moment and will change as I add and update ideas in an effort to articulate my thoughts into what I call Waterfall 2.0.

 Feel Free To Leave Comments

 

Some key thoughts

The strength of the English language is its ability to adapt and evolve. It brings back into common usage words from the past. It adapts words or adopts them from other languages. Waterfall 2.0 needs to be like this, bringing in the best of other methodologies and adapting to circumstance.

In the SDLC and the TDLC there are no rules there are guidelines and as such Waterfall 2.0 should be a collection of tools, with a user pulling out the pieces that fit their problems.

 Assumptions

Requirements change less than designs

 

Some Key Rules

  • Documents should be distilled to their essence
  • If the cost of a process or an artifact exceeds its value, then do not do or produce it
  • Identify problems early
  • All process and artifacts must have a feedback loop.
  • Effectiveness over Efficiency

Documents

I know that I am changing the roles of these documents, but this is an effort to make them quicker to produce and have less churn

Document Heirachy V0.1

 

 

 

The Test Strategy

This document should contain static information on the testing process. It should be reviewed

  • Yearly
  • If the delivery framework changes
  • As part of project reviews

Generally every organization should have one and only one Test Strategy. It should not be a living document.

 

Cross party projects should have their own test strategy. It should be a static document and provide a common framework. Generally the integrator should own the production of this and each party that involved in the development or testing should be a signatory.

 

A test strategy’s content can change depending if it is for a single organization or a cross party engagement.

Should contain for both documents

  • Document control block
  • Defect definitions
    • Severity
    • Priority
  • Test Environments
    • Locations
    • Access
    • Support hours
  • Glossary
  • Types of Testing
    • What each type entails
    • Supporting collateral
    • Acceptance into testing criteria
  • Document Hierarchy
  • Roles and Responsibilities
  • Tools
  • Static Testing Risks and Mitigations
  • Reporting heuristics
  • Artifact arching durations and process
  • Data management and anonymization rules
  • Project close out process
  • Test Objectives
    • Success Criteria

Additional items for a cross party strategy

  • Delivery milestones
  • Suspension and Resumption criteria

 Test Plan

The test plan is the document that articulates the test process and constraints. It sits between the strategy and the cases.

I am not a great fan of the test plan having the test case titles in it. I thing that it pushes a determination of detail to early.

I am a great fan of the Test Plan on a page approach. Where each module, component of functional area has a test plan. If you cannot get the detail onto 2 pages, then you need to go more granular.

For large projects a collection of test plans can be grouped together to create a master test plan as this can aid in sign off.

Test plan needs to contain

  • What is under test ( and what is not under test)
  • Test Objectives
  • Resources
  • Tools Required
  • Data criteria
  • Test Tasks (Test Philosophies)
  • Location and dates

 Test Cases

Here is where we get to what we are actually testing. I have preference of Excel sheets over Word or Mind maps as I find reporting easier.

A test case is a collection of scripts

I like to see requirement listed with test cases underneath.

Testers should be given time each week (or for each module) to do guerilla testing

 

 

Test Case ID Requirement ID Requirement or Test Script detail Positive Test Completed Negative Test Completed Boundaries Tested Notes
T01R1 R01 Requirement to form part of the Traceability matrix
T02R01 Test Script  to prove requirement
T03R01 Test Script to prove requirement
T04R01 60 minute Guerrilla Test to prove R01
T05R02 R02 Requirement to form part of the Traceability matrix
T06R02 Test Script to prove requirement
T07R02 Test Script to prove requirement

 

Contributions

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *