Everything we do and know can or even should be able to be improved. At least that's how I look at things. If this is not the case, it would mean a complete "standstill". As a testing professional I know that nothing is perfect. And even if it appeared to be, the world around this perfect object still moves forward. So in the end even this object should improve and adapt. It’s like I said before (some posts back):
"In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change”
Charles Darwin
So if everything should be adaptable to change, the Testing process should be as well. As testers we know a lot of our own issues, but most of the time we blame the environment for it. "The developers don't takes us serious", "We don't get any budget to test what we want to test", "We're always at the end of the chain, so it's not our fault there are still some bugs in production" etc. And some of it is valid and some of it might be questioned. Is it because people don't know what testing is? Or is it because we (as testers) aren't transparent enough? Or could it even be because of the fact that we don't even know how mature our own process is?
This last question is not that strange to ask. The testing profession is not even a profession in it's true nature. Compared to (for example) lawyer, doctor or bartender, we are just beginning to find out ourselves what software testing is. But before I dwindle to far away from the subject, I wanted to talk about improving our test process. Every projects starts with the best intentions and maybe even a complete test process in place, but during a project things always change. How adaptable are we then with our standardized test process?
Using methods like TPI NEXT, we can make a snapshot of our current situation and work our way toward our (pre) set goal(s). For example, if we want to be cost effective, more effort should be put into getting the test environment more mature instead of getting our meetings formalized. But methods should only be used to support practice and not be the leading factor of your process. Let it become a tool for yourself to get an overview, insight and something to "hit" management with in order to get resources/time/money to improve and/or change.
Being at the top level of maturity does not guarantee that "all goes well". It does give some basis of a proper process at that given time. Keep in mind that every project changes and that at a mature level, so should your test process!
To state it more boldly;
"We don't want to be CMMI level 5!"
Posts
Hi, Reinder.
ReplyDeleteWith respect to "For example, if we want to be cost effective, more effort should be put into getting the test environment more mature instead of getting our meetings formalized," I have a question for you. Are you sure? Maybe you're right, but maybe "formalizing" meetings, in the sense of time-boxing them, could save time and create a sense of purpose to them.
The problem that "process improvement" models run into all the time is that the model doesn't know anything about my business. The people who developed the model don't know anything about my problems, and they don't know what's working well. The model is always based on assumptions of what will be valued, assumptions that may not be warranted. It's a solution that looks for a problem.
In addition, I would avoid the word "maturity". http://www.developsense.com/blog/2009/10/maturity-models-have-it-backwards/
---Michael B.
@Michael Thats why I gave it as an example :) I agree that the models don't have all the answers to the business problems, so you should only use them as a basis for the evanualtion and build on that.
ReplyDeleteMaturity might give a false sense of security for the business which is why I stated the last scentence; we don't want to be CCMI 5. It has no use for an organisation that needs (and wants) to be felxible and able to adapt to changes...
Hi Reinder,
ReplyDeleteI agree with you that processes do not guarantee for making the software bug free.
But on the other hand it provides support system, which helps to remove issues from the product.
As every project is different in itself, so we need to align our processes to get maximum benefit of processes.
The conclusion is " Processes are to help get best possible quality in existing constraints, These processes should not become burdon"
so we need to finetune processes now and then.
Regards,
Yatender Sharma