My friend Srini Kulkarni - Software Testing Generalist, Systems thinker, Skeptic (on twitter @shrinik) during tweeting asked me why I do not yet sharing my thoughts through my blog and asked me to create the one. Now I have the one Srini and I named it as www.testexclusive.blogspot.com. I also promise that I will share my ideas. Here we start. That too from the point that I and Srini were discussing.
"Now put together these two things "quality" and "requirements" - what we get?" Shrini asked me.
My answer was - "Gap between them represents defects. Fulfillment results in acceptance"
Since we had space restrictions we could not go further in our tweeting too far. Here I continue.
Gap always exists and also, in practice, acceptance also takes place may be with certain conditions which need to be addressed within a client specified time. And life goes on! However I am not very much concerned with this "business drama" but want to show some way to address them.
As a step forward, here are some billion dollar questions-
"Why there are always gaps between what was agreed upon (requirements) and what is delivered (product)?" and "Why we need to live with these defects and their impacts?"
My answer has two folds-
------------------------------
1.It is because of the fact that requirements engineering is the least matured phase in software engineering and thus requirements specification that emerges out of it is not concrete. We use such requirements as the basis for development and testing. As such both development and also, testing will not be good. Good output always requires good input. Thus what we require as starting point is quality requirements, means, requirements that are clear, complete, unambiguous, verifiable, and traceable.
In summary, we need to have quality requirements and also, we need to measure clarity, completeness, unambiguity, verifiability, and traceability of requirements so as to define their quality. But How?? I will answer these in near future.
------------------------------
2. Definition of quality can not be generic. Meaning of quality is always specific to project and product. In other terms quality is always relative. Meaning of quality is highly diversified since stake holders and their requirements & expectations are different and many a times conflicting. Thus we need to arrive at definition of quality specific to that product and project before we start our project. But, again, How?? I will provide insights on it as well.
----------------------------
Now I look forward to your thoughts and points ..
"Now put together these two things "quality" and "requirements" - what we get?" Shrini asked me.
My answer was - "Gap between them represents defects. Fulfillment results in acceptance"
Since we had space restrictions we could not go further in our tweeting too far. Here I continue.
Gap always exists and also, in practice, acceptance also takes place may be with certain conditions which need to be addressed within a client specified time. And life goes on! However I am not very much concerned with this "business drama" but want to show some way to address them.
As a step forward, here are some billion dollar questions-
"Why there are always gaps between what was agreed upon (requirements) and what is delivered (product)?" and "Why we need to live with these defects and their impacts?"
My answer has two folds-
------------------------------
1.It is because of the fact that requirements engineering is the least matured phase in software engineering and thus requirements specification that emerges out of it is not concrete. We use such requirements as the basis for development and testing. As such both development and also, testing will not be good. Good output always requires good input. Thus what we require as starting point is quality requirements, means, requirements that are clear, complete, unambiguous, verifiable, and traceable.
In summary, we need to have quality requirements and also, we need to measure clarity, completeness, unambiguity, verifiability, and traceability of requirements so as to define their quality. But How?? I will answer these in near future.
------------------------------
2. Definition of quality can not be generic. Meaning of quality is always specific to project and product. In other terms quality is always relative. Meaning of quality is highly diversified since stake holders and their requirements & expectations are different and many a times conflicting. Thus we need to arrive at definition of quality specific to that product and project before we start our project. But, again, How?? I will provide insights on it as well.
----------------------------
Now I look forward to your thoughts and points ..
Hi Sir,
ReplyDelete"requirements engineering is the least matured phase in software engineering"
Very right thinking.I agreed,
Warm welcome to Bloggers world. *Thumbs up*
Hi Arun,
ReplyDeleteCongrats on the new blog.
Regarding your question, according to me quality is always relative and in some form in the human mind. Not every requirement can be stated due to which the gap will always exist from human to human, unless we have robots defining the requirements....I enjoyed the movie A.I.
Cheers!
Ramesh, It was not my question but a question which was put across by Srini. Quality is always relative since perceptions are personal and reality will infered differently by individuals.Locke in his 1690 in his "Essay Concerning Human Understanding" gave one of the fullest accounts of what are known as "representational models" of perception. I also request you to read my another post in this blog on Primary Quality and Secondary Quality.
ReplyDeleteHi Arun,
ReplyDeleteWelcome to Blogosphere. I am glad that I was somehow the cause for you launching this blog. Hope we will have many fruitful discussions on this platform.
Interesting to see you quote Locke (as opposed to Deming or Crossby) Do write about Locke, Kant, Hume Kuhn, Popper and others- how to see testing in these people's thinking.
Shrini