Confidential Information Overflow Is too much information a bad thing? Rev PA1 2011-12-07 1
Introduction A tester’s job is to generate information and decision material for different stakeholders What happens if the tester generates too much information which the stakeholder has to analyze, preventing the stakeholder from doing much else, such as correcting defects in the case of a developer? This is not a right/wrong situation – if the tester withholds information that is deemed low priority or not important, that same information could be extremely critical from a stakeholder perspective
Practical Example A developer has 8 hours in a day Each defect takes 30 minutes to analyze Each defect takes 4 hours to fix A tester submits 8 issues developer has time to fix 3 issues A tester submits 24 issues developer has time to fix 1 issue
Triage Of course you can have a Triage team which looks at the defects and prioritize them for the developers, so that the most critical defects are fixed first The problem is that the developer still has to analyze all the defects before the Triage team can prioritize them
Problem? Information Overflow becomes a problem when the inflow of defects is much higher than the correction rate If the developers have to spend all their time analyzing a mountain of defects, they will not have time to fix anything The tester must support the developer in this task by filtering the information they provide to their stakeholders!
Solution? A tester does not provide unfiltered information to the stakeholders either way – filtering is always performed when deciding what defects to report, what information to include in the defects, and what information to include in test reports and similar When the tester filters the information to the stakeholders, the tester must be aware of this information overflow problem, and take actions accordingly But how do you know which information to omit? What can we do to solve this information overflow problem?
Basic Remedy A few basic bullets that must always be taken into consideration before any other solutions are discussed Reports must always be accurate and understandable Testers must understand what information their stakeholders need, and provide that information in a usable format Testers must understand the requirements and their priority But even with the basics in place, how should the tester handle the information overflow problem?
Information Overflow Remedy When a defect is found, but before it is submitted to the stakeholders, the tester should prioritize the defect using the same model as the Triage Team would If the defect has high priority it should always be reported If the defect has low priority it should only be reported if the tester believes there are available resources to fix the problem If the tester cannot prioritize the defect, it should be submitted, and the information gained if the defect is not fixed should be used for future prioritizations
What about the low priority defects? Information should not be forgotten – even low priority defects can be valuable in a greater context Even if a defect is not submitted, the information should still be saved somewhere – low priority defects could show patterns, or give important leads to other higher priority defects A separate database for low priority issues that are not submitted should be maintained – a database which most stakeholders will never look into - but which is of great value to testers and selected stakeholders
Solution Overview Provide the right information in the Defect Testers must perform these actions Prioritize Defect Will be fixed Will not be fixed Defect Database Information Database Testers use Developer Analysis information for future analysis
Conclusion Testers must take the information overflow problem into account when submitting defects and providing stakeholders with information A tester always filters information, but it must be done in a formal way to combat the information overflow problem No information should be lost, even though it is not reported to stakeholders