In last month’s article, we explored an innovative approach to project management – one in which teams could improve their chances of success by adopting 6 complementary “lateral thinking” styles throughout the development process.
The concept was first introduced by Edward de Bono in his 1985 landmark book, Six Thinking Hats. And in the 30 years since, this unique approach has broken out of its strictly “business” shell and gained favor with other disciplines, including in software testing and development.

This is the second in our 6-part homage to de Bono’s framework. The previous article provided an overview of the different Hats before diving into the first cognitive style – Managerial Blue.

Just to quickly recap, the Blue Hat represents the top-level thinking required before a project even begins. Typical questions one might ask include:

  • What is the goal?
  • Why are we here?
  • What are we testing?
  • Why are we testing this?

While wearing the Managerial Blue Hat, you become a navigator who charts the overall path. “X” marks the spot, and you now have a final destination in mind.

Today, we’ll look at the next Hat in our series – Informational White.

White Software Testing Defined

When wearing the White Hat, you become a census-taker who determines the facts as objectively as possible. More specifically, White Hat thinking requires that you assess:

  • What do we know already?
  • What do we need to find out?
  • How will we obtain these missing data?

Note that there are zero emotional judgments attached to this process. You adopt a strictly clinical approach to the project and determine what pieces of information are verifiable – and what pieces are based on assumptions. If and when gaps emerge, White Hat thinking allows you to identify avenues for retrieving the information you still need.

In short, you want to remove as many assumptions and theories from the table as possible. Other Hats in de Bono’s framework offer plenty of opportunities to explore and get creative. But the White Hat is about taking stock and making sure you begin your journey from a place of certainty.

This step is so critical that many projects begin with the White Hat over the Blue. And there may exist times when software testing calls for this reversal. But we feel that asking “why” is usually more important than asking “what.”

Let’s explore further.

White Hat Applications in Software Testing

Software testing often brings about a lot of emotions – especially as deadlines approach, personalities clash, and budgets become tighter.

White Hat thinking is neither the time nor place to indulge such distractions. Your main concern is to determine neutral facts like:

  • What is the budget (not what would you like the budget to be)?
  • What does the product currently do (not how can it perform better)?
  • Where does the product currently fail (not why does it fail)?

When you’re done with White Hat thinking, you should be able to print out a simple 1 or 2-page report that outlines the current state of development.

“This is where we are.”

But getting to this stage still requires some testing:

  • Focus on regression testing to identify what works and doesn’t work. And save exploratory testing for later on when you’re ready to figure out the why of whatever bugs you uncover.
  • Use automation to cycle through. It is not subject to manipulations, and can be repeated with no room for changes.
  • Use pre-determined scripts and schedules to verify what is known.
  • Use manual testing to re-run failed tests (it is a fact that they failed).
  • Validate fixed-defects to prove that they were indeed fixed and make it a known fact (or not). In Testuff test management, we have a feature designed for that exactly.
  • Work with Requirements coverage table until you have cleared all reported defects from it.

Most software testers feel right at home wearing the White Hat. Ours is a data-driven profession. And whether consciously or not, most of us automatically take stock of what we know – before jumping into any big project.

However, avoid the temptation of tinkering at this stage. New ideas and insights will begin forming in the back of your head (“If A is true, then B may be the cause”).

There will be plenty of time to test those assumptions in later stages. For now, just the facts – and nothing but the facts.

Why White Cognitive Thinking Matters

The best way to understand why White Hat thinking matters is to consider instances when this step is absent.

Thanks to Blue Hat thinking, your team understands the basic goals of the project. You all share a common roadmap. But because you haven’t gone through the fact-collection stage:

  • Half the team thinks that the budget is A – the other believes it to be B.
  • Half the team thinks that component X is working – the other half realizes that it still needs fixing.
  • Half the team is working to improve feature Y – the other half understands that this feature isn’t part of the beta release.

When you have competing assumptions within the same team, delays and frustrations are inevitable. White Hat thinking removes speculation from the testing process, so that everyone is on the exact same page.

It’s okay if White Hat thinking doesn’t come naturally. After 1 or 2 failed projects, it will. You’ll intuitively grasp the benefits of fact-collection. And you’ll begin to see the White Hat as a tool in and of itself. In many ways, it’s the most valuable tool in our arsenal.

Stay tuned.

In the next article, we’ll look at the 3rd lateral thinking framework in de Bono’s series – the Red Hat.