Year ago one of our Software Test Engineers was tasked with documenting our smoke* process. It should have been something simple like:
- Developer packages binaries for testing
- Developer places smoke request on web page
- Tester signs up for smoke on web page
- Tester runs appropriate tests
- Tester signs off on fix
- Developer checks in
Instead it turned into a ten page document. Needless to say, I took one glance at the document and dismissed it as worthless. As far as I know, no one ever followed the process as it was described in that document. We all had a simple process like the six steps I laid out above and we continued to follow it.
When tasked with creating a process for a given task, the tendency is to make the process complex. It's not always a conscious effort, but when you start taking into account every contingency, the flow chart gets big, the document gets long, and the process becomes complex. To make matters worse, when a problem happens that the process didn't prevent, another new layer of process is added on top. Without vigilance, all process becomes large and unwieldy.
The problem with a large, complex process is that it quickly becomes too big to keep in one's mind. When a process is hard to remember, it isn't followed. If it takes a flow chart to describe an everyday task, it is probably too big. It is far better to have a simple, but imperfect process to one that is complete. The simple process will be followed out faithfully. The complete one will at best be simplified by those carrying it out. Worse, it may be fully ignored. It is deceptive to think that a complex process will avoid trouble. More often than not, it will only provide the illusion of serenity.
I have discovered that process is necessary, but it must be simple. It is best to keep it small enough that it is easily remembered. The best way to do this is to document what is done, not what you want to be done. People have usually worked out a good solution. Document that. Don't try to cover all the contingencies. It will only hide the real work flow. Documented process should exist to bring new people up to speed quickly. It should be there to unify two disparate systems. It should not be there to solve problems. You hire smart people, let them do that. Expect them to think.
My final advice on this topic is do not task people with creating process. It is tempting to say to someone, "Go create a process for creating test collateral." Tasking someone with creating process is a surefire way to choke the system on too much process. The results won't be pretty. Nor will they be followed.
*Smoke testing is a process involving testing fixes before committing them to the mainline build. Its purpose is to catch bugs before they affect most users.
There's another good example in the book "Slack". In the chapter on process, DeMarco comments that we automate the easy parts and leave the hard parts alone.
ReplyDeleteApplying this to process, we end up with something that says how to do the easy part (You must create a branch before adding a test) but leaves the hard part alone (Create the test).