[thelist] Page Testing

Luther, Ron Ron.Luther at hp.com
Fri Dec 8 12:26:33 CST 2006


Joel D Canfield asked for clarification of my blanket statement of
disbelief in 'user sign-offs'.


Hi Joel,


What's that about being careful what you ask for?  ;-)

Sorry.  Yes, you are right, clarification does seem warranted. 
Apologies in advance because this will most likely comes 
across as a bit of a rant.

My clients are 100% 'in-house', and that may be enough in 
and of itself to justify my comment.  (I feel it was 
relevant because the original poster was, I believe, 
discussing page testing _within_ their own company.)

I would certainly agree that in situations involving external 
clients you need the legal CYA of numerous sign-offs to stave 
off liability from litigation. However, even in that situation 
I think it ought to complement a good working relationship 
with the client.  IMO documentation is never a substitute for 
a good working relationship.

Back to the in-house scenario.  I've seen internal 'user 
sign-offs' used in two ways.  

(1) I *have* seen them used to augment and cement mutual 
understanding of project goals, scope of work, tentative 
timelines and budget estimates.  Really.  I have.  
Unfortunately, I haven't seen them used that way since 
the '80s!

(2) For the last decade or so the only way I have seen 
these internal 'user sign-offs' used is to club people 
over the head in internal company politics. {I also 
suspect that they may have been set as a default 
requirement for some enterprise project tracking 
software like TeamPlay, so some people have to have 
these sign-offs on their projects whether they make 
sense or not. [1]} 

YMMV.

So, for the time being anyway, I'm not a big believer in 
'user sign-offs'.  Maybe some nostalgia fad will hit and 
we will start using them properly again. Maybe that *is* 
a flying monkey ... <nevermind />.


Hope that's a little more clear,

RonL.


Two-fer!  And now for a separate rant on 'test scripts'!  ;-)

[There are supposed to be some software packages, like Mercury 
Interactive, that allow you to automate some level of testing.  
My understanding is that the price and the learning curve are 
both pretty steep. As an alternative there are folks who 
write out 'test scripts' in longhand and get their users 
to follow along like a cookbook.  The following is about 
that kind of 'test script'.]

I know some folks that like to script every dang keystroke 
and hover over their testers while they all hit the same 
key at the same time.  I don't really see the point.  I see 
that as load testing.  If anything it might be considered 
user training on the app ... but it ain't app testing as 
I understand it.

I prefer more free-flow test scripts.  I think they should be 
more action based. E.g. "Enter a sales order for a customer." 
"Now enter a second sales order for that same customer but this 
time crank up the quantity so that the order exceeds the 
customer's pre-approved credit limit." Leave the keystrokes and 
screen choices up to the testers.  I think that kind of 
approach does a better job of flushing out workflow and 
application issues and concerns.



[1] There _are_ also cases where user sign-offs do not make sense.  
E.g. I discover some records that need to be purged from my db. 
The effort will take more than 'x' hours so it must be registered 
as a project. Now the software won't allow _me_ to sign-off 
because I am managing the project. My dba can't sign-off because 
he is doing the work. Now what? ... Now I have to grab some poor 
schmoe and assign them as 'client' just so I can get their 
sign-off because the software requires it.  That is just *wrong*.  



More information about the thelist mailing list