Home > Archive > Software Testing > September 2006 > job market for 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]
| Author |
job market for testing?
|
|
| ankit 2006-09-16, 10:05 pm |
| hello,
can any one tell me current job market for testing field in USA.
and also future of testing field.
Regards,
Raj
| |
| Phlip 2006-09-16, 10:05 pm |
| ankit wrote:
> can any one tell me current job market for testing field in USA.
Hit: http://sandiego.craigslist.org/sof/
Note a third of the listings have Test or QA in their name.
> and also future of testing field.
All programs need professional testing. The days of throwing the programmers
to your customers and letting them test it are over. But not many companies
know that! The field can only expand...
--
Phlip
[url]http://www.greencheese.us/Z Land[/url] <-- NOT a blog!!!
| |
| Phlip 2006-09-16, 10:05 pm |
| > All programs need professional testing. The days of throwing the
> programmers to your customers and letting them test it are over.
The days of throwing your PROGRAMS to your customers are over.
The days of throwing your programMERs is just beginning!
;-)
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| erkan77@gmail.com 2006-09-17, 8:13 am |
| Hi Phlip,
I agree to that:
"All programs need professional testing. The days of throwing the
programs to your customers and letting them test it are over."
It is actually good, that people realize this
(please remember: there are five levels of testing maturity, see
Beizer, Burnstein or Gelperin + Hetzel.
And this knowledge exists since a long time)
But why do you say,
"The days of throwing your programMERs is just beginning!"
question here is:
when there is someone fired, then there was made a mistake earlier:
e.g.
right at the beginning when hiring the wrong person
or not communicating clearly the goals to the developer in daily-work
or generating too much load for the developer
Then the question could be:
why not fire the one, who hired the programmer? :-)
or the one NOT telling/insisting on the project-priorities
Let's say we forget this above for a moment:
imagine:
Wouldn't it be better, to introduce/teach/help the programmer more
(into/with) testing skills/techniques?
So, everyone would profit and there would be more quality (ok, what
quality now is, is another subject :-) ).
e.g.
in project-meetings let the developer speak in terms of risk with the
help of (test-)metrics
and I bet management will listen to this
(please remember: the sooner the fault is fixed, the less money ...)
Most of the problems actually are due to limitations not all people can
influence (time, money, market-chance, ...).
Erkan YILMAZ
| |
|
| erkan77 wrote:
> But why do you say,
> "The days of throwing your programMERs is just beginning!"
>
> question here is:
> when there is someone fired, then there was made a mistake earlier:
> e.g.
> right at the beginning when hiring the wrong person
> or not communicating clearly the goals to the developer in daily-work
> or generating too much load for the developer
You missed the inference. I wrote an abridged version of, "The days of
throwing your programmers to your customers are just beginning."
> Then the question could be:
> why not fire the one, who hired the programmer? :-)
> or the one NOT telling/insisting on the project-priorities
I have had plenty of bosses who forbade me to interact in any way with their
customer contacts. They wanted to control the message, and not risk me
blabbing about all our bugs.
This was while I was fixing bugs the customer reported, in the order my boss
told me to. Me interacting with the customer would have made him feel more
in control. I could have fixed _less_ bugs, and he would have felt I was
_more_ responsive. If I fix the bugs he considered important.
> imagine:
> Wouldn't it be better, to introduce/teach/help the programmer more
> (into/with) testing skills/techniques?
> So, everyone would profit and there would be more quality (ok, what
> quality now is, is another subject :-) ).
Imagine if developers wrote test cases _before_ they wrote lines of code.
> e.g.
> in project-meetings let the developer speak in terms of risk with the
> help of (test-)metrics
> and I bet management will listen to this
> (please remember: the sooner the fault is fixed, the less money ...)
The team should collect metrics, and testers should lead that effort. The
metrics should be available at meetings. I prefer a chart on the wall. At
another job, I used to announce this chart with, "In today's weather", and
give a report on its twitches, like a weatherman. "This dip here came after
the big party we had..."
> Most of the problems actually are due to limitations not all people can
> influence (time, money, market-chance, ...).
I would prefer that the team keep quality as high as possible at all times,
and the only part to vary should be the scope. This is why a customer
liaison is critical - to remove low-priority features from the feature list.
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| erkan77@gmail.com 2006-09-17, 7:04 pm |
| Hi Phlip,
ok, everything clear now.
as you also point out: a company doing this would not survive on
long-term.
As Copeland says:
"The corporate landscape is strewn with the sun-bleached bones of
organizations who have used this testing approach."
With the testing aproach he references: "test whatever you test; let
the users test the rest."
>I have had plenty of bosses who forbade me to interact in any way with their
>customer contacts. They wanted to control the message, and not risk me
>blabbing about all our bugs.
ah yes, I know this feeling.
We testers normally tend to speak about the naked truth - no matter
what: a bug is a bug
in the end a customer will find bugs
and who else - if not we testers - find the bug,
we are the last wall, we must fight until the end
if we do not find, the customer surely will.
yes, management generally tends to transform issues,
e.g. a bug is a feature :-)
[color=darkred]
> Imagine if developers wrote test cases _before_ they wrote lines of code.
very good point: like in test-driven-development.
Actually this is the best what a tester could wish for:
due to prewritten + reusable tests, not searching for bugs, which were
closed already some time ago and now appear
again (I hope not because some versioning-system had a prob. :-) )
or that each function can handle really the specified input with the
expected behaviour AND also not-specified inputs
should be handled appropriate.
then testers could have time for (more) better tests
yes, I agree, the quality should shift more early in the process:
not the QA should be responsible, everybody should be
to continue with the "imagination":
I have a dream, in 100 years companies will never release software
without proper testing,
because then they really would get punished for their products by
someone.
Like Beizer tells: "testing less than this [100% statement coverage]
for new software is unconscionable and should be criminalized. ... In
case I haven't made myself clear, ... untested code in a system is
stupid, shortsighted, and irresponsible."
so, who can this someone be, besides the customer or state?
[color=darkred]
>The team should collect metrics, and testers should lead that effort. The
>metrics should be available at meetings. I prefer a chart on the wall. At
>another job, I used to announce this chart with, "In today's weather", and
>give a report on its twitches, like a weatherman. "This dip here came after
>the big party we had..."
nice idea with the weather-analogy.
yes, pointing directly to the problem after an event may solve many
things.
but why let the team do this collecting? set up a programm, which
automatically collects and displays,
then we all can do something else :-)
What I notice is, that people tend to forget why the quality is bad or
project is late ...
because they do not remember what happened during the long path
(or do they want to remember? "What you don't know won't hurt you.")
This would be the bell for the conscience
how about this simple metric:
ask in the team, if person X can have vacation.
Then from the reactions you can know, how the status of the project is.
[color=darkred]
>I would prefer that the team keep quality as high as possible at all times,
>and the only part to vary should be the scope. This is why a customer
>liaison is critical - to remove low-priority features from the feature list.
good idea and I believe everybody wants to deliver quality
I suspect no one wanting to make bad things with purpose (except some
masochist or suicide:-) )
but sometimes, somehow something gets worse
and sooner or later we are all going to die :-)
CU,
Erkan
| |
|
| erkan77 wrote:
> As Copeland says:
> "The corporate landscape is strewn with the sun-bleached bones of
> organizations who have used this testing approach."
> With the testing aproach he references: "test whatever you test; let
> the users test the rest."
The company I cryptically cited is still alive and kicking. All their
competition made bigger mistakes.
;-)
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| Michael Bolton 2006-09-18, 10:06 pm |
| > to continue with the "imagination":
> I have a dream, in 100 years companies will never release software
> without proper testing,
> because then they really would get punished for their products by
> someone.
> Like Beizer tells: "testing less than this [100% statement coverage]
> for new software is unconscionable and should be criminalized. ... In
> case I haven't made myself clear, ... untested code in a system is
> stupid, shortsighted, and irresponsible."
....and inevitable.
Have you tested all of the libraries with which your program interacts?
All of the operating system calls that it executes? All of the
platforms on which it runs? Is it possible that Boris was talking
about a testing environment that was specific to his context
(high-reliability telecom switches, 20 years ago) and not to the vastly
more complex (and creaky) operating environments that we're dealing
with today?
Have you achieved 100% statement coverage in your testing? How do you
know?
> nice idea with the weather-analogy.
> yes, pointing directly to the problem after an event may solve many
> things.
> but why let the team do this collecting? set up a programm, which
> automatically collects and displays,
> then we all can do something else :-)
One answer might be that programs are terrible at observations of human
behaviour, which is what Phlip was promoting (and in my view, he's
spot-on).
---Michael B.
| |
| Phlip 2006-09-18, 10:06 pm |
| Michael Bolton wrote:
>
> ...and inevitable.
>
> Have you tested all of the libraries with which your program interacts?
Q: Can we achieve World Peace?
A: Nope.
Rebuttal: That's completely irrelevant to whether we should try.
Each step between here and the goal is itself also a Good Thing.
And the current situation has _much_ room for improvement!
> One answer might be that programs are terrible at observations of human
> behaviour, which is what Phlip was promoting (and in my view, he's
> spot-on).
Not sure if I understand the polarity there, but I don't recall thinking it,
so if it appeared between us, great!
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| erkan77@gmail.com 2006-09-18, 10:06 pm |
| Hi Michael + Phlip,
[color=darkred]
>...and inevitable.
>Have you tested all of the libraries with which your program interacts?
> All of the operating system calls that it executes? All of the
>platforms on which it runs?
Give me infinite time, then all can be done.
So the answer is obvious: this is never possible completely - even with
normal projects, because there are other
limitations which can happen anytime.
So only thing which can be done is: starting with the high-priority
testcases, so that when stopping the test,
the best-possible was tested/achieved.
Or didnt you start in the morning with position A and in the evening
you were completely different direction ? :-)
>Have you achieved 100% statement coverage in your testing? How do you
>know?
We can't know of course.
How about if the control flow does not include all paths, cause the
instrumentation tool may be defect - it is just also a software.
Without reviews we would not know.
So, again same answer as above.
And who says that statement coverage is enough? why not uising the
better coverages?
[color=darkred]
>One answer might be that programs are terrible at observations of human
>behaviour, which is what Phlip was promoting (and in my view, he's
>spot-on).
>Not sure if I understand the polarity there, but I don't recall thinking it,
>so if it appeared between us, great!
:-) that is telepathic :-)
true, but automated collected metrics can indicate some problem-areas
and of course we humans must judge this.
Or would you solely test without exploratory testing in a project?
So the human factor always plays a role (in finding bugs/and creating
also).
>Q: Can we achieve World Peace?
>
>A: Nope.
>
>Rebuttal: That's completely irrelevant to whether we should try.
> Each step between here and the goal is itself also a Good Thing.
> And the current situation has _much_ room for improvement!
indeed
Erkan
| |
| Michael Bolton 2006-09-19, 8:10 am |
| > >> Boris Beizer: ... untested code in a system is stupid, shortsighted, and irresponsible."
Michael: > > ...and inevitable.
Michael: > > Have you tested all of the libraries with which your
program interacts?[color=darkred]
>
> Q: Can we achieve World Peace?
>
> A: Nope.
>
> Rebuttal: That's completely irrelevant to whether we should try.
> Each step between here and the goal is itself also a Good Thing.
> And the current situation has _much_ room for improvement!
Actually, my point was that Beizer's statement is simply fatuous, and
that it's unseemly (albeit typical in his writing, alas) to harangue
people for not achieving the impossible. (And in fact, if we are going
to busy ourselves with impossible things, world peace is probably
closer to being achievable, and more worthwhile.)
Far better, I think, to recognize the inevitability of untested code,
but to change our thinking about it. We can leave code untested
/compulsively/ by maintaining narrow models and inadequate coverage, or
we can leave code untested /consciously/ by extending our models,
improving our coverage, and focusing on what's achievable and what
matters to people.
---Michael B.
| |
| erkan77@gmail.com 2006-09-23, 8:05 am |
| Hi all,
I am back again.
>Actually, my point was that Beizer's statement is simply fatuous, and
>that it's unseemly (albeit typical in his writing, alas) to harangue
>people for not achieving the impossible. (And in fact, if we are going
>to busy ourselves with impossible things, world peace is probably
>closer to being achievable, and more worthwhile.)
>Far better, I think, to recognize the inevitability of untested code,
>but to change our thinking about it. We can leave code untested
>/compulsively/ by maintaining narrow models and inadequate coverage, or
>we can leave code untested /consciously/ by extending our models,
>improving our coverage, and focusing on what's achievable and what
>matters to people.
of course you are right with the impossibility of testing everything,
but I mentioned it in category "imagination". Who says, that in 100
years there is not better hardware, software or even improved versions
of humans (testers)? Imagine, if you can do path testing with a tool in
1 day :-)
and of course it is so, that not all faults lead to errors:
for example E. Adams examined data of 9 OS-software products. And he
found out, that only "... a small number of faults (less than 2%)
caused the most common failures, namely those occuring at least once
every 5 years of use. In other words, a very small proportion of the
faults in a system can lead to most of the observed failures in a given
period of time." van Veenendaal, 2005
So, it is always a risk-based decision, what to test and what not. Like
you say it depends on what matters to people.
And with that info at that special time, we trust in the decisions we
make.
And then we can sleep well (at least for a certain period of time :-)
).
Erkan
|
|
|
|
|