Home > Archive > Software Testing > July 2006 > software testing
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]
|
|
| software testing 2006-06-24, 7:09 pm |
| hi I am prashant having starting knowlege of CCNA & MCP(but not geeting
much experience), want to start carrer in software testing....can
anyone guide me for this..
what is the basic requirement of software field...I have completed BE
in Electronics so not in touch of any language....
Can I do this course so I can start my carrer in S/W company
| |
|
|
software testing wrote:
> hi I am prashant having starting knowlege of CCNA & MCP(but not geeting
> much experience), want to start carrer in software testing....can
> anyone guide me for this....
Well, If you grab the classifieds in the papers you'll see that for the
post of software testers Cos. demand 10-15 yrs experience! But this
shouldn't demoralise you...but however you can decipher the magnitude
of this field!
Well "Software Testing" is quite unlike the actual "tangible" products
testing. To gain a sound understanding of this field it is beneficial
to have a computer background. Yes, knowing coding is helpful but not
100% mandatory. To gain an insight into this field have a look at this
book
Effective methods for Software Testing by William Perry (Wiley Pubs).
It costs Rs.380/- and it's worth every penny. It'll give you a good
insight into this field and then you can decide for yourself what do
you wish to do thereon!
Hope I was of help
Nupul.
| |
| Matt Johnson 2006-06-24, 7:09 pm |
| NUPUL wrote:
....
> Well "Software Testing" is quite unlike the actual "tangible" products
> testing.
....
What is the difference between software testing and product testing.
-- Matt Johnson
| |
| James Bond 007 2006-06-24, 7:09 pm |
|
"Matt Johnson" <mattj@3am-software.com> wrote in message =
news:129o3ehion1qg77@corp.supernews.com...
> NUPUL wrote:
> ...
>=20
products[color=darkred]
> ...
>=20
> What is the difference between software testing and product testing.
>=20
> -- Matt Johnson
You've got to be kidding.
| |
|
| James Bond 007 wrote:
[color=darkred]
[color=darkred]
> You've got to be kidding.
Do you mean there's no difference?
Or do you mean the difference is too obvious to state?
If the latter, how would you state the difference? Is it too obvious to
state? Even with my feeble rhetorical skills, I can state the difference
between day and night, obvious though it may be.
So have a crack at it - what's the difference?
--
Phlip
[url]http://c2.com/cgi/wiki?Z Land[/url] <-- NOT a blog!!!
| |
| Matt Johnson 2006-06-24, 7:09 pm |
| Phlip wrote:
> James Bond 007 wrote:
>
>
>
>
> Do you mean there's no difference?
>
> Or do you mean the difference is too obvious to state?
>
> If the latter, how would you state the difference? Is it too obvious to
> state? Even with my feeble rhetorical skills, I can state the difference
> between day and night, obvious though it may be.
>
> So have a crack at it - what's the difference?
>
Perhaps I am not sufficiently devoted to nomenclature, but I do not
think there is a meaningful difference between software testing and
product testing.
-- Matt Johnson
| |
|
| Matt Johnson wrote:
> Perhaps I am not sufficiently devoted to nomenclature, but I do not think
> there is a meaningful difference between software testing and product
> testing.
My bad. I accidentally thought that "products" could include hardware. You
know - protons.
Silly me!
--
Phlip
| |
| James Bond 007 2006-06-24, 7:09 pm |
|
"Phlip" <phlip2005@gEEEmail.com> wrote in message =
news:pan.2006.06.24.05.39.40.696581@gEEEmail.com...
> Matt Johnson wrote:
>=20
think[color=darkred]
>=20
> My bad. I accidentally thought that "products" could include hardware. =
You
> know - protons.
>=20
> Silly me!
>=20
> --=20
> Phlip
Silly me too. I interpreted "products" to mean anything from cars to =
newspapers to blue jeans. I'm not aware of any software in blue jeans. =
In the business systems of the company, certainly. But not in the jeans.
| |
|
| James Bond 007 wrote:
> Silly me too. I interpreted "products" to mean anything from cars
> to newspapers to blue jeans. I'm not aware of any software in blue
> jeans. In the business systems of the company, certainly. But not
> in the jeans.
The aspect of a "product" most relevant to testing is its assembly line. So
the process of producing jeans _is_ the process of setting up and tuning
their assembly line.
Plenty of hardware and software to test. For example, suppose the supplier
of your cloth starts using a certifiable technique, such as Statistical
Process Control, to tune their machines. You can then skip the inspection
phase on your cloth input, and can run it directly through your own
machines.
Put another way, testing at the right point in the process can realize
orders of magnitude of savings on industrial waste of all kinds.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Michael Bolton 2006-06-24, 10:07 pm |
| > The aspect of a "product" most relevant to testing is its assembly line. So
> the process of producing jeans _is_ the process of setting up and tuning
> their assembly line.
That's interesting. Do you think the process of developing a piece of
software is an assembly-line process?
---Michael B.
| |
| Phlip 2006-06-24, 10:07 pm |
| Michael Bolton wrote:
> That's interesting. Do you think the process of developing a piece of
> software is an assembly-line process?
A metaphor is a leaky bucket should only be used to carry water short
distances.
The aspect of software development that's like an assembly line is the
feature request stream. Users request features, a business analyst schedules
them, programmers implement them, testers test them, and users use them.
That's why extreme programming uses cards as tokens for the location of a
feature on the line.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Matt Johnson 2006-06-24, 10:07 pm |
| James Bond 007 wrote:
> "Phlip" <phlip2005@gEEEmail.com> wrote in message news:pan.2006.06.24.05.39.40.696581@gEEEmail.com...
>
> Silly me too. I interpreted "products" to mean anything from cars to newspapers to blue jeans. I'm not aware of any software in blue jeans. In the business systems of the company, certainly. But not in the jeans.
Silly indeed. Jeans, cars and newspapers would not be discussed in a
newsgroup about software testing.
| |
|
| Matt Johnson wrote:
> Silly indeed. Jeans, cars and newspapers would not be discussed in a
> newsgroup about software testing.
My jeans and my car have software running inside them. I'm waiting for the
newspaper to...
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Michael Bolton 2006-06-25, 8:08 am |
| > > That's interesting. Do you think the process of developing a piece of
>
> A metaphor is a leaky bucket should only be used to carry water short
> distances.
I don't think your metaphor is a bucket; I think it's a sieve.
<-metaphor
> The aspect of software development that's like an assembly line is the
> feature request stream. Users request features, a business analyst schedules
> them, programmers implement them, testers test them, and users use them.
>
> That's why extreme programming uses cards as tokens for the location of a
> feature on the line.
I don't see the assembly line as a useful metaphor for the development
process, but that you've described it this way makes a lot of our
fundamental disagreements much more clear. I thought you were an
advocate of XP and Agile processes, but what you're describing is
manifestly the waterfall, only with cards.
In my vision of the world, there are dozens and dozens of ways for a
feature to be added to a product. Here's only one:
A user recognizes a need for a feature, and expresses that need to a
business analyst. The business analyst talks about the idea with the
user and with a programmer. The programmer asks the user for
clarification of the feature, which the user provides. The business
analyst remarks that there's already a similar feature, and they decide
that, rather than writing something new, they'll make a couple of
changes to the old feature. In the next day's standup meeting, the
tester identifies two serious risks associated with the modification
idea. The developers put their heads together, and figure out a way to
address one of the risks. For the other, they set up a spike (an
exploratory development process) for the next w's iteration. That
spike involves research into how to implement the feature, prototyping
a throwaway attempt at the product, and the B.A. calling a colleague to
see how a similar got solved at another company). The tester tries the
prototype, sees a problem or two, and the developer fixes them right
away. The prototype works okay, in its limited way. The feature is
scheduled for the next iteration. The B.A. sits down with the user,
and they charter the new feature more formally. They might implement a
description of the feature on a Wiki page in FitNesse, and some tests
implemented as five tables using older fixtures and three proposed
fixtures. The testers review the page, make a couple of additions to
the existing tables, and add two more. They also describe a bunch of
tests that they'll perform manually, about half of which they intend to
automate using WATIR. The developers write some code to pass the new
tests, and work on the new fixtures. They they write some new code to
pass the new fixtures. They run these tests themselves; then the
testers run some of their tests. The B.A. looks over the testers'
shoulders, and suggest a couple of new test ideas. The code fails one
of them. They call the developer over, and the developer recognizes
the problem. She goes back to a workstation, fixes the problem, and
rebuilds. The tester reruns the test, which passes. At the next
morning's standup meeting, they declare the feature complete.
Where's the assembly line here?
---Michael B.
| |
| Phlip 2006-06-25, 10:08 pm |
| Michael Bolton wrote:
> In my vision of the world, there are dozens and dozens of ways for a
> feature to be added to a product. Here's only one:
>
> A user recognizes a need for a feature, and expresses that need to a
> business analyst. The business analyst talks about the idea with the
> user and with a programmer.
I don't understand how you think my "metaphor" forbade that. Do you think
that roles and individuals are forced to remain on only specific points
along the belt?
<Snip boring story about cards moving in various directions besides down the
belt.>
> Where's the assembly line here?
Do you think I thought that cards must stay fixed to the belt, must move in
one direction, must never change their positions, must move at the same
rate, etc? Was this entire diatribe an elaborate way to describe all the way
the cards could step out of sequence?
Or did you actually think my metaphor somehow implied I'm too stupid to
realize some card paths don't go straight down the belt??
The metaphor works because the belt moves, not the cards. When you place one
on the belt, you know that either it will move through refinement to
implementation to QA without intervention, or intervention will move it
around the belt (and you know that intervention is obviously possible
_because_ the cards are seen on the belt!).
Mary Poppendieck describes the process we s as (IIRC) "autonomatic". That
means at each step, my environment tells me what to do. [Insert long boring
fable about environments telling workers to do the wrong thing here. Etc.
etc.]
Standing at a station on the conveyor belt, I pull a card. (In reality, I
pull it from a column of a corkboard.) Then I check its readiness for my
station, and attempt to do my thing, to pass it to the next station. If it
fails, I pass it to someone else for special attention. If it passes my
station, I put it into the inbox for the next station.
Some folks don't use cards. Whatever. Their feature requests still move down
an assembly line.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Michael Bolton 2006-06-26, 7:11 pm |
| > Do you think I thought that cards must stay fixed to the belt, must move in
> one direction, must never change their positions, must move at the same
> rate, etc? Was this entire diatribe an elaborate way to describe all the way
> the cards could step out of sequence?
>
> Or did you actually think my metaphor somehow implied I'm too stupid to
> realize some card paths don't go straight down the belt??
Your metaphor can be interpreted a number of ways, which is what makes
metaphors interesting and powerful, and also what makes them dangerous.
You might have one impression of what you mean, but your readers may
take quite another. I did.
When I read about software development as an assembly line, the first
thing that comes to my mind is processes and tools, rather than people
and interactions. In an assembly line, the product is assembled in a
completely linear, straight-ahead fashion. The people complicate
things, since they're ornery, fallible, and bored; so for products that
are put together by that process, robots are much more desirable.
A more powerful metaphor for the Agile approach (one which Mary
Poppendieck uses; Lean development) might be the Toyota approach, in
which teams of well-trained, empowered, and skilled people assemble the
vehicle. It's not anywhere near as linear as the North American
robotic process. One might also ask this pointed question: which mode
of production is used by the companies with increasing customer
satisfaction and market share?
In any case, I think the metaphor isn't terribly powerful either way,
because to me, software development (including programming, including
testing) is not an assembly process; it's a design process.
> The metaphor works because the belt moves, not the cards. When you place one
> on the belt, you know that either it will move through refinement to
> implementation to QA without intervention, or intervention will move it
> around the belt (and you know that intervention is obviously possible
> _because_ the cards are seen on the belt!).
The metaphor of software-development-as-assembly-line is one that Kent
Beck has explicitly attacked in his presentations on software
development. I'm surprised that any Agilist would use it in any
context. Then again, maybe I'm not.
> Mary Poppendieck describes the process we s as (IIRC) "autonomatic". That
> means at each step, my environment tells me what to do. [Insert long boring
> fable about environments telling workers to do the wrong thing here. Etc.
> etc.]
> Standing at a station on the conveyor belt, I pull a card. (In reality, I
> pull it from a column of a corkboard.) Then I check its readiness for my
> station, and attempt to do my thing, to pass it to the next station. If it
> fails, I pass it to someone else for special attention. If it passes my
> station, I put it into the inbox for the next station.
I don't stand at a station at a conveyor belt, and when I've
accomplished something, I pass it to a person, not a station. The
metaphor, frankly, disgusts me. I work in a design studio. We walk
around, we discuss, we write, we draw. We try stuff out, and show it
to each other. We collaborate. We get out of the office and try stuff
out in the real world. We give our products to people and let them try
it out. We watch them using it, and listen to what they have to say
about it. We realize we've made some mistakes. We come back to the
office, and refine our designs until we've got something that we like
and, more importantly, that the customer likes.
> Some folks don't use cards. Whatever. Their feature requests still move down
> an assembly line.
Not anywhere I'd want to work. Your assumption that I was focused on
the cards, rather than on the people and interactions, once again
speaks volumes.
---Michael B.
| |
| software testing 2006-06-27, 7:08 pm |
| Tell me what to do .....
Can I complete S/W Testing course without no knowledge of any language?
what should I do ..............
| |
|
| software testing wrote:
> Can I complete S/W Testing course without no knowledge of any language?
That depends on the course.
However, once you get a job, if you cannot program then you will be
treated _as_ a program. You will be given a list of operations, and you
will do them over and over again, mindlessly.
I have seen this done for Video games, so playing the game makes this
situation healthier.
If you can program, however, then you can participate in helping
developers go faster. That is a significant and rewarding achievement. So
learn to program!
--
Phlip
| |
|
| Testers without programming experience, but with a helpful attitude,
good investigative skills and the ability to communicate problems
clearly and at the right time are able to help developers go faster. I
don't see programming ability as a prerequisite. I'm sure there are
some helpful activities that are out of reach for non-programming
testers though.
Not sure what you are getting at with your comment about video games,
and what situation is made healthier by 'playing the game'. I tested
games for over four years, so am curious :)
Jared
> However, once you get a job, if you cannot program then you will be
> treated _as_ a program. You will be given a list of operations, and you
> will do them over and over again, mindlessly.
>
> I have seen this done for Video games, so playing the game makes this
> situation healthier.
>
> If you can program, however, then you can participate in helping
> developers go faster. That is a significant and rewarding achievement. So
> learn to program!
>
> --
> Phlip
| |
| Phlip 2006-06-27, 10:03 pm |
| Jared wrote:
> Testers without programming experience, but with a helpful attitude,
> good investigative skills and the ability to communicate problems
> clearly and at the right time are able to help developers go faster. I
> don't see programming ability as a prerequisite. I'm sure there are
> some helpful activities that are out of reach for non-programming
> testers though.
>
> Not sure what you are getting at with your comment about video games,
> and what situation is made healthier by 'playing the game'. I tested
> games for over four years, so am curious :)
If I can't automate a test, and if computer-literate resources were cheap, I
might "automate" the test by passing them the script, and letting them
manually run the test over and over again. That differs from your suggestion
when it doesn't involve "creatively stressing the program to s bugs".
One Brian Marick raised the point, elsewhere, that there are recruitment
firms in certain low-rent areas that specialize in promising every candidate
a job (probably collecting a stiff fee from them), and dumping them into
this Horde Manual Testing role. That would indeed explain the rash of "how
to test?" posts here - people think they'll get a job, have no training, and
ask here how to do it.
When you HMT a video game, you are allowed to also play the game, and you
are inspired to get in trouble, shoot the chandelier, jump into chasms, etc.
So creatively stressing the game becomes much easier, and you can also
participate like that.
For a dreary business application, you either stay on the script and remain
a "biologically automated test", or you go off the script and either
everything works, or your boss catches you playing!
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| The original question seemed to be whether one could become a software
tester (or pass a certification) without knowledge of a language (we
assume, a programming language). I get plenty of resumes from people
who learnt to program, but still appear to have been the kind of
testers you described (HMT). I don't think programming ability is the
factor that determines whether a person ends up being that kind of
tester.
I'd really like clearly understand what point you are trying to make
regarding the value of programming ability to software testers. I
don't feel like I'm getting it. Or are you making a different point
(related to the Horde Manual Test postings in the agile-testing yahoo
group)?
Happy to babble on about HMT approaches to games testing though :)
Jared
> If I can't automate a test, and if computer-literate resources were cheap, I
> might "automate" the test by passing them the script, and letting them
> manually run the test over and over again. That differs from your suggestion
> when it doesn't involve "creatively stressing the program to s bugs".
>
> One Brian Marick raised the point, elsewhere, that there are recruitment
> firms in certain low-rent areas that specialize in promising every candidate
> a job (probably collecting a stiff fee from them), and dumping them into
> this Horde Manual Testing role. That would indeed explain the rash of "how
> to test?" posts here - people think they'll get a job, have no training, and
> ask here how to do it.
>
> When you HMT a video game, you are allowed to also play the game, and you
> are inspired to get in trouble, shoot the chandelier, jump into chasms, etc.
> So creatively stressing the game becomes much easier, and you can also
> participate like that.
>
> For a dreary business application, you either stay on the script and remain
> a "biologically automated test", or you go off the script and either
> everything works, or your boss catches you playing!
| |
| Matthias Wolpers 2006-06-29, 4:10 am |
| In article <1151476161.267575.311490@j72g2000cwa.googlegroups.com>,
"Jared" <xflibble@gmail.com> wrote:
> I'd really like clearly understand what point you are trying to make
> regarding the value of programming ability to software testers.
two thoughts:
a) aptitude for testing:
I find that testers may profit from programming skills in a somewhat
indirect way. anybody who has ever written a nontrivial piece of code
will understand the kind of mistakes that just seem happen, given the
present state of that craft.
in my experience, this helps (at least)
- to reckognise bug patterns (e.g. in code reviews)
- to make mental models of what could go wrong and to craft test cases
for such potential errors
- to write bug reports that actually help the programmers
while these effects seem desirable, they may be achieved by other means.
Also, other factors (like an inflated sense of one's own importance, to
mention one) may hinder or even completely block the fruition of those
effects : hence, i should call "programming skill" neither necessary nor
sufficient, but it can have a bearing.
b) handicraft:
a fair bit of system testing is open to automation , which in turn often
necessitates some manner of script programming. clearly, testers with
prog skill have an edge here.
hth,
mats
| |
|
|
Matthias Wolpers wrote:
> In article <1151476161.267575.311490@j72g2000cwa.googlegroups.com>,
> "Jared" <xflibble@gmail.com> wrote:
> two thoughts:
> a) aptitude for testing:
Yes, it adds to their bag of error theories or failure models. This
may help a person with testing aptitude, but applying those theories or
models fruitfully is not a guaranteed outcome.
> I find that testers may profit from programming skills in a somewhat
> indirect way. anybody who has ever written a nontrivial piece of code
> will understand the kind of mistakes that just seem happen, given the
> present state of that craft.
> b) handicraft:
> a fair bit of system testing is open to automation , which in turn often
> necessitates some manner of script programming. clearly, testers with
> prog skill have an edge here.
Again, it's not critical to being a good tester. It just means that
that tester doesn't have to rely on developer resources to perform
certain testing tasks. In some situations this might help the team
find important problems faster. At other times and in other
situations, the testing skills of the tester are going to be the
limiting factor to their usefulness.
If I have two candidates, all other things equal bar programming
ability, the guy with programming skills will get the nod. Otherwise,
I don't believe the ability of a candidate to program has much bearing
at all on their value, suitability or aptitude for testing. I have
hiring tests that I believe tell me something about the attributes of
the candidate that indicate whether they will be a good tester. I rely
on these.
So I'm still unclear on the point that Phlip is trying to make in
relation to the original posting.
Jared
| |
| James Bond 007 2006-07-02, 7:03 pm |
|
"Jared" <xflibble@gmail.com> wrote in message =
news:1151642197.330037.211950@y41g2000cwy.googlegroups.com...
>=20
> Matthias Wolpers wrote:
make[color=darkred]
>=20
> Yes, it adds to their bag of error theories or failure models. This
> may help a person with testing aptitude, but applying those theories =
or
> models fruitfully is not a guaranteed outcome.
>=20
>=20
often[color=darkred]
>=20
> Again, it's not critical to being a good tester. It just means that
> that tester doesn't have to rely on developer resources to perform
> certain testing tasks. In some situations this might help the team
> find important problems faster. At other times and in other
> situations, the testing skills of the tester are going to be the
> limiting factor to their usefulness.
>=20
> If I have two candidates, all other things equal bar programming
> ability, the guy with programming skills will get the nod. Otherwise,
> I don't believe the ability of a candidate to program has much bearing
> at all on their value, suitability or aptitude for testing. I have
> hiring tests that I believe tell me something about the attributes of
> the candidate that indicate whether they will be a good tester. I =
rely
> on these.
>=20
> So I'm still unclear on the point that Phlip is trying to make in
> relation to the original posting.
>=20
> Jared
Testers often need to write scripts or small programs on their own and =
can't rely on developer resources. The testers are already testing the =
developers' software. If they also need to rely on them for scripting =
or test automation, well that just clouds the picture. Clearly, testers =
with previous programming and design experience are preferred. In fact, =
I would not want any testers that did not have some programming =
knowledge. The best testers are the ones who started their careers as =
programmers and then moved into testing roles, for they understand both =
sides of the street.
James
| |
| Jared 2006-07-03, 10:03 pm |
| > Testers often need to write scripts or small programs on their own and can't rely on
> developer resources.
I didn't dispute this point in my posting. I'm simply suggesting that
there are testing activities and there are programming activities.
Writing scripts or support programs is a programming activity. We can
choose to add developer resources to support this, or we can choose to
hire a tester with the necessary skills, but there is no choice that is
always best or always right. You might prefer to do it one way, but
there is more than one way to get the job done. Much will depend on
what skills are in the team now, what candidates are in the
marketplace, and what kind of team member suits the way we are
currently working.
> The testers are already testing the developers' software. If they also need to rely on
> them for scripting or test automation, well that just clouds the picture.
> Clearly, testers with previous programming and design experience are preferred.
> In fact, I would not want any testers that did not have some programming knowledge.
That's great. Whatever gets the job done is great. Don't assume
though that the tester skill set you like your testers to have is going
to work for everyone else. And consider what you might be missing out
on by only hiring testers who know how to program.
> The best testers are the ones who started their careers as programmers and then
> moved into testing roles, for they understand both sides of the street.
The best testers *in your experience*, and based on the criteria by
which *you* judge a tester to be good are those that started their
career as programmers. If you are a programmer, then one way for me to
interpret this is that 'Testers who know how to program are more help
to developers than testers who don't'. Might other people on the
project have a different point of view?
I have experience which contradicts yours. What can we learn from
this?
Jared
| |
| James Bond 007 2006-07-05, 7:02 pm |
|
"Jared" <xflibble@gmail.com> wrote in message =
news:1151976379.794871.295330@75g2000cwc.googlegroups.com...
and can't rely on[color=darkred]
>=20
> I didn't dispute this point in my posting. I'm simply suggesting that
> there are testing activities and there are programming activities.
> Writing scripts or support programs is a programming activity. We can
> choose to add developer resources to support this, or we can choose to
> hire a tester with the necessary skills, but there is no choice that =
is
> always best or always right. You might prefer to do it one way, but
> there is more than one way to get the job done. Much will depend on
> what skills are in the team now, what candidates are in the
> marketplace, and what kind of team member suits the way we are
> currently working.
Whatever works in your environment. But my experience is that =
development has enough to do just getting their stuff working and =
delivered to the testers on time. In addition to their software, they =
have design documents, reviews, meetings, etc. Asking them to write =
scripts for the testers is an added burden that they just don't have =
time for.
You talk about candidates. I see and hear about companies that place =
new college graduates in testing roles, so that they can learn the =
products. My experience is that this is not a great idea. Testing is =
not the place for new hire training. Inexperienced testers just don't =
find as many bugs as experienced ones. Kids out of college should start =
in a position which they have been studying and preparing for, and most =
of the time that is in a programmer or design role. Although, I know =
that some schools are now offering software testing classes and there =
could be some graduates who choose to become testers right off the bat. =
I would certainly give them that opportunity but would pair them with an =
experienced tester as their mentor and trainer if possible.
also need to rely on[color=darkred]
picture.[color=darkred]
>=20
preferred.[color=darkred]
>=20
programming knowledge.[color=darkred]
>=20
> That's great. Whatever gets the job done is great. Don't assume
> though that the tester skill set you like your testers to have is =
going
> to work for everyone else. And consider what you might be missing out
> on by only hiring testers who know how to program.
I don't see where I am missing out on anything. Testers with a more =
broad background, testers with previous programming experience and/or =
experience in other aspects of the SDLC (such as business analysts =
writing requirements, tech writers producing documentation, customer =
support engineers, installers, trainers, etc.) are going to be better =
testers than those who do not have the added experience.
programmers and then[color=darkred]
street.[color=darkred]
>=20
> The best testers *in your experience*, and based on the criteria by
> which *you* judge a tester to be good are those that started their
> career as programmers. If you are a programmer, then one way for me =
to
> interpret this is that 'Testers who know how to program are more help
> to developers than testers who don't'. Might other people on the
> project have a different point of view?
Clearly, everything I say and post here is my opinion. I don't need to =
preface every statement with the phrase "In my opinion, ".
I'd like to hear that other point of view. Although I didn't say it, I =
agree with your interpretation. Testers with programming knowledge can =
relate better with the programmers and will understand the issues the =
programmers are dealing with. If the programmer wants to explain to the =
tester how an error was introduced, the tester will surely understand =
much more if he/she can put themselves in the programmer's shoes.
> I have experience which contradicts yours. What can we learn from
> this?
All I can learn from this is that you have a different experience. :) =
Why don't you share it with us?=20
James Bond
Agent 007
| |
|
| > Whatever works in your environment. But my experience is that development has enough to do
> just getting their stuff working and delivered to the testers on time. In addition to their software,
> they have design documents, reviews, meetings, etc. Asking them to write scripts for the
> testers is an added burden that they just don't have time for.
If developers build the test tools, maybe the tools will be better and
more easily maintained. Maybe the experience of developing the test
tools will help developers understand testers' concerns. Maybe the
testers will have much more time to explore and find important problems
if they don't have to spend time building test tools. Of course,
having testers build the tools will have benefits as well, but we need
to consciously make these tradeoffs.
> You talk about candidates. I see and hear about companies that place new college graduates in
> testing roles, so that they can learn the products. My experience is that this is not a great idea.
> Testing is not the place for new hire training. Inexperienced testers just don't find as many bugs
> as experienced ones. Kids out of college should start in a position which they have been
> studying and preparing for, and most of the time that is in a programmer or design role.
> Although, I know that some schools are now offering software testing classes and there could
> be some graduates who choose to become testers right off the bat. I would certainly give them
> that opportunity but would pair them with an experienced tester as their mentor and trainer if
> possible.
This seems to be a new topic. I was simply suggesting that if the
market doesn't have people with the skill set you desire, it's good to
be flexible. We can do this by not thinking about 'tester' and
'developer', but thinking in terms of the skills that individuals have.
Having testers build test tools and harnesses doesn't make that work
go away, it just shifts it somewhere else. We could just as easily
hire extra developers to do that work as we could hire testers.
> I don't see where I am missing out on anything. Testers with a more broad background, testers
> with previous programming experience and/or experience in other aspects of the SDLC (such
> as business analysts writing requirements, tech writers producing documentation, customer
> support engineers, installers, trainers, etc.) are going to be better testers than those who do not
> have the added experience.
I hired two people with no prior domain, software or testing
experience, and they're great testers. The development team love the
work they do.
The things that make a great tester are often enhanced by the
experiences you describe, but those experiences aren't responsible for
making anyone a great tester. Great testers come from a variety of
backgrounds and each brings their own unique perspective. If you are
only hiring technical people, then I expect your team's viewpoints are
skewed in some way. Sometimes this is good, sometimes it isn't.
> Clearly, everything I say and post here is my opinion. I don't need to preface every statement with the phrase "In my opinion, ".
I understand you to be making these claims -
- The best testers understand both sides of the street.
- People who start their careers as programmers and then move into
testing roles understand both sides of the street.
I had hoped you would clarify your criteria for tester goodness, and
how those criteria help the projects that you've worked on succeed.
When might those attributes work against us finding the important
problems on a project? When might those attributes give us a better
chance of success?
> I'd like to hear that other point of view. Although I didn't say it, I agree with your interpretation.
> Testers with programming knowledge can relate better with the programmers and will
> understand the issues the programmers are dealing with. If the programmer wants to explain to
> the tester how an error was introduced, the tester will surely understand much more if he/she
> can put themselves in the programmer's shoes.
Testers do typically provide a service to developers. I think this is
generally a healthy way for a tester to see themself, and that skills
that help testers provide this service are important. Testers also
usually represent the interests of many other parties, and the skills
that let them do this are also really important. Their importance
differs a lot depending on the project context. I'm simply pointing
out that what works best for the developers may not always be best for
the project as a whole.
>
> All I can learn from this is that you have a different experience. :) Why don't you share it with
> us?
My current environment has a lot of talented programmers, and they
provide most of the programming support to the test team. We hired
testers who had the ability to ask hard questions and explore. My
manager and I *chose* this team model, because it built on the
strengths of the team. We discussed other possible ways for team
members to work and what skills we wanted programmers and testers to be
investing in. We then made an informed choice based on the kind of
organisation we wanted to have, rather than rely on any default
behaviour.
I've worked in many different places, with many different testers and
programmers. I've learned that every place is different, and yet most
of us are quick to assume that what works for us will work somewhere
else for different people. If things are working for you, I'm not
suggesting that anything be changed. I just think that it's healthy
(and helpful) for us to talk about the assumptions underlying what we
do and why it works for us.
Jared
http://www.quinert.com/blog/
| |
| Paul Szymkowiak 2006-07-06, 8:02 am |
| James Bond 007 wrote:
> You talk about candidates. I see and hear about companies that place new college
> graduates in testing roles, so that they can learn the products. My experience is that
> this is not a great idea. Testing is not the place for new hire training.
In my experience, hiring Computer Science graduates into testing roles
can work well. In particular, it provides practical exposure to a good
range of software quality issues through tangible experience (important
concerns *not* often addressed well in academic courses). My experience
has been that CS graduates who start out as testers, or spend some time
working in testing roles, have made some of the better software
developers I've worked with.
> Inexperienced testers just don't find as many bugs as experienced ones.
My experience is that analyzing who is (on average) best at finding the
most bugs is a complex thing to determine, and quite frankly isn't
always a terribly meaningful statistic. I've worked with incredibly
experienced, certified testers who couldn't find a non-trivial bug if
it bit them, let alone communicate it well. And I've trained completely
inexperienced testers with no software development schooling or
experience, who in a short time proved to have an excellent ability to
find important problems fast (In fact, one went on to be a great
software developer). So my conclusion is that some people make good
testers, and others don't: experience plays a part, but it isn't an
absolute measure.
> Kids out of college should start in a position which they have been studying and
> preparing for, and most of the time that is in a programmer or design role.
My experience has been that fresh grad's often don't make great
developers out-of-the-gate. Typically, they benefit from some period of
time getting a grounding in the practical realities of commercial
software development. A probationary period where they start in a
supporting coding role (non-critical code, bug fixing, building
utilities such as test, support and diagnostic tools), or having them
spend time working in different software development disciplines can be
a useful start to a good development career. There are of course
arguments against that approach. The right choice depends a lot on your
specific situation.
> Although, I know that some schools are now offering software testing classes and there
> could be some graduates who choose to become testers right off the bat. I would certainly
> give them that opportunity but would pair them with an experienced tester as their mentor
> and trainer if possible.
As you surely would with a graduate working to become a developer,
right?
> I don't see where I am missing out on anything. Testers with a more broad background,
> testers with previous programming experience and/or experience in other aspects of the
> SDLC (such as business analysts writing requirements, tech writers producing documentation,
> customer support engineers, installers, trainers, etc.) are going to be better testers than those
> who do not have the added experience.
Testers with a strong coding background have certain strengths, just as
they have certain biases and weaknesses.
Testers with a strong analysis background have others. Testers with no
software-development background, but domain/ SME background have still
others.
It differs a little depending on the software-project context, but
all-thing-being-equal, I like to have a test team with a mix of
backgrounds.
Testing is a broad, deep, complex and challenging discipline: there is
scope for many different skills and perspectives.
Paul Szymkowiak
| |
| software testing 2006-07-06, 8:02 am |
| Hi i m prashant ,
I have started this topic...daily I am getting a new good things from
you both (Jared & James Bond ).
my basic problem is that I am from Networking field, want to start
carrer in software testing ........Can I utilise my N/W knowledge in
that? ...Can I handle or become a good Tester
But what I got from our discussion is that, both are saying right (in
both way)..depend upon your working exprience.
soooooooooo
| |
|
| Hi Prashant,
I'm not sure about your employment environment, so I could not say with
any certainty how easy or difficult it might be for you to move to
software testing from networking. If you can land a testing job, then
becoming a marketable tester is entirely up to you. I believe that
rising above the pack is, at this point in time, not too hard.
Below is untested advice, that you can apply on your own. I like to
think that the kind of person I would hire might come to me by this
path, and that I might be a better tester now if somebody gave me this
advice a long time ago -
- Read about software testing. You can find some good books mentioned
in some of the recent threads, and a great deal of helpful material at
www.testingeducation.org. Apply it to your open source testing
efforts.
- Find an open source application and test it. Log clearly written,
helpful bugs for the project team. Make your own test plan or
strategy. Bring these to interviews and be prepared to talk about
them.
- Play with open source test automation tools and build a simple
framework.
Above all, think about your testing as you do it, and try explaining to
others what it is that you are doing and thinking. Write it down if
you can't find anyone to listen.
There are a few points in my last blog post that may also be relevant
to your situation -
http://www.quinert.com/blog/
Best of luck,
Jared
software testing wrote:
> Hi i m prashant ,
>
> I have started this topic...daily I am getting a new good things from
> you both (Jared & James Bond ).
>
> my basic problem is that I am from Networking field, want to start
> carrer in software testing ........Can I utilise my N/W knowledge in
> that? ...Can I handle or become a good Tester
>
> But what I got from our discussion is that, both are saying right (in
> both way)..depend upon your working exprience.
>
> soooooooooo
| |
| Michael Bolton 2006-07-07, 7:03 pm |
| Paul Szymkowiak wrote:
> In my experience, hiring Computer Science graduates into testing roles
> can work well.
I gasped at this, but then I began to realize that you meant that it
would work well /for them/, as a means of educating them about testing,
which the CS program typically would not do in North America.
>
> My experience is that analyzing who is (on average) best at finding the
> most bugs is a complex thing to determine, and quite frankly isn't
> always a terribly meaningful statistic. I've worked with incredibly
> experienced, certified testers who couldn't find a non-trivial bug if
> it bit them, let alone communicate it well.
This says more to me about the quality of certifications than it does
about anything else. A certified tester, in my observation, is one
that can demonstrate that he or she has passed a given certification
exam, but it tells me little nothing about their thinking skills, and
that's what I'm looking for when I'm evaluating testers.
---Michael B.
| |
| Paul Szymkowiak 2006-07-07, 10:00 pm |
| Michael Bolton wrote:
>
>
> I gasped at this, but then I began to realize that you meant that it
> would work well /for them/, as a means of educating them about testing,
> which the CS program typically would not do in North America.
In the short-term, yes it benefits the graduate. It can also help the
employer to integrate a new team member quickly, building team
communication and unity. In the longer-term, I think it benefits the
team and the organization as a whole.
My experience is that - as a generalization - CS graduates don't arrive
in an organization with a pragmatic grasp of the day-to-day challenges
and tradeoff's of real software development work (a failing not of
them, but of their education). As such, I think it is negligent of an
employer to simply hire a graduate into a job, without partnering,
pairing or otherwise providing suitable mentors to the graduate.
Under a mentoring program, I don't see why new grads can't experience
different aspects of software development: not simply "hard core"
coding. I've had good experiences with developers who started their
post-school careers as testers.
I'm not advocating that this approach will work for all organizations
and cultures, or for all individuals: in my view, its /an/ approach
that has both strengths and weaknesses - selecting this approach is a
brain-engaged, context-dependent choice.
Paul Szymkowiak
| |
|
| Hi
You can go to SQTL one of the best training institutes for testing.
They provide placement Assistance and also offer ISTQB,CSI
certification.
url://www.sqtl.com.
I have many friends already got job with the strong placements network
they have.
S/W testing is one line where freshers are welcomed.
muks
software testing wrote:
> hi I am prashant having starting knowlege of CCNA & MCP(but not geeting
> much experience), want to start carrer in software testing....can
> anyone guide me for this..
>
> what is the basic requirement of software field...I have completed BE
> in Electronics so not in touch of any language....
>
> Can I do this course so I can start my carrer in S/W company
| |
| software testing 2006-07-08, 4:01 am |
|
Hi Mukta..
Few days before I went to SQTL & SEED'S both....
Can U aske to ur friends, which will be better..Becz syllabus for
both is almost same & SQTL is conducting course for 20hrs.with
practicle but SEED'S conducting course for 40hrs.with practicle.
Tution fees for SEED'S is more than SQTL....in faculty & Testing
enviornment..practicle & projects ......& after all Placement..
Plz do the needfull...
| |
| automated_tester 2006-07-11, 4:07 am |
|
software testing wrote:
> Hi i m prashant ,
>
> I have started this topic...daily I am getting a new good things from
> you both (Jared & James Bond ).
>
> my basic problem is that I am from Networking field, want to start
> carrer in software testing ........Can I utilise my N/W knowledge in
> that? ...Can I handle or become a good Tester
>
> But what I got from our discussion is that, both are saying right (in
> both way)..depend upon your working exprience.
>
> soooooooooo
Hi Prashant,
Indeed Jared and James Bond are making some good points, but they are
focussing a bit to much on the technical side of testing for my taste.
Testing is more than telling programmers if their software works! There
is also the side of dealing with the end users, the client, the
specification specialists...When it all comes down to it, the
programmers don't pay the bills, the customer does. If he is not happy,
you're gone. Of course, by helping the programmers to write good code
you will make him happy!
If your background is networking, you will probably s a carier as a
technical tester, working in projects that require a high level of tech
knowledge to even understand your teammembers. In this role you should
be able to use your experience as an advantage. I did a project for an
isp some time ago (involviong digital TV and VOIP), where I really
wished I had more network knowledge, so use your strong points!
automated_tester
|
|
|
|
|