I was responding to a thread on "productivity in software - when the term is relevant" on test republic and posted following paragraph about quantification and metrics, which I thought would benefit larger audience ....
People (especially managers) when trying to make things that are not (easily, at least without changing the form of task or thing)quantifiable, quantifiable - end up in changing the core of the thing.... that is goal displacement. I once heard a manager asking us to change the way we do testing because the method we were using was not quantifiable (having more human elements etc). We then changed the approach to testing to meet the quantification needs of testing rather than original needs of "information" and "evaluation". Following this, the manager was happy, metrics were available, everything was quantifiable .. but testing suffered. When that happened, manager managed to shift the blame to something else (totally unrelated) and gotten away. He could do that and get away with it because metrics enabled him to do so ... metrics being numbers have no story or no descriptive form on their own. Given a metric, you can tell any story that you want to tell and manipulate the world.
Software Metrics are like gases or liquids, they do not have their shape or form, they take the shape of the container in which they are placed. Be careful about this when making or dealing with things in software that are "quantifiable" ...
Shrini
2 comments:
Very meaningful writing. And, the discussion which is going on in Test Republic for the mind igniting thought, 'When is the term "productivity" is appropriate to software testing profession....' -- is bringing up information's which are useful to all of us.
Recently, one person asked me, 'how can I measure the productivity in your testing?'
I asked that person, what is the meaning of productivity do you have. Since, I don't know what the productivity is, what you want to know from my testing. That person said how many bugs you have found so far and test cases you have written.
I said, I have given the information's for my team members, which helps in releasing a product whereby it can be used for the purpose with freedom and deserved value for using it.
That person asked, I want metrics of the bugs count and test cases passed and failed.
I said, the productivity of my team is in giving the needful information to the people, who are in need of it. And, we are doing it and learning how to improve the information which we give every time, when we give the information. I cannot tell the metrics of that information; instead I can show you the product which is being used with freedom across 24x7 -- productivity.
That is the productivity of my team and testing.
The words of Shrini are very near and it is the words of the daily life-- that is measuring of productivity using a metrics (but most of us would not try to understand whether it is value addable), which we should think and question ourselves what the Productivity means?
I never thought of metrics as a liquid until now.
You are correct, a metrics template is created in the beginning of a project but it evolves into different forms throughout the project lifecycle.
Great blog, thanks for sharing.
Jay
Follow Me On Twitter: @jayphilips
Post a Comment