Interview questings to identify good technical testers
DLW
welcome suggestions and help on questions that would identify the good
technical tester in a multi-platform environment running transaction
processing applications across desktop, middleware, mainframe.
Thanks in advance.
DLW
Paul Henry
Please Please Please don't ask "What is String Testing?" as I got asked
once! Be aware that there are different names for the same technique, and
hundreds of techniques, so even though you may think every good tester
should know what X-testing is, maybe they have never heard of it, or know it
by a different name.
Some suggestions:
Take them gently though their work history, asking "what systems did you
test? what bugs did you find?". Remember you are looking for the best person
for your organisation, not the best interviewee! You may have to put a
little effort into it to bring out the best candidate, so give plenty of
time to get to know the person - 5 or 10 minutes is a waste of time.
Give them a piece of code/spec and ask what kind of test cases they would
write for it.
Ask them what kind of bugs they would look for in a given system, e.g. in a
transaction processing you would look for locking, race conditions,
performance, recovery (backup) problems etc. Multi-platform you would want
installation, upgrade tests?
If they don't have the full skillset, how flexible are they at learning new
skills, new OSs etc. e.g. If they have used Unix, have they done shell
scripting? If DOS, have they developed batch files? Have they picked up
languages at their past places, e.g. C, Perl, SQL, whatever? What I'm
getting at here is, do they have the ability and the inclination to learn
new stuff in medium depth.
Do they know how to program? This is not necessary for a good tester, but
for a "technical tester" you might want them to read code? BTW, just because
they don't have a particular language doesn't mean a person can't read that
language....except APL! (LOL!) A programmer might understand and look for
certain problems that maybe a non-programmer won't, e.g. memory leaks,
unmaintainable code, unmaintainable design.
Oh, here's one that I use when asking employers questions: "Is there any
question you think I should have asked?" :)
Eamonn J. Casey
business experience - 20 people in product development):
This is my own opinion, but, I have made a test and release group from
nothing to a group with QA style responsibility, the ability to hire and
schedule multiple products releases - within 18 months!!! So these
qualities count for something:
1. No Fear - Testing usually stops development, rollout etc. and causes
all sorts of money and contract issues. At any given point in time the
test engineer assigned to the project is one of the more junior members.
You cannot be afraid to say "Hey, I can give you a bad product now that
you will struggle with - or wait a few weeks and I can give you
something that you actually want!"
2. Personality - "Personality goes a long way" (Pulp Fiction"). You test
engineer will be trying to coordinate alot of different skill sets
(business requirements, development gurus (& egos), programmers,
management etc.). When shit hits the fan, you want a cool head so all of
these other guys will be drawn to the test engineer and look for
guidance.
3. Programming Experience - Good testers are programmers who are tired
of making the same old crap and want to make better software. They move
out from the classical hack-and-fix-later project life-cycle into the
software-development-for-a-better-world. Ok, egos with a chip on their
shoulders! If you have programming experience you can speak to the
programmers on their own level and they will accept you - last thing you
want is a 'technical writer' that is telling you 'maybe you need a safe
array pointer instead of releasing it in seperate places manually'.
4. Win-Win Attitude - The problem with most defects is that they are
presented in a negative light. This puts you as the tester as the
'winner' and the rest of the company as the 'loser'. This is part of
personality (2) but it is such a big part when you are negotiating what
to do i.e. 'We can still release now (as Sales requires) but you
(Developers) must fix this as the first thing in the next release'.
5. Blind Optimisim - This speaks for itself !
Eamonn J.
chr...@my-deja.com
In article <8qb33q$j9o$1...@epos.tesco.net>,
"DLW" <art...@tesco.net> wrote:
> I am interviewing for technical testers (non-functional testing). I
would
> welcome suggestions and help on questions that would identify the good
> technical tester in a multi-platform environment running transaction
> processing applications across desktop, middleware, mainframe.
>
> Thanks in advance.
>
> DLW
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.