Building a test team ...

I told this story recently and was asked to blog about it, so here I am.

I have worked on several teams over the years, usually teams where I am starting testing departments from almost nothing, or revamping them from a place of failure to a place where they feel more valuable and are valued more. Frequently, I think back to the first major position I had out of college.

I started out during my senior year in college working as a part-time software tester at a bioinformatics company (software for genetics researchers). About 6 months in, I was given the opportunity to lead the testing effort (we had 2.5 testers) for a small turnkey project we had for a government agency. It was difficult, but I enjoyed it. When I graduated from college (about 11 months in), I was given the opportunity to hire 2 full-time testers and lead the QA team for the company.

My first 2 hires spent the first week or two in training (that I instructed) about the domain -- I taught them about bioinformatics and the algorithms that the software used (I did it because I loved it, but it was good for them to learn). There were maybe a dozen different genetic matching algorithms. At one point, my team was able to run the major genetics algorithms *by hand*, and knew *immediately* when some result set was incorrect.

Within about a year, I encouraged each of them to specialized in some aspect that interested them: the software itself, testing, the domain, etc. One of them enjoyed unit testing, so she did that. Another was interested in the back-end processing so he focused on that. Each of them also focused on specific types of algorithms.

We met regularly to teach each other what we were learning. Each "specialist" would give some sort of presentation to teach all of the other team members what we all needed to know to be able to effectively test. As new developers came on, they lacked the domain knowledge to understand *why* something was wrong. I was proud to see my test team able to understand the problem deeply and be able to explain it to the development team.

Before long (about a year), it became time to hire 2 more testers. Once the new hires came on, my existing team members helped to teach the new hires about the domain and the algorithms. The company had expanded the systems that it supported to 5 platforms for the client and 3 for the server. We maintained large whiteboards across the QA "hallway" to coordinate with each other on configuration management and testing efforts (in the days before I spoke words like "big visible charts").

At one point during this time, my software development lead conducted an experiment on us -- he purposely inserted 5 issues into a build and we had 2 days to knock away at it. We found 4 of those 5 issues in just 2 days.

In general, we struggled with test automation and never quite got it to work (though I became intimately familiar with WinRunner and TestDirector). We got offended when we were reprimanded for talking to each other too much (I valued that then, just as I do now). We communicated with each other via big whiteboards that let us know what everyone was doing at any given time and how it was progressing. We talked through test techniques with our dev leads, who were incredibly skilled people.

Looking back, at the time, I thought we were doing so many things wrong. In hindsight, however, we really were doing a *lot* of things right, and I am proud of that team.