That's ludicrous, nobody wants to write test case.
-
Developers think QA team should be in charge of this. QA team says developers should write it by themselves. Test case has now become a political issue in my friend's company.
-
Developers think QA team should be in charge of this. QA team says developers should write it by themselves. Test case has now become a political issue in my friend's company.
Assuming that you mean something like a UAT test case, it is really easy to argue development shouldn't write them: The original spec always contains ambiguity or needs a interpretation - if this wasn't the case we wouldn't need developers. The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption. Getting the dev to write the test case has the effect of transferring the errors into the test case rather tha n picking them up, which is the point of the test. Also a dev has worked on the UI and thinks it is usable, he will write tests with ease, which will be followed as scripts. It is better for someone else to write them as they'll report stuff they find difficult to use.
Alberto Brandolini:
The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
-
Assuming that you mean something like a UAT test case, it is really easy to argue development shouldn't write them: The original spec always contains ambiguity or needs a interpretation - if this wasn't the case we wouldn't need developers. The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption. Getting the dev to write the test case has the effect of transferring the errors into the test case rather tha n picking them up, which is the point of the test. Also a dev has worked on the UI and thinks it is usable, he will write tests with ease, which will be followed as scripts. It is better for someone else to write them as they'll report stuff they find difficult to use.
Alberto Brandolini:
The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
Keith Barrow wrote:
The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption.
Call me maybe thick but... wouldn't it be better if the developers clarified any ambiguity with their clients before basing their work on an interpretation? I know I may live in cloud cuckoo land, but it's the way I tend to go about things - I do also meet people who do have a tendency to jump into coding when the spec is full of ambiguous requirements.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Keith Barrow wrote:
The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption.
Call me maybe thick but... wouldn't it be better if the developers clarified any ambiguity with their clients before basing their work on an interpretation? I know I may live in cloud cuckoo land, but it's the way I tend to go about things - I do also meet people who do have a tendency to jump into coding when the spec is full of ambiguous requirements.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Test cases should should come from both BA & Developers as business Analyst know what is the change require for and developers know the implication of their changes.
Mark the answer as accepted if that worked for you :). And for down-voters please specify the reason to improve the solution :).
-
Test cases should should come from both BA & Developers as business Analyst know what is the change require for and developers know the implication of their changes.
Mark the answer as accepted if that worked for you :). And for down-voters please specify the reason to improve the solution :).
In my case - I'm a business analyst, project manager, developer and mentor all rolled into one - with a client base of around 130 people - it's the way I like to work, not having to interpret an interpretation of a user request.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Developers think QA team should be in charge of this. QA team says developers should write it by themselves. Test case has now become a political issue in my friend's company.
Here's a nasty take on it, whoever specifies the requirement should also specify the acceptance criteria. The developer should prove the criteria is met and then QA confirm the proof. Pipe. Inserted. Smoke.
-
Developers think QA team should be in charge of this. QA team says developers should write it by themselves. Test case has now become a political issue in my friend's company.
Every requirement in the specification should have a section "How will we know this is done". That becomes your UAT test case(s) independent of coding.
-
Developers think QA team should be in charge of this. QA team says developers should write it by themselves. Test case has now become a political issue in my friend's company.
Writing test cases is boring. No one, including myself, wants to write them...but they must be done. There is great responsibility in writing good, effective test cases, and none of which is fun.
-
Keith Barrow wrote:
The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption.
Call me maybe thick but... wouldn't it be better if the developers clarified any ambiguity with their clients before basing their work on an interpretation? I know I may live in cloud cuckoo land, but it's the way I tend to go about things - I do also meet people who do have a tendency to jump into coding when the spec is full of ambiguous requirements.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
wouldn't it be better if the developers clarified any ambiguity with their clients before basing their work on an interpretation?
Where you realise there is ambiguity obviously, yes. Really the problem is that natural language is imprecise to which everyone brings their own set of assumptions about the ambiguity. I suppose "misunderstanding" is better than "assumption". I think this problem is intractable, otherwise natural language would rapidly become source-code directly. There are other reasons devs should not formally (obviously only a total fool would not test their own UI as they are developing it) test their own stuff in the end-user capacity (as oppposed to unit/integration etc) but those reasons are less concrete and harder to sell to managerial staff.e.g. a [decent] developer is attached to their work and therefore biased, also developers tends to start from the standpoint "is it working" rather than a better foe testing standpoint of "how do I break it?"
Alberto Brandolini:
The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
-
Shouldn't developers write unit test cases and rest to be done by QA, business analyst or whatever?
Unit tests are NOT "test cases". Writing those is the domain of QA, and they are developed based on requirements.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
