Posted by Ben Simo
A few months ago, I enlisted my 11 year old son to help me with some work around the house. After a short while, he was doing something other than what I had asked him to do.
I told him, "You're not helping me."
"But I am helping you.", he replied.
"No you're not."
"I'm helping you. I'm helping you.", he shot back. He was frustrated. He really thought he was helping me; and I was putting down his work. I was frustrated too. From my view, his helping was creating more work for me. I did not feel helped.
Then it hit me. I've heard this argument before -- from software testers.
I've seen testers, and test managers, attempt to justify their work by telling team members and stakeholders "I'm helping you. I'm helping you." We QA and tester people develop metrics and reports to help us demonstrate how helpful we are. We talk about our quality assurance and testing processes. We talk about all the test cases we develop and execute. We like to show off our test automation that spits out impressive color-coded results.
However, we still encounter unhappy team members and stakeholders. We develop adversarial relationships with developers. We have to explain ourselves to project leads that question the value of our testing. We hear people tell us we're not helping and we keep saying "I'm helping you. I'm helping you."
Maybe, just like my son, we're not giving our stakeholders what they need. Maybe we aren't really helping. So instead of shooting back the "I'm helping you." line, we can stop and listen. Find out what our stakeholders want from us. Listen and ask clarifying questions to better understand how we can help.
I'm not advocating that we just give in and do whatever we're asked without defending our positions. However, we can be willing to adjust our positions to better serve our stakeholders. (Joining an overly optimistic rush to release poor quality software usually doesn't serve them.) If there is disagreement, work to resolve it. Sometimes we may need to educate others on our areas of expertise. Yet we testers also need to respect others' roles and expertise. Listen and learn.
So, the next time you feel like screaming "I'm helping you. I'm helping you.", try to better understand how you can help before turning up your defenses.
Serve your stakeholders.
7 Comments:
January 06, 2009-
Michael M. Butler wrote:
-
-
January 06, 2009
-
Anonymous wrote:
-
-
January 06, 2009
-
Ben Simo wrote:
-
-
January 06, 2009
-
Anonymous wrote:
-
-
January 07, 2009
-
Lisa wrote:
-
-
January 22, 2009
-
Anonymous wrote:
-
-
February 15, 2009
-
Ajay Balamurugadas wrote:
-
-
Jerry Weinberg has had some things to say about [not] inflicting help, too.
Reminders are helpful. Thanks for this one. :)
It was bit surprising to read this. Because, I came back from extended defect review meeting and saw the writing which illustrated the instance that took place few minutes back, which I witnessed.
Most of the defects, showed the flaws in the requirement. And, I was telling this are defects and this will reduce the product's value and efficiency.
But, the team said 'where is the requirement for this defect?' I kept justifying what happens if this does not get fixed and left as it is. But none were able to understand 'Requirements itself can have defects' and I kept saying, the testing is helping to identify them now i.e., uncovered things in the Requirements that is giving birth the defects.
I was not convinced, with the team response and I extended the meeting and finally, they agreed to review the Requirement. But, I was helping them to given full complete value to the user of my product.
Should defect always have the requirement written? But, those defects helps in correcting the requirements, isn't true?. We should help each other to know what we can help each other and for the user who makes of our product.
Thanks for giving such a good thought.
Ravisuriya
Ravisuriya,
We're not always going to be able to directly link defects to requirements documents. Sometimes requirements documents are bad. Sometimes requirements and priorities change as a project progresses. I once heard James Bach ask something like "How do you know if your requirements are ambiguous?" His answer: "It contains words." Language is ambiguous. Every writer and reader of a specification document brings their own knowledge and experience into interpreting the document. Smart reasonable people will have differing interpretations of things the author thought were clearly stated.
Requirements documents are not the requirements. Let me say that again: there is a difference between the real requirements and your requirements documents. Sometimes we need to learn to write better requirements documents. Other times we just can't put all the requirements into writing before coding starts.
Requirements documents are models of the real requirements. They are less complex than the real requirements. As George Box wrote, “All models are wrong, but some are useful.” When a team understands that their requirements documents may be useful but are wrong, it makes it easier to discuss defects in context of the real requirements.
Due to our inability to produce perfect requirements, we must often make a good case for bugs that we believe threaten value. This requires learning how to communicate with the team responsible for deciding what does and does not get fixed, and the priority of those things deemed worth fixing. Find out what matters to that team and explain the risks in relation to those things that matter to the team -- which may differ from what matters to you.
I once worked with a project manager that said "revenue is king and liability is queen". Although we didn't all realize it at the time, this was priceless information. It told us that we needed to talk about bugs and enhancement requests in light of their impact on revenue and liability. These things may not matter in all contexts. Find out what matters to the stakeholders you serve.
Testers aren't always going to get their way. This is fine if we have made a good case and the team disagrees with our assessment. Sometimes priorities and requirements change over time. A bug we can live with today may become a monster tomorrow. Today's top priority may no longer matter tomorrow. Learn to be flexible and support what the team needs.
Ben
Ben,
Today, I have got the lessons which, I will never forget. I am very happy with the lessons I have learned today.
>> I once heard James Bach ask something like "How do you know if your requirements are ambiguous?" His answer: "It contains words." Language is ambiguous. Every writer and reader of a specification document brings their own knowledge and experience into interpreting the document. Smart reasonable people will have differing interpretations of things the author thought were clearly stated.
So, true! Ambiguity lies in the language we use and interpretation we make.
>> Requirements documents are not the requirements. Let me say that again: there is a difference between the real requirements and your requirements documents.
This one, took me again back the our discussions we had in the defect review meeting. The requirement of the product which will be used by customer was not
not stated. But the contexts and scenarios, which I used and explored the system brought defects. And, the real requirements was not met. The words, "Other times we just can't put all the requirements into writing before coding starts." tells this.
>> Requirements documents are models of the real requirements. They are less complex than the real requirements. As George Box wrote, “All models are wrong, but some are useful.” When a team understands that their requirements documents may be useful but are wrong, it makes it easier to discuss defects in context of the real requirements.
I was witnessing this today, when I gave my team the contexts of how it might happen and causes.
>> Find out what matters to that team and explain the risks in relation to those things that matter to the team -- which may differ from what matters to you.
Here, I have questions.
1) The defects we observe, which might be due to the
i) missing requirement or
ii) by not understanding the requirement and coding
iii) or by testing and observing defects with various contexts and scenarios from the given build.
All this bring value to the product and team right?
2) If that (defects) is not considered as, that does not matter much, is not that me being a tester and keeping quiet when something causes my employer and my product to lower its value?
3) When people agree that what matters to you also matters to the team, but they ask for showing me that requirement that gave you the defects (I also agree with your words --"Other times we just can't put all the requirements into writing before coding starts."). Is not the time to think and question to ask ourselves what you said i.e., "Requirements documents are not the requirements. Let me say that again: there is a difference between the real requirements and your requirements documents. Sometimes we need to learn to write better requirements documents."? By doing so we are giving the value to the product and the user, Am I right?
4) How can I distinguish prominently, that it matters to me more, but not to the user who buys it for her/his purpose and same with me but not for the team? Since, using of application by us will change, as we keep learning it. That thought came to my mind, when I was observing the defects i.e., "This is a defect. But, how can I know how the other user may feel for this?".
I requested few people to see this and then listened to what they expressed, looking at it. Most of them agreed, it as a needy one; but they also said the priority might be high for this now -- this brings me your words again i.e., " This requires learning how to communicate with the team responsible for deciding what does and does not get fixed, and the priority of those things deemed worth fixing." and "Sometimes priorities and requirements change over time. A bug we can live with today may become a monster tomorrow. Today's top priority may no longer matter tomorrow. Learn to be flexible and support what the team needs.".
>> I once worked with a project manager that said "revenue is king and liability is queen". Although we didn't all realize it at the time, this was priceless information. It told us that we needed to talk about bugs and enhancement requests in light of their impact on revenue and liability. These things may not matter in all contexts. Find out what matters to the stakeholders you serve.
>> Today's top priority may no longer matter tomorrow. Learn to be flexible and support what the team needs.
After reading this, I realized that, I should have been flexible, when they said me "can we continue tomorrow and write the minutes of meeting for this hour discussion". But, I felt it was high priority to my team, which helps me to come with information again for them, tomorrow. And, requested them can we finish it up today.
This beautiful lessons from you, will be with me forever in my testing practice. Thanks for sharing your experiences. It made me to know my mistakes.
Ravisuriya
A nice example of an "agile" mind-set (whether or not you're on an agile team) vs. a "Quality Police" mindset.
>Serve your stakeholders
This thought is more than useful. It contributes to the survival of one's role in the project. Further, serving the stakeholders is the primary purpose of a professional or a company. We should not accept the stakeholders’ requirements at face value but analyze them to really understand them and identify any value-addition from our individual and collective expertise. Whether we can develop the stakeholders requirements further or not, the stakeholders probably know (or can come up with) much more about what they want than we know or we think we know. As you mentioned, listening to the stakeholders is very important.
Sometimes, we put up defenses simply because we do not want to look bad in the eyes of other people. If we do not become defensive when told about the problems, the stakeholders (for example, the customer) would probably assume that it was just a communication problem and move on. When we do become defensive and/ or do not listen (well), the stakeholders would probably wonder about what the real problem is (is it a skill issue or an attitude issue or is this the way they habitually work or is there something I don't really know about them). In my opinion, the latter situation is worse.
A customer (or any stakeholder) involves us to further their goals. It becomes important that our actions be aligned to their goals, so that we may give the push in the direction in which they want to go. We should not become a drag force to the customer's progress.
Hi Ben Simo,
Nice article.
Nice discussion in the comments section too.
To be frank, I learnt a lot from the comments section than from the main article.
The main article "I'm helping you. I'm helping you" highlighted the importance of 'OPV: Other People's Views'. (http://edwarddebono.com/PassageDetail.php?passage_id=393&)
>> You must put yourself in the shoes of these other people to think and feel as they do.
In one of the workshops of RST by Mr. Pradeep Soundararajan, I noted: There is no point in carrying out a process if it does not help fulfill the mission.
>> Learn to be flexible and support what the team needs.
After some discussions in Test Republic(www.testrepublic.com), my perspective of 'Tester is the king' changed to 'Tester is also a member of the team whose goal is to meet the mission of the project'.
Thanks for such a nice article.
Regards,
Ajay Balamurugadas
Post a Comment