Here's another entry for the "30 Days of Testing" Testability challenge. Let's keep this ball rolling.
Find out if your application has an operational manual or runbook? How can you test this?
Put simply, yes, it does. More to the point, I've been one of a few people that has actually updated this documentation with new feature information as well as release notes. To that end, I absolutely have familiarity with what goes in it, how to put content in there and how to look for details about how our software works and what options are available to me.
Having said that, our software has a fairly high level of complexity and thus our documentation needs to reflect that. While I will not say that I look at every single help page, I do look at it from a macro level as I'm the one who builds those help files.
What I do try to do is look at the top level details and traverse them the way I imagine that an everyday user of our product might. What could this tell me?
First and foremost, it tells me what we are telling our customers as to how we should be doing something. That's an important avenue to look at and consider while I am testing because that's what we intend our customers to be focusing on doing to complete their workflows. How often do I do this and determine that I have a different or better way of performing a task? Surprisingly often, as I have come to see. Of course, part of that is the fact that I know the administrator interface and many times using that is *way* more effective than performing the in-app methods. However, since our customers do not have access to that level of interaction (well, most don't) I need to remind myself to either go with the published methods or make a case that, maybe, our backdoor methods probably need to be considered as a way to let our customers do things, too.
To borrow from Red and Overly Sarcastic Productions... "So... yeah!"
Find out if your application has an operational manual or runbook? How can you test this?
Put simply, yes, it does. More to the point, I've been one of a few people that has actually updated this documentation with new feature information as well as release notes. To that end, I absolutely have familiarity with what goes in it, how to put content in there and how to look for details about how our software works and what options are available to me.
Having said that, our software has a fairly high level of complexity and thus our documentation needs to reflect that. While I will not say that I look at every single help page, I do look at it from a macro level as I'm the one who builds those help files.
What I do try to do is look at the top level details and traverse them the way I imagine that an everyday user of our product might. What could this tell me?
First and foremost, it tells me what we are telling our customers as to how we should be doing something. That's an important avenue to look at and consider while I am testing because that's what we intend our customers to be focusing on doing to complete their workflows. How often do I do this and determine that I have a different or better way of performing a task? Surprisingly often, as I have come to see. Of course, part of that is the fact that I know the administrator interface and many times using that is *way* more effective than performing the in-app methods. However, since our customers do not have access to that level of interaction (well, most don't) I need to remind myself to either go with the published methods or make a case that, maybe, our backdoor methods probably need to be considered as a way to let our customers do things, too.
To borrow from Red and Overly Sarcastic Productions... "So... yeah!"
No comments:
Post a Comment