Comments on: More Responses to the Agile Testing Questions http://www.developsense.com/blog/2006/05/more-responses-to-agile-testing/ DevelopSense Blog Tue, 07 Feb 2012 17:56:32 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Eric Jacobson http://www.developsense.com/blog/2006/05/more-responses-to-agile-testing/comment-page-1/#comment-8451 Eric Jacobson Wed, 19 Oct 2011 13:53:43 +0000 http://developsense.com/wordpress/?p=22#comment-8451 You are suggesting it may not make sense for testers to give time-based estimates to their teams, but what about relative estimates? Let's say a Rapid Software Tester is asked to participate in Planning Poker (relative-based story estimation) on an Agile Scrum team. I've always considered this a golden opportunity. Are you suggesting said tester may want to refuse to participate in the Planning Poker? <em> Michael replies: This question was interesting enough to me that I did <a href="http://www.developsense.com/blog/2011/10/should-testers-play-planning-poker/" rel="nofollow">a blog post on it</a>. Thanks!</em> You are suggesting it may not make sense for testers to give time-based estimates to their teams, but what about relative estimates? Let’s say a Rapid Software Tester is asked to participate in Planning Poker (relative-based story estimation) on an Agile Scrum team. I’ve always considered this a golden opportunity. Are you suggesting said tester may want to refuse to participate in the Planning Poker?

Michael replies: This question was interesting enough to me that I did a blog post on it. Thanks!

]]> By: Samuel http://www.developsense.com/blog/2006/05/more-responses-to-agile-testing/comment-page-1/#comment-6086 Samuel Wed, 02 Feb 2011 11:17:09 +0000 http://developsense.com/wordpress/?p=22#comment-6086 Michael, I have a different view from what you have stated above. <em>Michael replies: That sort of thing has been known to happen. :)</em> When I ask you how long you would take to drive from home to office, you may say about an hour. You would not say I do not know. Though it may be possible that there are days where there are traffic jams, days when there is no trffic at all, there may be a break down in the car etc. It is possible that you do not reach your home exactly in an hour every time, it may be 1.1 hrs, 1.2 hrs or 0.8 hrs. But we approximate it to one hour. <em>So far, so good.</em> This is what the customer is looking for, is you testing going to take 2 weeks or 2 months (not considering the development effort) assuming that there would be two rounds of testing. This is the assumption that we provide. <em>And I am going to suggest that is <strong>not</strong> your assumption to provide. There are services that have a set completion point. Were you the customer and I a taxi driver, it would be perfectly legitimate for you to ask me, "How long will it take for me to get home?" and it would be perfectly legitimate for me to respond "About an hour." If you asked for something more specific, it would be legitimate for me to answer that my answer was pretty reliably accurate to plus-or-minus fifteen minutes, based on the traffic, the time of day, weather, road conditions, and so forth. No problem there. There's a starting point, and a finite destination. One can describe from the outset most of what it means to deliver the completed service to the customer in this extremely specific and binary way: either you're at home, or you're not. But <strong>testing is not that kind of service.</strong> Testing, real testing, is an open-ended task. It's not an activity with a specific, predictable destination. It's a process of exploration, discovery, investigation, and learning. This doesn't have a set completion point, and it's not subject to piecework. We can't say that when we've completed these N test cases, we'll have tested the product (unless we've decided that we want to express testing solely in terms of <a href="http://http://www.developsense.com/blog/category/testing-vs-checking/?submit=Search" rel="nofollow">checking</a>). We cannot schedule the discovery of important problems; we can't decide in advance how much time we're going to spend investigating them; and we cannot predict when we'll be satisfied with our investigation. Since the programmers haven't provided us with a list of bugs, we can't schedule when we'll find them, the programmers can't schedule when they'll fix them, and we can't schedule when we'll re-test them. Nor can we decide in advance how many of the problems won't be fixed and will need additional work from the programmers. What we <strong>can</strong> do, of course, is provide this promise: "We will continue to investigate the product, Dear Client, until you ask us to stop. And at every step along the way, we will to report what we've discovered so far, what we think you'd like us to look into that we have not yet looked into, and into risks that we can anticipate. And at every step of the way, we're willing—nay, obliged—to make sure that you're satisified with what we've looked into and what we plan to look into, and if there's any problem with that, then we'll work with you to make sure that we're providing you with the kind of information you seek."</em> When we provide a estimate, the customer gets an idea as to how long it would take. <em>How long it would take to do <strong>what</strong>, <strong>specifically</strong>?</em> If the test team does not provide the testing estimate and this responsibility is given to the development team, the decision is taken away from us, and I would not like that as I would be forced to test in the timelines that the development team provides. <em>The decision as to how long you have to test is never yours in the first place, so it can't be taken away from you. I'd recommend that you read <a href="http://www.developsense.com/blog/2010/10/project-estimation-and-black-swans-part-5-test-estimation/" rel="nofollow">this post</a>.</em> Thanks Sam <em>Thank you for writing.</em> Michael, I have a different view from what you have stated above.

