Testing Walls

Testing walls

This is the next post in my series on the types of walls that we can use when we are sharing our knowledge with out teams.

Testing walls are similar to architecture walls but take a different dimension. By using the walls as a basis, you and your team can share information about test type (unit, integration, system, acceptance, hardware), test coverage, test results, test approach (automation/manual), or test focus (functionality, performance, usability, reliability etc). Test coverage can be classified by colour (the type or level of testing) and also by status (pass or fail).

One of my favourite approaches is to have a high level architecture diagram and then cover it with cards indicating the testing planned either manual or automated, at what level.

Test Coverage Plan

As the testing progresses the cards can be annotated or coloured either red or green for pass or fail.

Test Result Mapping

If the team wishes to track defect density, adding a red card every time a test fails allows the thickness of the card pile to reflect the riskiness of the code/solution underneath. This is excellent for selecting likely regression tests to run during an iteration or a release.

This approach can also be used to track automation, regression, non-functional attributes or any other aspect of test coverage that is required to be known by the team. This is a very powerful tool in spotting defect clusters as well as areas of the system that are highly fragile and prone to regression.