V&V is not all a tester does
I associate Verification and validation with process of comparing documented requirements with code. However if we want to create software that users is willing to pay for (instead of simply protection from being sued for low quality software) then perhaps testers should do something more…. Let me tell you what I do and why
The gap between requirements and user needs
I believe everyone have seen tire swing joke about programming. When I tried to build a house for my family I learned that in reality different perceptions may be even more remote. When I started project my understanding of what I want was something like this. Only after working close with architect for several months my understanding of what I want shaped more into how it is illustrated in the joke mentioned above.
What happens if we only care to validate requirements
I was reading Brian Marick about business value and I realized why I has never completely accepted agile ideas.. although they accept that seeing the finished work made the business change its mindthough they don’t want to be accountable for the change. They want to charge business for any change they does. Do they dismiss the “non-agile” ways to minimize such costs such as pilots, models, prototypes – I don’t know. But I know why they think they don’t need testers – good testers do they best to minimize the need for changes and this work is seen not-our-business by agile developers.
The other role of tester: my vision
So beside V&V there is something else a good tester does. That is sometimes not valued by certain developers and even managers. So there are at least 4 (there are more in waterfall-like methodologies, but agile reduced it to minimum – to 4) different visions of product:
1) What customer really needs (a blur things)
2) What customer thinks (now) she needs (a bit gap with 1 that reduces with each step in waterfall)
3) What we (business analysts, product owner, whoever else on developers site) have managed to describe on a paper about what we think about what customer thinks about what he wants
4) How developers understood and implemented what we described about what we think what customer thinks about what she really needs
Ok there are 5 – actual code, but comparing it to 4 is the developer’s task. Their Unit tests does it perfectly.
Now if we have a dedicated tester he may compare 3 and 4 (to reduce risk of misinterpretation made by developer). However it is more essential to try find gaps with 2 and even 1. Good tester may try to use a “reverse-thinking”, try to understand what a customer really needs. Of course testers makes a lot of wrong guesses (that why developers and even manager don’t like them) but they should eventually help customer to understand for example that they really need the system to survive after year 2000...
The gap between requirements and user needs
I believe everyone have seen tire swing joke about programming. When I tried to build a house for my family I learned that in reality different perceptions may be even more remote. When I started project my understanding of what I want was something like this. Only after working close with architect for several months my understanding of what I want shaped more into how it is illustrated in the joke mentioned above.
What happens if we only care to validate requirements
I was reading Brian Marick about business value and I realized why I has never completely accepted agile ideas.. although they accept that seeing the finished work made the business change its mindthough they don’t want to be accountable for the change. They want to charge business for any change they does. Do they dismiss the “non-agile” ways to minimize such costs such as pilots, models, prototypes – I don’t know. But I know why they think they don’t need testers – good testers do they best to minimize the need for changes and this work is seen not-our-business by agile developers.
The other role of tester: my vision
So beside V&V there is something else a good tester does. That is sometimes not valued by certain developers and even managers. So there are at least 4 (there are more in waterfall-like methodologies, but agile reduced it to minimum – to 4) different visions of product:
1) What customer really needs (a blur things)
2) What customer thinks (now) she needs (a bit gap with 1 that reduces with each step in waterfall)
3) What we (business analysts, product owner, whoever else on developers site) have managed to describe on a paper about what we think about what customer thinks about what he wants
4) How developers understood and implemented what we described about what we think what customer thinks about what she really needs
Ok there are 5 – actual code, but comparing it to 4 is the developer’s task. Their Unit tests does it perfectly.
Now if we have a dedicated tester he may compare 3 and 4 (to reduce risk of misinterpretation made by developer). However it is more essential to try find gaps with 2 and even 1. Good tester may try to use a “reverse-thinking”, try to understand what a customer really needs. Of course testers makes a lot of wrong guesses (that why developers and even manager don’t like them) but they should eventually help customer to understand for example that they really need the system to survive after year 2000...
Add a Comment
-
Comment by kashif ali on June 20, 2009 at 5:34am -
Ainar,
i will definaltly consult the link you have given. :)
-
Comment by Ainars Galvans on June 18, 2009 at 11:19am -
You know how Microsoft made their money? I don't think it was because some testers were talking to any users. Bill Gates realized that people need something they don't yet know that they need it. And he gave it to them.
I'm a tester. I know my skills. I know that if I would participate meeting with a client I would be able to do nothing during that meeting. I need computer, application installed on it and a time to try realize what I want to ask or suggest the customer. But I know that I have to do it. This is not a communication issue I'm talking about in the blog. It is an attitude, or perhaps the mission issue.
Sorry, but I think that models (and their unambiguity) are great to fool ourselves into believing that we reduce the gap. IT may reduce the gap between 3 and 4, not 1 and 2 above. That was exactly my experience with house model (the paper designed by architect). We managed together to create what I referred to as my dream house. And now I live in a completely different house and am satisfied, completely satisfied.
And here http://www.softwaretestingclub.com/video/751045:Video:42 is another link about model based testing just for you :)
-
Comment by kashif ali on June 18, 2009 at 8:39am
-
Model based testing Links
http://www.goldpractices.com/practices/mbt/index.php
-
Comment by kashif ali on June 18, 2009 at 8:35am
-
Hi Ainars great post again :)
it is quite true that requirement engineering is quite intergral part of Software development, even we do Verification and validation against our RS (Requirement specification),change request etc, there is enough possibilty that we can miss understand some reqirements of the client.
Studies have shown that almost 60% of errors/bugs are due to un-cleared requirements because extracting requirementd is quite difficult job to do, requires great deal of expereince and focus.
In agile, we work along with clients, and client is quite important stakeholder as we all know sepcillialy in agile , so testers should be part of each communication with the client. so that can perform gap analysis along with the software activities.
you have mnetioned good points i would like to add one point here.
According to model based testing , we developed the model of the system by analyzing requirements. its model is just like flow chart , then for each branch testers derive the test cases, this model grows with tha passage of time because it is difficult to develop model at once. i think testers can "reverse think" by following this technique.
tester can get an idea while executing flows that some application flow can be differ from client expectations. you can read more about model based testing
Again Ainar Nice post, good discussion:)
Looking for your commenst
Find Us Elsewhere
Nice Things
Bloggers
© 2010 Created by Rosie Sherry
You need to be a member of Software Testing Club - An Online Software Testing Community to add comments!
Join Software Testing Club - An Online Software Testing Community