Michael replies: That sort of thing has been known to happen. :)

When I ask you how long you would take to drive from home to office, you may say about an hour. You would not say I do not know. Though it may be possible that there are days where there are traffic jams, days when there is no trffic at all, there may be a break down in the car etc.
It is possible that you do not reach your home exactly in an hour every time, it may be 1.1 hrs, 1.2 hrs or 0.8 hrs. But we approximate it to one hour.

So far, so good.

This is what the customer is looking for, is you testing going to take 2 weeks or 2 months (not considering the development effort) assuming that there would be two rounds of testing. This is the assumption that we provide.

And I am going to suggest that is not your assumption to provide.

There are services that have a set completion point. Were you the customer and I a taxi driver, it would be perfectly legitimate for you to ask me, “How long will it take for me to get home?” and it would be perfectly legitimate for me to respond “About an hour.” If you asked for something more specific, it would be legitimate for me to answer that my answer was pretty reliably accurate to plus-or-minus fifteen minutes, based on the traffic, the time of day, weather, road conditions, and so forth. No problem there. There’s a starting point, and a finite destination. One can describe from the outset most of what it means to deliver the completed service to the customer in this extremely specific and binary way: either you’re at home, or you’re not. But testing is not that kind of service.

Testing, real testing, is an open-ended task. It’s not an activity with a specific, predictable destination. It’s a process of exploration, discovery, investigation, and learning. This doesn’t have a set completion point, and it’s not subject to piecework. We can’t say that when we’ve completed these N test cases, we’ll have tested the product (unless we’ve decided that we want to express testing solely in terms of checking). We cannot schedule the discovery of important problems; we can’t decide in advance how much time we’re going to spend investigating them; and we cannot predict when we’ll be satisfied with our investigation. Since the programmers haven’t provided us with a list of bugs, we can’t schedule when we’ll find them, the programmers can’t schedule when they’ll fix them, and we can’t schedule when we’ll re-test them. Nor can we decide in advance how many of the problems won’t be fixed and will need additional work from the programmers.

What we can do, of course, is provide this promise: “We will continue to investigate the product, Dear Client, until you ask us to stop. And at every step along the way, we will to report what we’ve discovered so far, what we think you’d like us to look into that we have not yet looked into, and into risks that we can anticipate. And at every step of the way, we’re willing—nay, obliged—to make sure that you’re satisified with what we’ve looked into and what we plan to look into, and if there’s any problem with that, then we’ll work with you to make sure that we’re providing you with the kind of information you seek.”

When we provide a estimate, the customer gets an idea as to how long it would take.

How long it would take to do what, specifically?

If the test team does not provide the testing estimate and this responsibility is given to the development team, the decision is taken away from us, and I would not like that as I would be forced to test in the timelines that the development team provides.

The decision as to how long you have to test is never yours in the first place, so it can’t be taken away from you. I’d recommend that you read this post.

Thanks
Sam

Thank you for writing.

]]> By: Samuel http://www.developsense.com/blog/2006/05/more-responses-to-agile-testing/comment-page-1/#comment-5588 Samuel Tue, 04 Jan 2011 10:47:12 +0000 http://developsense.com/wordpress/?p=22#comment-5588 The customers are going to ask for the test effort. In our organization the development team and the test teams give separate estimates. So what do we do here? <em>Michael replies: I would consider this (probably more a question for those who set policy than for you, alas): when you are asked how long it's going to take you to drive somewhere, do you give separate estimates for steering and looking where you're going? When you call a taxi company as a customer, do you ask for a breakdown of steering time and looking-where-you're-going time, or do you see them as activities that should be continuous, in parallel, from start to destination? As a tester, I'm going to start testing as soon as someone gives me something to test, and I'm going to stop testing when someone asks me to, or when the product ships. You will perhaps find some helpful suggestions by following <a href="http://www.developsense.com/blog/category/estimation/" rel="nofollow">this link</a>.</em> The customers are going to ask for the test effort. In our organization the development team and the test teams give separate estimates. So what do we do here?

Michael replies: I would consider this (probably more a question for those who set policy than for you, alas): when you are asked how long it’s going to take you to drive somewhere, do you give separate estimates for steering and looking where you’re going? When you call a taxi company as a customer, do you ask for a breakdown of steering time and looking-where-you’re-going time, or do you see them as activities that should be continuous, in parallel, from start to destination?

As a tester, I’m going to start testing as soon as someone gives me something to test, and I’m going to stop testing when someone asks me to, or when the product ships. You will perhaps find some helpful suggestions by following this link.

]]>