Posts in Software Testing
Making progress visible
Last week I finished reading Behind Closed Doors: Secrets of Great Management by Johanna Rothman and Esther Derby. The book is well written and is told in an interesting way. As a person who reads more management books then anyone really should (I'm working towards an MBA) I know what a well written management book looks like (there are too few of them out there).

The following is one of many examples of how I have already applied this book...



In the back of the book, there is a section titled Techniques for Practicing Great Management. In that section, I found a list of questions designed to help managers make the progress of any project contributor more visible. You might try asking questions like the following:


  • How will you know when you're done with that?

  • What steps will you take?

  • Which part will you work on first?

  • Can you provide a picture or a measurement of work to date?

  • Do you need to collaborate with anyone else on this?

  • How will you know you're making progress?

  • Who needs to be in the loop if you are unable to finish this on time or run into problems?



When I finished reading this list, I noticed that some of these questions were eerily familiar. In fact, my manager had just been asking me those questions last week. I thought about why he would be asking me those questions because I always report my progress.

After reflecting on the questions a bit more, I began to recognize that I had not been effectively communicating my progress. Without even being aware I was doing it, I had stopped. Not only have I not been communicating progress, I haven't even been telling my manager what I've been working on.

I see three reasons as to why this might be:

1. I don't yet really understand the scope of the work I'm doing. I know what I want to do, and I know how I want to do it, but I'm still trying to work out the steps to get from point A to point B. Because I don't truly understand the work yet (and I hope to in a couple of days), I can't think of a way to explain my tasks to my manager yet. When he asks what I've been doing and what I plan to do, he's looking for a level of precision that I just don't have yet.

He asks, "Which part will you work on first?"

I answer, "I don't really know what the parts are yet. I'm still trying to figure that out."

He asks, "How will you know when you're done with it?"

I answer, "I don't know yet. I'm still not sure what 'done' means. It's a complex set of tests and I still don't know what they will look like."

He asks, "Do you need to collaborate with anyone else on this?"

I answer, "Of course, I just don't know who yet."

As you can see, I'm very vague.

2. My manager is new (to me). The old manager just rolled off the project and this manager is new and has not yet been 'tested in battle.' We don't yet have a history and a working relationship. It's hard to develop a working relationship with a new manager. We don't know to communicate yet and we both have different expectations for what the person in our roles should be doing.

Therefore, much of what he asks me smacks of micromanagement. When in truth, it's more likely that he truly doesn't know what I'm doing and he's just trying to learn the only way he knows how - asking questions. Nothing wrong with that...

3. Finally, I'm moving off the project in the near future (or at least my status with the project is rapidly changing). That means that I don't really want to take the time to build the relationship like I normally would. It's hard work getting to know how to work with someone new and I just don't want to put in that effort.

Now that I recognize my behavior, I need to fix it.

Starting Monday I plan to take the time to invest in the new relationship. It's not his fault he's new, I'm just being silly (to put it nicely). I also plan to provide more visibility to my tasks and progress.

While I'm still struggling to understand the work, I think I can do this by including him in my brainstorming and by talking with him more about the nature of the testing that will be taking place. Perhaps he can help add structure to my thinking. I'm hopeful that the process of explaining it to someone else will help me better understand the problem.
Touring Heuristic
I seem to have a winner with my test reporting heuristic. I've used it several times now. It helps me envision and explain my test reporting. I think I will need something similar for application touring.

Here is my attempt:

FCC CUTS VIDS



The mnemonic stands for the following:

Feature tour
Complexity tour
Claims tour

Configuration tour
User tour
Testability tour
Scenario tour

Variability tour
Interopeability tour
Data tour
Structure tour


  • Feature tour: Move through the application and get familiar with all the controls and features you come across.

  • Complexity tour: Find the five most complex things about the application.

  • Claims tour: Find all the information in the product that tells you what the product does.

  • Configuration tour: Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.

  • User tour: Imagine five users for the product and the information they would want from the product or the major features they would be interested in.

  • Testability tour: Find all the features you can use as testability features and/or identify tools you have available that you can use to help in your testing.

  • Scenario tour: Imagine five realistic scenarios for how the users identified in the user tour would use this product.

  • Variability tour: Look for things you can change in the application - and then you try to change them.

  • Interopeability tour: What does this application interact with?

  • Data tour: Identify the major data elements of the application.

  • Structure tour: Find everything you can about what comprises the physical product (code, interfaces, hardware, files, etc...).