going to take a bit of paradigm shift, especially for those listeners who are in companies where the testers have not been involved up front. They're always given something at the back end. I have always wondered how can you create tests for something that you do not even know how it is supposed to run, or you do not know what the requirements are?
Johanna: Well right, and the interesting thing there, is that every product has requirements. So, the key is how do you discover them. I wrote an article with Brian Lawrence a couple years ago called "Testing In The Dark," I think that is the name of it. It was published in Software Testing and Quality Engineering. It is on StickyMinds and it is on my Web site. It is in a bunch of places. One of the things that Brian and I suggested is that you take at least four or five hours or a day or two and ask people what the requirements are. Who are we developing this product for? Who are we developing this product--so that they can't use the system, they use disfavored users. Who do we not necessarily care about? We are happy they are using the system, but we are not designing the product for them. And then what attributes does the product have? How fast is fast? How reliable is reliable? Is there any way to describe the attributes of the project, I should say the product? What makes the product sellable to the maximum number of users? What makes it sellable to the minimal number of users? What makes it completely unsellable? Is there anything that we left out, we wouldn't have a product? So, we go through that stuff and then talk about the functionality. So that even if you don't have a built product yet, you don't have an executable of some sort, you can talk about what the requirements are. And it turns out that, I at least find that the user attribute function technique of eliciting requirements along with context-free questions is a fun technique to use. And developers respond very well to that, as do project managers. People say, "Oh, we are designing this thing for the kinds of people who...." And you get this real feeling of we are in this together, and we are trying to solve this particular problem.
Once you have any software that is built at all, you can do a whole lot of exploratory testing. James Bach has done a lot of work in the area of exploratory testing. He has published a bunch of articles that I find fascinating. But a lot of us testers got to testing because we were curious, because we were skeptical, because we had this, especially, the intellectual curiosity if I push on this thing, what is going to happen. You can use that curiosity in your exploratory testing. So, you can say, I'll do a little testing for awhile, I will explore this product for an hour or two and see what areas do I think would be right for finding defects. So between looking for requirements by talking to people, whether or not you actually have anything written down, and then starting to do some exploratory testing even if you did not get a chance to look at the requirements and the things that did get thrown over the wall. Then you at least have a chance of figuring out how the product works.
Now, the later you get brought in, of course, on the project the less
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
