QA Day

I recently posted why I think that to excel in QA and in Programming are mutually exclusive. Today I'd like to introduce you to a tool I find very useful for a software project's evolution, even if it may seem to contradict my previous claims (it doesn't contradict, really, it just seems to)...

On QA Day all programmers become QA engineers for one day. Typically, the QA team/department leader is responsible to divide the work between her temporary "employees". She's the actual boss for the day, and all programmers (including team leaders) must follow her orders. With large teams, some of the QA engineers move between the programmers to help them out with things they don't know, the rest participate in testing with the programmers. A primary requirement is that a programmer will test the parts of the application she hasn't written. I know that the previous statement was in bold, but I want to emphasize it again: putting a programmer to test a feature she has written would be a complete waste of time and miss the whole point of QA Day.

Which brings us to the inevitable question - what's the point? Why would you waste the programmers' valuable time doing stuff I claim myself they cannot be really good at (assuming you have really good programmers)?

1. By putting a lot of efforts in QA for a short period of time, you can often produce a rather good overview of the real fitness of your application. When done at the right timing, QA Day is an invaluable tool to find out where you stand and how you are going to meet your deadlines. Do it too early, and you will have large parts of your release uncovered. Do it too late, and you might find yourself with much more bugs than time allows to handle. Do it on time, and you'll know where you stand and have the time to act accordingly - in one day!!!
2. All programmers know the features they work on perfectly (hopefully). They are usually also well acquainted with some other portions of the application. We all have, however, "black zones" - parts of the applications we don't know at all (even at a user level). By forcing programmers to test their "black zones" you gain twice:
1. The programmers get to know the whole application to a much better degree, which will open their mind and let them see the "whole picture". This in itself could be enough a reason to do a QA Day once in a while.
2. Since they are not familiar with the features they are testing, they are a pretty good simulation of a "dumb user". In most cases you will see that programmers testing something in their "black zones" tend to behave like the most stupid of users. I don't know why it is, but it's so - I tend to ask the most stupid of questions in such situations, and so does every programmer I know. This level of "innocence" exists with QA engineers the first time they work on a feature. However, it evaporates extremely fast, leaving you with no way to really see how a new user would react. The programmer is a pretty good tabula rasa for this.
3. For weeks/months/years your application is being tested by the same persons over and over again. QA Day is an excellent way to refresh that - programmers will find errors in the test procedures, missing parts, propose improvements, etc. Good programmers are lazy people. As such, they will always try to find ways to work less. The idea is to leverage this characteristic to improve the test procedures.
4. Programmers tend to underestimate how hard it is to do QA. After one QA Day, the most bragging programmer will start to see things otherwise. It is also an invaluable way of improving communication between QA engineers and programmers and yields to better cooperation in the future.

There are, of course, several issues you must consider prior the QA Day to ensure its success:

1. Organization - people should know in advance when the QA Day is, all test procedures must be ready and assigned beforehand, etc. A thorough explanation of why we're doing it and what it's good for is a must.
2. Timing, as I mentioned above.
3. Short day - try to organize it such that people would finish their work relatively early. This has two reasons:
1. It's nice to finish early, and all other things being equal - people will remember it favorably.
2. There are always unexpected problems, which can cause serious glitches in time.
4. Choose the QA engineers responsible to assist the "testers" wisely - they should know the application thoroughly, explain things simply and fast, etc. They must constantly move among the people and make sure everybody can do his job and nobody is stuck with some stupid configuration problem.
5. Use a simple bug-report mechanism. You don't want to waste the whole day only because the programmers don't know how to report a bug.
6. The Achilles Heel of QA Day is that it might be confronted with antagonism from both sides (QA and Programming). Deal with it up-front by explaining its importance and turning it into a fun day. A nice add-on is to make it a tournament - the programmer who found the most bugs is the winner.

I've had the opportunity to work in a company that had QA Days at some point before each important release. It's one of the best organizations I've ever worked for. The relationship between testers and programmers was amazing. So was the level of knowledge of the whole system by everyone.

I truly believe it's an excellent tool for improving the overal performance of the development effort.