Implementing Unit Testing – Goals

In this series, I’m going to discuss the strategy of how to roll out a unit testing implementation in an organization. As we all know, most unit testing initiatives start by developers, and if they are lucky, it gets picked up by their team, and maybe, in a viral fashion, go on to other teams.

This is all very dependent on how well the process goes, how people respond, and more importantly, how much management gets behind it.

But when it does happen, it is still fallible. So how can we support the process, in such a way that teams adopt it, and continue doing it?

That’s where this series starts. We’ll go through the different aspects of implementing the process. And we start with the end in mind.

GOOOOOOOAAAAAALLLLLLL!

Ok, maybe not that kind.

We want to know what to aim for, so we can adjust accordingly. As with any new process, the chances that everything goes according to plan is quite low, so keeping in mind what we want to achieve  is important.

• Sustainable, continuous effort of unit testing.

Obviously, that’s the major one. We want writing tests become an integral part of development. And it’s not just about writing – we want to include the unit testing strategy as part of development. The sustainable part means that it’s not just part of writing software, it also doesn’t require extra nagging.

It’s just part of the job.

• Tests are effective.

Yeah, we kind of miss that sometimes. Good, effective tests don’t just write themselves. Unfortunately, the tests we write first are pretty crappy, and those live the longest. We want that after testing becomes a way of life, we write effective tests, and get rid of the bad ones.

• Quick on-boarding of new people on the team

Remember, the goal is after the implementation plan, so we want this goal to be attainable after the initial roll-out. When new people join the team, without knowledge of basic testing skills, and particular team knowledge, we want them to get on-board with less hassle as possible. This doesn’t just happen by itself, and we’ll need to invest time and resources to make that happen.

• Easy on-boarding for a new team or group

If there are only a handful of developers, that’s not a priority. But if we want our 500 team organization moving towards developing tests, that’s an issue we should address. Note, that here the focus is on “easy”, not “quick”. We cannot expedite a new process implementation, it just takes time. We do want to be prepared, with examples, coaches, etc., to support a new team starting out the unit testing way.

That’s a nice set of worthy goals. Of course, you can add yours if they are as worthy.

Next time we’ll discuss how we know we’re there and what leading indicators we need to track.