Verification and Validation is not only about tools, methods and processes. Crucial is also people and how they think.

The "Six Thinking Hats" is a thinking and problem solving tool developed by Edward de Bono [1]. Julian Harty at Google has adapted the hats to testing and presents the "Six Testing Hats" [2]. Julian has successfully applied this both in reviews, for checklists and in creating acceptance tests. They can be a good way to structure the thinking involved in V&V.

In general there is a lack of research and results on how the thinking, personality and psychology of testers, affect the testing. However, there is a growing community of people who want to acknowledge and investigate this mental side of software development more [3].

How is your V&V thinking doing today?

[1] http://en.wikipedia.org/wiki/Six_Thinking_Hats
[2] http://newsweaver.ie/qualtech/e_article000666359.cfm?x=b11,0,w
[3] http://www.cs.st-andrews.ac.uk/~jr/ppig08/program.html

---
SWELL is a National Innovation Driver for Software V&V funded by Vinnova and a number of Swedish universities and companies.
http://www.swell.se

Reviews and inspections are ways to find problems and increase quality of software and development artefacts. In fact, they are among the most effective methods known. Many practitioners use them. However, many do not, do them partly (without preparation) or do not use them continuously. With shorter release cycles these methods are often avoided altogether.

IBM Haifa labs introduced selective, homeworkless reviews three years ago at different IBM departments. Instead of developers spending 20-30% of their time doing inspections, they now have one hour booked weekly where a part of the code is selected for a focused review. Participants need not prepare but use checklists and other techniques to guide the review. The advantages are:

* Less time spent in review, only critical code or documents are reviewed
* No preparation needed, also cuts the time
* Efficient, finds 2-3 defects per person-hour, like formal inspections
* Normal review advantages like increased developer awareness => better programs with fewer bugs in future

So not much to loose and much to gain. Maybe you can adopt (more) lightweight review methods in your development team?

Links:
http://www.haifa.ibm.com/info/20071015_bugs.html
http://portal.acm.org/citation.cfm?id=1381305.1382104&coll=GUIDE&dl=GUIDE
http://en.wikipedia.org/wiki/Software_inspection

---
SWELL is a National Innovation Driver for Software V&V funded by Vinnova and a number of Swedish universities and companies.
http://www.swell.se