When you think about your company, your project, and what information you need to report, it can be helpful to think about how you'll get that information. When you're thinking about what tools you'll need to help you understand where you're testing is, try asking yourself these questions:

• How much testing do we plan to do and how much of that have we done?


• What potential tests are remaining and in which areas?


• What is our current test creation velocity and what has it been for the duration of the project? How does that break out across the testing area or test case priority?


• What is our current test execution velocity and what has it been for the duration of the project? How does that break out across the testing area or test case priority?


• How much of our testing has been focused on basic functionality (basic requirements, major functions, simple data) rather than common cases (users, scenarios, basic data, state, and error coverage) rather than stress tests (strong data, state, error coverage, load, and constrained environments)?


• How much of our testing has been focused on capability rather than other types of quality criteria (performance, security, scalability, testability, maintainability, and so on)?


• How many of the requirements have we covered and how much of the code have we covered?


• If applicable, what platforms and configurations have we covered?


• How many issues have we found, what severity are they, where have we found them, and how did we find them?

Here are some quick tips to keep in mind when debriefing an exploratory test session:

• The more important the setup and configuration of your software is to your testing, the more you should describe it.


• The areas of the system that are less frequented and/or are the newest require additional details for clarity.


• Talk about how you felt about your testing and the software as you describe the steps you took.


• Avoid "info dumps." Keep those in your session notes, and focus your face-to-face debrief time on patterns, feelings, and overall results.


• Avoid saying the same thing over and over again as you debrief similar tests, or even across several different debriefs. When the notes and data speak for themselves, go beyond the obvious.

When you're reporting on test status (verbally or written), be sure you establish a relationship between your testing and your mission. The following questions can sometimes help with that:

• Was I successful?


• Am I finished?


• What obstacles do I have?

Big visible charts have gained a lot of currency with Agile projects for good reason. They help keep the team focused on their goals, and they provide important information that can be understood by just about anyone at a glance.

When testing, an incredibly powerful communication tool is the low-tech testing dashboard. If you put it in a location that has a lot of traffic, you'll have far fewer repeated questions about testing progress and quality issues.

I'm a big fan of the "complaints go up" principle. It's best explained by Tom Hanks in Saving Private Ryan. Watch from 4:00 to 5:20 for details. (Depending on where you work, you may not want to watch that at work.)