e-Talk Radio: Hendrickson, Elisabeth, 15 February 2001

Rebroadcast 29 March 2001

time that you have invested in using that tool. And those scripts are not going to be transferrable to another tool.

CAROL: Right. And that...that's something I guess that you have lost. When you go through the step process, I would like for our audience to go through the kind of the steps that you have laid out in this article. And it was actually in STQE magazine. We've got two STQE'ers back to back in this series, which is kind of neat. In January/February 1999, in the STQE magazine, your article was called, "Evaluating Tools," and you laid out actually a very, very good five-step process. And I think it would be valuable for our audience to kind of know what is the critical pieces of each one. Step 1 you said, "Define the initial requirement." What do you mean by that? What do people have to do? Does that mean you can't go shopping for a tool first?

ELISABETH: Well, before you go shopping, you really want to understand what problem you're hoping the tool is going to help you solve. So, for example, if...if before I even start looking at tools, I don't even know whether I want to do GUI-based through the user interface...I don't know whether I want to do GUI-based testing or whether I am looking for something that is going to help me do command line base testing. If I don't even know at that level what kind of tool I'm looking for, then I am going to come up with a very, very huge list of possible vendors. And there is no way I can investigate all of those options. So, before I even start thinking about who I am going to get this tool from, I want to know what the tool is going to do for me. What capabilities does the tool need to have, who is going to be using that tool, do I need it to be extremely fault-tolerant, because that...that could restrict the...the kinds of tools I can use. Do I need it to work in a particular operating system? So, if all of our development is being done on MacIntosh, anybody who does not support MacIntosh in their tool set, there is no reason to even consider their tool, because they're not going to be able to help me solve my problem.

CAROL: Even if they've got something that looks and sounds really nice.

ELISABETH: Unless you're going to change your development environment, that's probably not going to help you.

CAROL: So, you're really talking about even before you look at any brochures, sitting down and defining really what you need. And in your article you talk about the tool audience. The fact that just because you are selecting the tool, you may not be the person that is using it. And there may be things that the person who is using it needs that you may not even know about.

ELISABETH: That's right. Or you may only be one of the people who are using it. So, a typical scenario that I see in software companies is that the folks who have been charged with choosing the test automation tool are the ones who will creating the automated test...and so that's great because they're really important stakeholders in the process. However, the folks who are going to be executing those tests ultimately are not given the opportunity to look at the tool.

CAROL: Interesting. And...and we're not just talking about, you know, test automation tools. This could be for any software tool, and I guess

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.