Supportive and Directive test documentation.
Submitted by Ainars Galvans on Wed, 11/03/2009 - 16:17.
general software testing
So there was (unfortunately) the exploratory testing good scripted testing bad conversation which I don’t want to continue. But I learned a few more reasons for scripted testing during the conversation: lack of tester’s commitment or competence. I’ll explore them in this blog and provide link to a space where I’ve stored some test case and other test documentation samples. I think rather than talking what is good and what is wrong we need to share examples.
Lack of commitment or competence
So this is the only reasonable reasons for scripted testing I’ve seen so far. Maybe there are more, but I’m not aware of.
However I’ve seen lack of commitment. I’ve seen it a lot. Mostly in too large and too long running projects. Everyone is bored, tired and see their everyday effort is eat up by the big project. So they don’t want to do the job the best they can. They only want to do it to survive until the next project which they hope will get them relief... Unfortunately so.
I’ve see lack of competence. Lack of testing competence is only part of a story. But don’t you forget about business domain competence. If I would need to test professional software for quantum physics, emulating aerodynamics or forecasting weather I would probably want a competent people to provide me with detailed test data and detailed validation algorithms. Yet all my experience is in domains that could be learned and I do prefer to learn the domain. And I do prefer my test team learn it as well.
Why should I care about commitment and competence?
Because according to situational leadership theory if a person has low commitment and low competence this person want to be directed. On the other hand if person has high competence, high commitment but you apply the same leadership style, you risk to be “despised for treating her like an idiot”.
Besides, according to the same source “we tend to have a preferred style”. So some people will love to write directive test cases. Others will prefer to write supportive ones, or just as Jonathan says it depends on personality if a tester would prefer descriptive or prescriptive test documentation. And there is nothing wrong about it, is there?
Tools supporting all types
By the way Jonathan seems to agree with me that most of existing test case management systems support the directive style test cases, while Jonathan is working in a project that creates a different tool that will support note keeping during test execution.
However I believe all we need is a rich text editor. That’s why I keep my tests documented in either Lotus Notes or wiki (confluence) – depending on what defect DB I have to integrate with. For example WIKI integrates well with JIRA. You could see quite a few examples of test documentation I’ve created and seen so far here, here and here.
Lack of commitment or competence
So this is the only reasonable reasons for scripted testing I’ve seen so far. Maybe there are more, but I’m not aware of.
However I’ve seen lack of commitment. I’ve seen it a lot. Mostly in too large and too long running projects. Everyone is bored, tired and see their everyday effort is eat up by the big project. So they don’t want to do the job the best they can. They only want to do it to survive until the next project which they hope will get them relief... Unfortunately so.
I’ve see lack of competence. Lack of testing competence is only part of a story. But don’t you forget about business domain competence. If I would need to test professional software for quantum physics, emulating aerodynamics or forecasting weather I would probably want a competent people to provide me with detailed test data and detailed validation algorithms. Yet all my experience is in domains that could be learned and I do prefer to learn the domain. And I do prefer my test team learn it as well.
Why should I care about commitment and competence?
Because according to situational leadership theory if a person has low commitment and low competence this person want to be directed. On the other hand if person has high competence, high commitment but you apply the same leadership style, you risk to be “despised for treating her like an idiot”.
Besides, according to the same source “we tend to have a preferred style”. So some people will love to write directive test cases. Others will prefer to write supportive ones, or just as Jonathan says it depends on personality if a tester would prefer descriptive or prescriptive test documentation. And there is nothing wrong about it, is there?
Tools supporting all types
By the way Jonathan seems to agree with me that most of existing test case management systems support the directive style test cases, while Jonathan is working in a project that creates a different tool that will support note keeping during test execution.
However I believe all we need is a rich text editor. That’s why I keep my tests documented in either Lotus Notes or wiki (confluence) – depending on what defect DB I have to integrate with. For example WIKI integrates well with JIRA. You could see quite a few examples of test documentation I’ve created and seen so far here, here and here.