I’ve read Karen Johnson’s blog about test script writers (catch it on testingreflections.com), and found it both understandable and sad at the same time.
Generally, I like it when someone has some passion about a given topic, even when I don’t agree with it. Everyone is entitled to have an opinion and some of them are pretty interesting.
But this one, well, it was oddly slanted and it kind of tickled at me. I stuck the whole thing in my blog fodder file and read it several times.
She was interviewing candidates for her team and went ballistic over a candidate that said he read specifications and wrote test scripts. I think what she really didn’t like was the “slow, steady” response. It seems likely she hires dynamic people who can think on their feet. I understood and agreed with her statements about having some passion about what you do. But her post inferred people who write scripts are the mental equivalent of doorknobs.
She used the comparison that she bought a camera after an interview to become a journalist. She lied during her interview and said she had a camera. If you really look at that comparison, she DIDN’T HAVE THE CAMERA to start with; she had to go get one.
Someone who has never worked in an environment that either does or does not require test cases doesn’t have a camera either. You have to be able to assess whether they have or will be able to use a camera (i.e. is able to think) and that’s a really hard job.
There’s really no such thing as a “test script writer”; some automaton that magically transforms specifications into test cases with no analysis. If you review someone’s test cases, you’ll see their test ideas in writing. If someone has no test cases or nothing you can look at, you’ll either have to probe to see how they think, or just assume that if they appear to be quick on their feet and talk a good story, they’re smart enough to be a good tester. Overall, gauging talent that way is a crap shoot. I know testers that develop test cases that I wouldn’t have on my team. I know agile testers that are just as bad. Is testing methodology really a good indicator of testing ability or intelligence?
A test case, or script, is nothing more than a test idea fleshed out with some instructions. As such, the analysis skills required to translate a requirement (whether written in a spec or brought up in a meeting) into a test idea(s) are pretty much the same. I think the core issue here is “are the test ideas any good”? The format is meaningless in comparison.
I feel a little sorry for the applicant that interviewed with her, whether they were qualified for the job or not. If the rest of her company uses test cases and her area doesn’t, the applicant was offering up what was viewed as successful in other areas of the company and would have no way of knowing Things Are Done Differently Here, unless she talked about how her group operates before they got started. If she did that and he didn’t adjust his delivery accordingly, then he probably WASN’T quick enough to impress her much. I’m not convinced that IQ or personality is linked to methodologies, however.
Having test personnel that understand the company and deliverables and who are “plug and play” is, in fact, a benefit for the company. Personnel here don’t get passed around, as we have a centralized QA organization, but we pretty much reassign staff as project needs dictate. I have a preference for dynamic people who are quick on their feet as well. We’ve got a mixed bag in terms of project methodologies here; some structured work and some agile, with most falling somewhere in the middle. So what I value most in my staff is flexibility. I feel the same way about interviewees.
Karen’s blog indicated that paying “script writers” peanuts and giving them no respect was justifiable. I don’t understand how any rational person could really believe that.
Then again, maybe I’m a doorknob.
Monday, February 23, 2009
Subscribe to:
Post Comments (Atom)

7 comments:
I don't know if I'd call myself a "script writer" per se, but my job title has "performance tools developer" in it... and I certainly write TONS of scripted tests.
I'm more of an "enabler" than a "tester" in most cases.
But IMHO, I actually add value.
I write an occasional script, so I guess I'm a "Test Script Writer". I think I exist.
Of course, I'm a "Test Script Reader", too.
Once in a while, I'm a "Test Script Executer", although more often I'm an "Unscripted Test Executer".
Am I a doorknob? If so, should I add it to my resume? Is there a good Certification Exam for doorknobs?
-joe
Joe, according to everything I've read, you're looking for ISTQB certification, although if you actually have to think or analyze (something) before writing a script, I don't think you'd qualify as a "doorknob". For now, I guess you're just going to have to be a Doorknob Wannabe.
Corey, I really can't imagine you as a mindless drone; the nature of the testing you "enable" makes you more of a Developer With An Attitude. My own tech team kicks ass too!
No, I certainly wouldn't want ISTQB Certification.
I susect I could continue to exist without it.
Good post back on Karen's blog. It appears to me that Karen has missed the value of context in all of this. I've worked for the same software house for about 3 years now and on some projects I've written no scripts, on others I've written masses of scripts. The reason being is that scripts were 'required' as proof of testing, they even had to be externally reviewed prior to testing - does that make me a rubbish tester? should I take a pay cut? No, of course not cos the following project was agile and I wrote no scripts.... Just because someone writes scripts doesn't make then a doorknob at all. If they have the potential to work exploratory, write automation scripts and manual scripts then surely this makes them a damn good tester. It makes them dynamic, flexible and capable of working in any environment possible.
Context is crucial. If my customer DEMANDS I write scripts and the only way we get the contract is to write scripts - then, you know what - I'm gonna write scripts. There's a time and a place for everything...
Keep up the cool blog. We need more balances view points out there.
>>>Keep up the cool blog. We need more balances view points out there.
Linda,
To have a balanced opinion on topics that you blog - please include the views that contradict or take a opposite stand on what you write.
In this case, Karen might be writing that post from a context that is different from yours. She might have forgot to call out her context explicitly. what is the problem with that?
It appears that most of your context might have been in those contexts where documenting test cases is a MUST and is percived as valuable by your stake holders.
There might be contexts where testers have freedom to document or skip the documentation of tests that they design and execute.
So there is no right approach for this. Through your previous posts, you have made your stand very clear on this - you value documenting test scripts. That does not me others take other approach need to be called as "oddly slanted"
I am more or less sure this comment will not be published ... yet making an attempt to see if you value a "differing" view point.
Let me see....
Shrini
First of all, Shrini, you don't have to double-dog dare me in order to get a comment posted. There's only one comment I haven't posted in the past year. You'd know that, by the way, if you had bothered to check it out.
Your assumptions - and they ARE assumptions - about what I do and do not support are just that. Have you ever bothered to ASK me what my personal preferences are? No. Your own assumptions lead you to read my posts in one way only, and because of that, your comprehension is limited. Is that how you customarily decide what to test? By making assumptions and asking no questions?
I value documentation in context; it depends on my client(s) and what needs to be accomplished. I'm not phobic about test cases, nor am I terrified about working with no test cases whatsoever. I think good work can be done either way. And here's where I differ from you and from many others, Shrini. I genuinely DO NOT CARE what the project methodology is at a given company. I believe a high-caliber testing professional can operate successfully in any type of environment.
What galls me, what sticks in my craw, and what makes me blog in support of structured processes are people who are allegedly contextual that feel it's their way or the highway. Whenever I see someone write something that is expressed in absolutes, it pisses me off. Most of the time, it's people dogging structured processes, hence I have blogs pointing out why that viewpoint is limiting.
I believe that making judgement calls in regards to someone's fitness or value as a tester based solely on whether or not they write test cases is profoundly misguided. Someone who writes no test cases can easily adapt to a situation where documentation is required, and someone who writes test cases can equally adapt to a situation where no documentation is required. It's the test ideas themselves that are important. The argument regarding structured/unstructured testing methodologies is, to me, nothing more than arguing about how and when to communicate those ideas.
I can, however, understand if Karen felt the applicant wasn't quick on their feet or in some other way didn't fit the type of personality profile she's found successful on her team. And I said so. The point of my blog was that personality, IQ, etc. are not necessary linked to what type of test artifacts you've delivered on past projects.
Now I will respond back to you in the same way you wrote to me, Shrini.
"I am more or less sure you won't comprehend this comment any more than you comprehend any of my blogs, but let me see...."
- Linda
Post a Comment