Opinion: Testers responsible for code changes
Don Rogers
become a developer (in the same shop). I am curious how common our shop's
practices are.
Currently, our developers can't write code without the tester telling them
exactly (to the nth degree) what to do. In fact, these developers actually
give testers pages of C++ code so that the tester can tell them what changes
they need to make. These "developers" actually blame testers for bugs that
are introduced into the code.
I personally (though maybe naive) believe that a tester should be able to
open a defect and not have to hear about it until the developer has debugged
it and determined what the problem is. Even then I feel that the tester
should only have to hear about it if the fix cannot be made without further
requirements.
I really feel that after the tester writes the defect, the next thing they
should hear about it is that the fix has been turned over by the developer.
That is how I operate, by the way. And I am appalled by this behavior. But
then again, maybe I am being naive.
So please: Let me know how common it is in other shops for testers to be
required to:
1. Write a User Interface Design Document because the developers "don't have
the knowledge"
2. Know more than the developer about the format and contents of data being
transmitted TO our application from other systems.
3. Know more than the developer about the format and contents of data being
transmitted BY our application to other systems.
4. Spend hours each week explaining and re-explaining simple requirements
(that are clearly documented – and that other testers can write test cases
from).
5. Tell developers what code needs to be removed/changed/added.
6. Be held responsible for bugs that are introduced by the developer.
David Owen
<DonER...@Hotmail.com> wrote:
>So please: Let me know how common it is in other shops for testers to be
>required to:
>
<list snipped>
sounds like the terms: tester and developer are the wrong way round in
your shop ?
If the tester is responsible for producing the "User interface spec"
then surely his role is that of analyst ?
I know in our shop the testers regularly complain about the quality of
the specs that they are deriving test cases from (or failing too!).
The attitude though [in our shop] is of the developer (who is
responsible for *his* code) attempts to right code with minimal bugs,
the tester is attempting to find as many bugs - herein lies the
challenge/motivation for both parties.
David Owen
email to: ow...@drowen.demon.co.uk
Vivekanand Sakaram
I've worked as a tester in several different companies (Apple, Symantec
and Fedility Investments being the most widely known)
I'd say that the industry standard is very different to your company
culture. I have never been asked to review a developers code and tell
them where to make changes, although there are times when it might have
been quicker to do so ;). Then again I've mainly worked in user and
integration level testing of finished systems, your situation may be
different.
From you email I get the impression that you are a bit frustrated with
the current situation. If you're looking for some advice give me a
shout.
To answer the specif questions
1. Write a User Interface Design Document because the developers "don't
have the knowledge"-
I've seen it happen. Mainly because the tester was the only one who knew
what the user wanted to see.
2. Know more than the developer about the format and contents of data
being transmitted TO our application from other systems. -
Quiet common. Testers have more exposure to the system as a whole than
the developer.
3. Know more than the developer about the format and contents of data
being transmitted BY our application to other systems. -
As above. Usually the tester has a good overall knowledge while the
developer has a more detailed knowledge of the data transmission
sections they have actually worked on.
4. Spend hours each week explaining and re-explaining simple
requirements (that are clearly documented – and that other testers can
write test cases from).-
Very common. It's a matter of focus often the developers don't
understand how their code will be used.
5. Tell developers what code needs to be removed/changed/added.
-Uncommon. At a system test level it's up to devlopers and development
managers to decide what code changes to make. A tester may be aware of
the underlying code but they don't usually look at the details of the
code.
6. Be held responsible for bugs that are introduced by the developer.
- Never. If you don't write the code you can't be blamed when it doesn't
work
Jimmy Murphy
Senior test analyst
Baltimore Technologies
Don Rogers wrote:
>
> I have only really worked in one shop since I started testing. I have since
> become a developer (in the same shop). I am curious how common our shop's
> practices are.
>
> Currently, our developers can't write code without the tester telling them
> exactly (to the nth degree) what to do. In fact, these developers actually
> give testers pages of C++ code so that the tester can tell them what changes
> they need to make. These "developers" actually blame testers for bugs that
> are introduced into the code.
> I personally (though maybe naive) believe that a tester should be able to
> open a defect and not have to hear about it until the developer has debugged
> it and determined what the problem is. Even then I feel that the tester
> should only have to hear about it if the fix cannot be made without further
> requirements.
>
> I really feel that after the tester writes the defect, the next thing they
> should hear about it is that the fix has been turned over by the developer.
> That is how I operate, by the way. And I am appalled by this behavior. But
> then again, maybe I am being naive.
>
> So please: Let me know how common it is in other shops for testers to be
> required to: