Extreme Testing

I'm sure many to most of you are familiar with the principles of extreme programming. It can be quickly characterized by writing unit tests before coding and pair programming, but you can read more about it from this webpage.

I was thinking on the way home today about possibly modifying the rules of engagement into something called Extreme Testing. It would focus more on the relationship of the two people in the pair. In particular, one of the two would be a QA engineer. They would work closely together in the planning and designing phase - not much would change there. During the coding phase, the two would spend half their time together in a modified pair programming mode; most likely the main developer would do most of the coding, and the QA person would be there making recommendations and understanding what's going on. The other half of the time would be spent on their own: the developer doing his thing, and the QA person developing test plans, documenting the design, and creating process flows and timing analyses. Then in the end there is a big celebration with much rejoicing.

Why would one think of such a scheme? What is the possible value of this to you? A more effective method of knowledge transfer. Very loosely, here is how the software development process works today: the developer designs the component and hands you a design doc. That developer then builds his component, and hands you (the QA person) a finished product to test. Meanwhile, you must learn the intricacies of this component on your own, for the most part. You have a design document, and checked it code to sift through to understand the inner magic.

Being in QA, understanding the component better than the author is your quest. You must know it so well that you can break it with your left pinky. However, the process of transferring that understanding and knowledge is somewhat broken. Here is the current process: developer's head --> design document --> QA's head. Stuff is lost inbetween, I assure you. Developers stereotypically dislike documenting their component, making the knowledge transfer process more difficult. Seriously, I love a well-written design doc. It's like crack-cocaine for me. I would mainline a well-written design doc if I could only fit it on that little spoon.

So what is the solution? Well how about some extreme testing? Working side by side with the developer while he's working, and documenting the component and processes involved are a better way in my opinion of guaranteeing that the knowledge is tranferred more effectively.