What is process improvement, and why should you care? Assuming you are a software tester, you’ll end up caring a lot. Especially when you get stuck on a job where there is no process and no improvement on the horizon! Ha ha, I can laugh now, but I’ve had that job too. Not for long – but I had it.
Here’s some purely anecdotal evidence for you, gleaned from my own experience. Most software developers think “process improvement” are dirty words and they dread being told that their shop is about to start going by this model or that process. Testers, on the other hand, tend to be much more open to the ideas of process improvement. Why is that?
I think it’s easy to figure out. Testers and other downstream folks like technical writers and even people who do implementations, customer service, and maintenance really feel the worst pain caused by a lack of process further upstream where the development actually takes place. That doesn’t mean that testers are going to thrive when forced to use big, heavy models with lots of documentation requirements. Remember, testers write a lot of documentation, and sometimes process can be as much of a drain on them as it is on developers.
The best process is one that solves a problem. For example: your requirements are unclear, which causes a problem for the developers (they aren’t sure exactly what to code) and the testers (they aren’t sure how to test what does get coded). Fuzzy requirements are causing problems. The solution is to elicit and document better requirements, and the best way to do that is to have a consistent requirements-gathering process that everyone is familiar with.
Here’s the key point, I think, on process improvement. Process models won’t tell you WHAT your requirements-gathering process should be, only that you need one. That leaves a lot of flexibility! Perfect! So in a large organization that’s developing some giant aerospace program, the process can look like: a team of people gathers requirements using a template, and they are vetted through another team, using certain organizational standards. Then they all get recorded and double-checked in a big tool, then perhaps modeled in some way, and so forth. On the other hand, a small team developing a lean web application have a process that looks like: one person always interviews the customer and gets the requirements. That person makes sure that any requirements given include certain essential information that’s needed for effective use (the requirements have their own requirements, if you will). If there’s any ambiguity, the requirements person goes back to the customer for clarification. Then the requirements get documented (perhaps in a spreadsheet) and reviewed with the team members regularly to make sure everyone understands them. Both processes have the same goal: clear, usable requirements. But they couldn’t be more different in scale and practice.
The whole point is having a process in the first place, instead of doing it differently for every project, or every customer, or every phase, or even every requirement. You can easily see where that lack of process will result in chaos, and that’s not fun for anyone.