Home > Archive > Software Testing > September 2006 > Programmer (or A Techinical person) in a Tester ...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Programmer (or A Techinical person) in a Tester ...
|
|
| Shrinik 2006-09-17, 7:04 pm |
| I often heard the statements like "we would like hire a tester having
good coding skills", "developers respect only technical testers", "how
can you test effectively a VOIP based software if you don't have the
technical skills in that areas" and these "I am black box tester and do
not do white box or unit Testing" , "I am tester and certified in SQL
server 2000 database programmer/.Net development", "I am developer and
I know testing"....
Now my questions or thoughts that keep me engaged all the time...
1. When some says "technical skills" in a tester - what do they exactly
mean? When can testers, testing computer software - be totally non
technical (as say a Poet or Politician or Police officer - considering
that these are non technical jobs ...)
2. Should testers be programmers? Then how about converting developers
by teaching them testing (if they are willing to take up that)
3. Is this notion of testers need to be good programmers or some one
having good coding skills - a strategy by development or so called
Technical community to force every around them to be programmers?
4. How does a skilled Tester counter such notions and demonstrate that
critical skills required for Testing are much broader and go beyond
being simply being "technical or having coding skills"
Please note that I am in total agreement with the statement - knowledge
of programming and knowing the technology that you are testing *really
helps*. I would just stop there. A skilled tester is a good learner and
understands the skills that need to be acquired in ordered to be
effective in Testing.
In my view a skilled tester is a "generalist". Can I say - "Jack of all
trades and the Master of Testing"?
Shrini
| |
| James Bond 007 2006-09-17, 7:04 pm |
|
"Shrinik" <Shrinik@gmail.com> wrote in message =
news:1158509284.484023.289130@b28g2000cwb.googlegroups.com...
>I often heard the statements like "we would like hire a tester having
> good coding skills", "developers respect only technical testers", "how
> can you test effectively a VOIP based software if you don't have the
> technical skills in that areas" and these "I am black box tester and =
do
> not do white box or unit Testing" , "I am tester and certified in SQL
> server 2000 database programmer/.Net development", "I am developer and
> I know testing"....
>=20
> Now my questions or thoughts that keep me engaged all the time...
>=20
> 1. When some says "technical skills" in a tester - what do they =
exactly
> mean? When can testers, testing computer software - be totally non
> technical (as say a Poet or Politician or Police officer - considering
> that these are non technical jobs ...)
> 2. Should testers be programmers? Then how about converting developers
> by teaching them testing (if they are willing to take up that)
> 3. Is this notion of testers need to be good programmers or some one
> having good coding skills - a strategy by development or so called
> Technical community to force every around them to be programmers?
> 4. How does a skilled Tester counter such notions and demonstrate that
> critical skills required for Testing are much broader and go beyond
> being simply being "technical or having coding skills"
>=20
> Please note that I am in total agreement with the statement - =
knowledge
> of programming and knowing the technology that you are testing *really
> helps*. I would just stop there. A skilled tester is a good learner =
and
> understands the skills that need to be acquired in ordered to be
> effective in Testing.
>=20
> In my view a skilled tester is a "generalist". Can I say - "Jack of =
all
> trades and the Master of Testing"?
>=20
> Shrini
To me, technical skills for testers include that they understand the =
hardware, the software architecture, the operating system, and other =
aspects of the environment the software they are testing resides in. =
Many times, errors arise not from the software being tested but from =
these other sources. Knowing how to analyze errors, recreate them and =
find the real cause of an anomaly are valuable skills that I'd like my =
testers to have.
At the risk of repeating myself, it is beneficial for testers to have =
programming experience so that they can a) write their own test tools =
and scripts, and b) understand what the programmers are doing and how =
they will be debugging the bugs that are being found. I think it's fine =
to train developers to become testers if they are interested in the art =
of testing and are looking for a change in roles.
I do NOT think it is necessary for testers to have previous experience =
programming in the same language that the code they are testing in is =
written. For the most part, a programming language is a programming =
language is a programming language. Of course, the testers should =
understand object oriented design and development - classes, methods, =
inheritance, persistence, etc.
James Bond 007
| |
| erkan77@gmail.com 2006-09-18, 10:06 pm |
| Hi James Bond 007 + Shrinik,
>In my view a skilled tester is a "generalist". Can I say - "Jack of all trades and the Master of Testing"?
indeed, in this fast-changing times always, but see below.
>To me, technical skills for testers include that they understand the hardware, the software architecture, the
>operating system, and other aspects of the environment the software they are testing resides in. Many times, errors
>arise not from the software being tested but from these other sources. Knowing how to analyze errors, recreate them
>and find the real cause of an anomaly are valuable skills that I'd like my testers to have.
hm, I agree to help the developers with hard-to find failures, which
they perhaps cant reproduce on their machines.
But what do you think on this: should debugging and testing be
seperated or not?
I have the opinion: they should be seperated
Testers should not concentrate too much on debugging (if the
quality-manager tells different, then it is ok or to help
the developer like stated above or if they found already so much bugs,
that the testobject is not releasable :-) ).
One of the goals of a tester is: to search for failures. Fault finding
and fixing is the part of developers.
(of course testing has more goals: generating trust, prevent failures,
measure quality)
But what is the priority?
We only have 24 hours a day :-(
actually what do you want the testers to be?
the advocate of the customer or not? (to add a fifth question to the
above 4 from Shrinik)
to be responsible, that the software works on customers side?
in the end customer pays the money.
what is your expectation of a tester?
and of course, does management agree to these goals too?
how about this one: the tester makes the developer get much more
qualified :-)
Of course in the end only teamwork will lead to a successfull project.
And this means helping each other (as good as possible).
(some possible) answers to some questions from above:
@1: non-technical - of course they can.
why should the testing team solely consist of people knowing technical
issues. Why not some unexperienced testers?
Perhaps they see failures which we do not see or cann not see anymore?
the market is so big, there is always much room for other target groups
:-)
Imagine old people using VOIP-software you just develop (not thinking
now, if they would buy or not :-) )
how would you test for this?
@2: "Should testers be programmers?"
depends on the test level you are in: on low levels: yes
in reviews also
and 2nd part:
yes, what more can a tester wish, that there is tests before the
QA-tests, so teach tetsing skills to all people.
spread the knowledge (or is it truth? :-) )
so much for now, have to go, cu next time,
Erkan
| |
| James Bond 007 2006-09-18, 10:06 pm |
|
erkan77@gmail.com wrote:
> Hi James Bond 007 + Shrinik,
>
>
> hm, I agree to help the developers with hard-to find failures, which
> they perhaps cant reproduce on their machines.
> But what do you think on this: should debugging and testing be
> seperated or not?
>
> I have the opinion: they should be seperated
> Testers should not concentrate too much on debugging (if the
> quality-manager tells different, then it is ok or to help
Testers need to be able to recreate a bug at will. If some anomaly
occurs one time and cannot be reproduced, it is hard to justify
reporting this as a bug. Testers need the ability to recreate the bugs
and document the steps taken to cause the bug. This is not debugging,
it is just documenting the bug with as much detail as possible so that
the designer knows what is happening and can focus on the analysis.
> actually what do you want the testers to be?
> the advocate of the customer or not? (to add a fifth question to the
> above 4 from Shrinik)
I think that testers should use the system in the same manner that the
customers do. They are not necessarily customer advocates, but are the
first customers of the system. Testers need to understand the
customer's environment and how the system is used in the field so that
they can replicate (or simulate) that environment. From that
perspective, in a way they are customer advocates because what makes
the testers happy will make the real customers happy.
> how about this one: the tester makes the developer get much more
> qualified :-)
I don't understand the point you are trying to make here.
> (some possible) answers to some questions from above:
> @1: non-technical - of course they can.
> why should the testing team solely consist of people knowing technical
> issues. Why not some unexperienced testers?
> Perhaps they see failures which we do not see or cann not see anymore?
> the market is so big, there is always much room for other target groups
> :-)
I have no problem with using inexperienced testers. Bring in your
spouse, your children, people from other departments (human resources,
sales/marketing people for other products, administrative assistants,
even corporate executives), your neighbor, somebody walking down the
street. Test plans ought to be written in such a way that anybody who
can use a PC can sit down and start testing. People without prior
knowledge or exposure to the software or product will try stuff that
nobody has ever thought of before.
| |
| Phlip 2006-09-18, 10:06 pm |
| James Bond 007 wrote:
> Testers need to be able to recreate a bug at will.
Then the better they can characterize it, in source, the better programmers
can fix it. A good tester (me, specifically), can even recommend a fix, if
the research leads to one. This assures the developer can find the bug
source, can match its characterization, and has the option to use this fix
or another one.
> ...This is not debugging...
Yet sometimes it is. Programmers (with poorly unit-tested code) often find
themselves wandering around the code looking for a bug source, same as a
tester.
> I think that testers should use the system in the same manner that the
> customers do.
That's /booring/!!
....Oh, uh, yeah! Of course they should!
--
Phlip
[url]http://www.greencheese.us/Z Land[/url] <-- NOT a blog!!!
| |
| erkan77@gmail.com 2006-09-23, 8:05 am |
| Hello everybody,
[color=darkred]
[color=darkred]
>Testers need to be able to recreate a bug at will.
>If some anomaly
>occurs one time and cannot be reproduced, it is hard to justify
>reporting this as a bug.
hm, see it that way, do you have all the time to test everything enough
before the release?
how about to report all anomalies you find, then you have additional
data if the bug comes again (and then you save some time).
and for not disturbing daily work, you can use an attribute in your
bug-tracking program (repeatability).
only time will tell, if this is a not-so-often-happening-bug (see
http://groups.google.com/group/comp...d6f52d926cba5e?
with Adams).
[color=darkred]
>I think that testers should use the system in the same manner that the
>customers do.
of course (but see also Phlips comment above or here at the end of this
posting)
>They are not necessarily customer advocates
this depends on the goals of testing: yes
>but are the first customers of the system.
not necessarily. What about developers? What about the persons involved
in requirements-collecting?
>Testers need to understand the
>customer's environment and how the system is used in the field so that
>they can replicate (or simulate) that environment. From that
>perspective, in a way they are customer advocates because what makes
>the testers happy will make the real customers happy.
Believe me, some customers or the majority of them are happy with less
quality attributes.
But I am definitely not so often happy, because due to the
impossibility of testing everything.
[color=darkred]
>I don't understand the point you are trying to make here.
With each failure the tester finds, the developer has the chance to
refactor
And then he can improve his skills.
to all developers: please do not kill me for that conclusion :-)
>Test plans ought to be written in such a way that anybody who
>can use a PC can sit down and start testing.
YES, that is 100% true.
it is always so: KISS (keep it simple and stupid)
If you cant write so, that everybody understands, probably there is
much more problems.
example: If you know a guy, explaining hard-to-understand topics also
for a child, be sure, he knows what he is
talking about.
[color=darkred]
>Then the better they can characterize it, in source, the better programmers
>can fix it. A good tester (me, specifically), can even recommend a fix, if
>the research leads to one. This assures the developer can find the bug
>source, can match its characterization, and has the option to use this fix
>or another one.
yes, a tester should always give a possible fix, but:
don't we then manipulate the developer?
We perhaps already narrow the developers view down. Howe about such a
feature in a bug-tracking program.
The field for the solution should be opened, when the developer wants?
[color=darkred]
>That's /booring/!!
hehe, that is sometimes true.
And why for example do not "play" with the test-object in order to get
more ideas how to crack it? :-)
CU,
Erkan
| |
| James Bond 007 2006-09-23, 7:04 pm |
|
<erkan77@gmail.com> wrote in message =
news:1159016892.320288.46560@d34g2000cwd.googlegroups.com...
> Hello everybody,
>=20
>=20
>=20
>=20
> hm, see it that way, do you have all the time to test everything =
enough
> before the release?
> how about to report all anomalies you find, then you have additional
> data if the bug comes again (and then you save some time).
> and for not disturbing daily work, you can use an attribute in your
> bug-tracking program (repeatability).
> only time will tell, if this is a not-so-often-happening-bug (see
> =
http://groups.google.com/group/comp..._thread/thread=
/ccd6f52d926cba5e?
> with Adams).
If you report a bug, you need to have all the data about what was =
happening at the time. You might not have been capturing everything you =
need when you first saw the bug. Maybe you weren't ready to start =
testing yet, or maybe you were distracted or focused on something else. =
You need to be able to recreate the bug so that development knows how it =
happened. You can't just report a bug without supporting documentation. =
Well you can, but it will not do much for your credibility.
>=20
>=20
>=20
> of course (but see also Phlips comment above or here at the end of =
this
> posting)
>=20
>=20
> this depends on the goals of testing: yes
>=20
> not necessarily. What about developers? What about the persons =
involved
> in requirements-collecting?
Developers, business analysts are not the customers. That would be like =
saying the people who work on the assembly line building the car are =
customers of the car, or the cook making your dinner is the one who will =
be eating it.
>=20
> Believe me, some customers or the majority of them are happy with less
> quality attributes.
> But I am definitely not so often happy, because due to the
> impossibility of testing everything.
>=20
>=20
>=20
>=20
> With each failure the tester finds, the developer has the chance to
> refactor
> And then he can improve his skills.
> to all developers: please do not kill me for that conclusion :-)
OK, I see. Yes, as testers find bugs and developers understand the root =
causes of them, they can learn from their mistakes and make process =
changes so that they produce better software. That does not make them =
more qualified, but it does improve their skills.
=20
>=20
>=20
> YES, that is 100% true.
>=20
> it is always so: KISS (keep it simple and stupid)
> If you cant write so, that everybody understands, probably there is
> much more problems.
> example: If you know a guy, explaining hard-to-understand topics also
> for a child, be sure, he knows what he is
>=20
> talking about.
>=20
>=20
>=20
>=20
>=20
programmers[color=darkred]
fix, if[color=darkred]
fix[color=darkred]
> yes, a tester should always give a possible fix, but:
> don't we then manipulate the developer?
> We perhaps already narrow the developers view down. Howe about such a
> feature in a bug-tracking program.
> The field for the solution should be opened, when the developer wants?
>=20
>=20
the[color=darkred]
>=20
> hehe, that is sometimes true.
> And why for example do not "play" with the test-object in order to get
> more ideas how to crack it? :-)
>=20
> CU,=20
> Erkan
>
| |
|
| James Bond 007 schrieb:
> If you report a bug, you need to have all the data about what was happening at the time.
>You might not have been capturing everything you need when you first saw the bug.
>Maybe you weren't ready to start testing yet, or maybe you were distracted or focused on
>something else. You need to be able to recreate the bug so that development knows how it
>happened. You can't just report a bug without supporting documentation. Well you can, but it
>will not do much for your credibility.
i'm afraid i don't agree with that statement. sporadic bugs are a fact
of life, and not reporting them is not going to change that. moreover,
i consider it bordering on sabotage, as in withholding vital
information from management. well that's perhaps overstating the case,
but not by much;-)
it is of course true that a non-reproducible bug is hard to find and
fix. but i have been in situations where the sheer number of such
sporadics made it clear that we were far from shipping and riddled with
stability issues. without the bug reports, all that whould have been
"based on innuendo and hearsay".
so, non reproducible bugs may not help developers much directly, but
they may very well help the overall project. i would not go without
them.
as a side: we had those credibility issues too. all these debates
stopped as soon as we shipped and the stress levels came down. i would
hence suggest that credibility debates are a (unsuitable) work load
management technique and should be managed as such.
mats
| |
| Michael Bolton 2006-09-24, 10:07 pm |
|
James Bond 007 wrote:
> If you report a bug, you need to have all the data about what was happening at the time. You might not have been capturing everything you need when you first saw the bug. Maybe you weren't ready to start testing yet, or maybe you were distracted or fo
cused on something else. You need to be able to recreate the bug so that development knows how it happened. You can't just report a bug without supporting documentation. Well you can, but it will not do much for your credibility.
Actually, you NEVER have all the data about what was happening at the
time; you merely have data that you believe is useful and important.
You don't necesarily need to be able to recreate the bug; you do need
to be able to tell a story about it that is sufficiently informative to
help development find and solve the problem. I can absolutely report a
bug without supporting documentation, and I can do so entirely
credibly. In fact, supporting documentation might be unnecessary and a
waste of time. I can see cases where documentation would be desirable
or necessary, but not all contexts are like that.
> Developers, business analysts are not the customers. That would be like saying the people who work on the assembly line building the car are customers of the car, or the cook making your dinner is the one who will be eating it.
First, line workers often are encouraged to buy and drive the cars that
they make. Ever been to the parking lot in a GM plant? Ever see a
Honda parked there? Also, if you've ever worked in a serious kitchen,
you'll understand the concept of the staff meal.
More importantly, though, even though developers and business analysts
might not be customers of the product, they are certainly customers of
the testing effort, as are (potentially and plausibly) all the other
members of the project community. If you are testing and are focused
solely on the customer, you'll fail to provide service to important
people.
> OK, I see. Yes, as testers find bugs and developers understand the root causes of them, they can learn from their mistakes and make process changes so that they produce better software. That does not make them more qualified, but it does improve their
skills.
People with better skills are usually more qualified than people with
worse skills, nicht wahr?
---Michael B.
| |
| erkan77@gmail.com 2006-09-25, 7:06 pm |
| HI,
@ James Bond 007:
***************
>If you report a bug, you need to have all the data about what was happening at the time. You might not have been
>capturing everything you need when you first saw the bug. Maybe you weren't ready to start testing yet, or maybe you
>were distracted or focused on something else. You need to be able to recreate the bug so that development knows how
>it happened. You can't just report a bug without supporting documentation. Well you can, but it will not do much
>for your credibility.
of course you are right - also with the credibility, but doesn't all
your programs offer a log-function?
And then you report it
(either to the developers with the repeatability N/A and the severity -
OR assign it to someone from testing)
And then if the bug happens again, boom - the developers have two
log-files they can search, two scenarios where this can happen and then
seach the common ground
>Developers, business analysts are not the customers. That would be like saying the people who work on the assembly
>line building the car are customers of the car, or the cook making your dinner is the one who will be eating it.
if someone sees it like (s)he would use it, then (s)he has a reference
to it/ bears upon it.
And that is why some things are better in quality than others.
Quality is very subjective - I mean I can release a software as
developer, which has all the functions like specified,
which were verified, but is it also validated?
Imagine the cook who just makes food or imagines his/her customers
sitting on the table, waiting for the food and then
the food arrives and then the twinkle in the eyes and the spittle in
the mouth gets going
and then the customer tastes it and doesnt like at all. :-(
I believe that someone doing something, must have this in his/her mind,
then every product gets best
(of course he should finally finish the product and not make aproduct
which is perfcet, but h erealizes, that already
the market is filled by all that similar products)
>OK, I see. Yes, as testers find bugs and developers understand the root causes of them, they can learn from their
>mistakes and make process changes so that they produce better software. That does not make them more qualified, but
>it does improve their skills.
lets hope so
you know: humans are just humans - and no one is god :-)
@mats:
*******
>i'm afraid i don't agree with that statement. sporadic bugs are a fact
>of life, and not reporting them is not going to change that. moreover,
>i consider it bordering on sabotage, as in withholding vital
>information from management. well that's perhaps overstating the case,
>but not by much;-)
actually our job is also that, we must provide as much info as
possible, so that the best decison could be made (to release or not)
with product-management
>it is of course true that a non-reproducible bug is hard to find and
>fix. but i have been in situations where the sheer number of such
>sporadics made it clear that we were far from shipping and riddled with
>stability issues. without the bug reports, all that whould have been
>"based on innuendo and hearsay".
>so, non reproducible bugs may not help developers much directly, but
>they may very well help the overall project. i would not go without
>them.
I agree fully!
>as a side: we had those credibility issues too. all these debates
>stopped as soon as we shipped and the stress levels came down. i would
>hence suggest that credibility debates are a (unsuitable) work load
>management technique and should be managed as such.
hm, yes, stress levels - there are some stories everybody knows of his
experience :-)
in the end it is always for the quality, but...
@Michael Bolton
***************
>First, line workers often are encouraged to buy and drive the cars that
>they make. Ever been to the parking lot in a GM plant? Ever see a
>Honda parked there? Also, if you've ever worked in a serious kitchen,
>you'll understand the concept of the staff meal.
I agree again fully
>More importantly, though, even though developers and business analysts
>might not be customers of the product, they are certainly customers of
>the testing effort, as are (potentially and plausibly) all the other
>members of the project community.
yes, I see it that way: everybody using it, is a help to QA. We cant
have enough tests :-)
>If you are testing and are focused
>solely on the customer, you'll fail to provide service to important
>people.
true, but the cutsomer is the one paying for it and also important
using it all the time, after you released.
So (s)he should be the one on top of your priority-list.
Or don't you sometimes use softwrae in your company and you wish this
an dthat feature would be more better to use, if it would be made like
this. And in the end you cant do, but just wait if it is changed, but
until then it goe son your nerves.
their skills.
[color=darkred]
>People with better skills are usually more qualified than people with
>worse skills, nicht wahr?
skills are such a thing,
lets say so: if you use them right as person it is good
but another topic
why is it then, that older people do not get a job anymore
why are they retired so early? normally they should have with their
experience enough skills to manage all.
CU guys,
Erkan
| |
| James Bond 007 2006-09-25, 7:06 pm |
|
Michael Bolton wrote:
> James Bond 007 wrote:
focused on something else. You need to be able to recreate the bug so that development knows how it happened. You can't just report a bug without supporting documentation. Well you can, but it will not do much for your credibility.[color=darkred]
>
> Actually, you NEVER have all the data about what was happening at the
> time; you merely have data that you believe is useful and important.
> You don't necesarily need to be able to recreate the bug; you do need
> to be able to tell a story about it that is sufficiently informative to
> help development find and solve the problem. I can absolutely report a
> bug without supporting documentation, and I can do so entirely
> credibly. In fact, supporting documentation might be unnecessary and a
> waste of time. I can see cases where documentation would be desirable
> or necessary, but not all contexts are like that.
OK, let's say that whenever it is possible and feasible, testers ought
to include as much supporting documentation as they can. I dodn't mean
to make it sound like an umbrella statement. Of course there are
always exceptions to any process or rule.
>
> First, line workers often are encouraged to buy and drive the cars that
> they make. Ever been to the parking lot in a GM plant? Ever see a
> Honda parked there? Also, if you've ever worked in a serious kitchen,
> you'll understand the concept of the staff meal.
>
> More importantly, though, even though developers and business analysts
> might not be customers of the product, they are certainly customers of
> the testing effort, as are (potentially and plausibly) all the other
> members of the project community. If you are testing and are focused
> solely on the customer, you'll fail to provide service to important
> people.
Encouraged does not mean customer. Sure they are encouraged. Someone
buying a Windows PC doesn't have much choice - they are customers of
Microsoft whether they like it or not. Most of the line workers will
buy the cars they make for several reasons: 1) they believe in their
company and know that their cars are built with quality, 2) they know
all the details about the cars including how to get support, who can
fix them if they can't do it themselves, etc., and 3) they get employee
discounts. You will still find some folks driving Hondas and Toyotas
there because they are new hires, they inherited the car from their
parents, or they won the car on a game show or a slot machine in Las
Vegas. :)
Of course the folks who work at a restaurant eat the food. But the
chef making my steak is not going to be eating my steak. He may make
the same dinner for himself or for a waitress, but it won't be MY
dinner. I'm sure most Dell employees have Dell PCs at their homes, but
it's not the same PC that is on MY desk or in MY lap.
I never said that there were not internal customers. We were talking
about the product, not the process. You have changed the scope of the
discussion.
ir skills.[color=darkred]
>
> People with better skills are usually more qualified than people with
> worse skills, nicht wahr?
"Qualified" means what kind of education one has, how many years of
experience, any certifications, publications, etc. All those things,
not just experience in and of itself. Making and fixing a lot of bugs
does not mean that they are more qualified. If a developer has a
history of making many bugs, and that performance has not improved over
the years, I don't think I'd want that person on my team. If someone
worked on a project that had lots of problems, where they were fighting
fires all the time, I think I would pass on that person, too. If a
programming quiz was done as part of the hiring process, then we could
say that the developer with better skills, who scored better on that
quiz, was more qualified.
James Bond 007
|
|
|
|
|