|
|
Johanna Rothman,
author of Hiring
Technical People
and numerous articles, is a well known
name in the world of testing. You can visit Johanna's
website at www.jrothman.com.
WhatIsTesting interviewed her
recently. We hope that this interview will be useful for
you. |
| Q1. Johanna, please tell us something about you,
your
background and experience. What are your interests and hobbies? |
I was
born in New Bedford Massachusetts. I graduated from the University
of Vermont in 1977 with a BA in English Literature and a BS in
Computer Science. I graduated from Boston University in 1985 with a
MS in Systems Engineering (Software Engineering concentration). I've
been working professionally in the software field since 1976 (I had
some part-time developer jobs before I graduated from college). I
was a developer (and small project manager) until 1985. I was a
tester from 1985-1988. I started managing large projects and people
in 1988. When I'm not working, I read voraciously, cook, and drive
my kids where they need to go :-) (I think the driving is an
American thing.) |
|
Q2. Your email signature reads "Speaker, Author, Consultant -Managing Product
Development."
What all do you
do? |
I speak
professionally at conferences and privately so that I can spread the
word :-) Seriously, I find that speaking is a large part of my
business. I can reach many people when I speak, so I seek out
conferences to explain my pragmatic approach to software project
management. I write (books, many articles, blogs) so that I can
explore the issues around software projects. Both speaking and
writing are one-to-many relationships. When I'm lucky, someone
writes back and I can develop a relationship with that person. I
consult when people want a one-on-one relationship with me. In my
consulting business, I perform assessments (not audits) to help
people understand what they really do and ways they can perform the
work better. I coach people and project managers, including
executives. I help projects start on track and stay on track. I
facilitate project retrospectives. I do anything that helps people
see where they've been, and help facilitate their choice about
whether to continue working like that. |
| Q3. What percentage of your total
"management" consulting time is spent in "managing testing"? Do you
specialize in testing management?
|
Every so
often, I take on interim management positions. About half the time
those positions have been VPs of Engineering, and the other half has
been some form of test/quality management. I don't specialize in any
one kind of management -- because of my experience, I'm well
qualified to perform either type of position. |
| Q4. What do you have to say about the
present state of test management in most
organizations?
|
I speak
and write for test managers as much as speak and write for project
managers. I find test management to be the hardest position in a
typical company. Too often, the position is underfunded,
understaffed, and the management position is staffed by people who
are ignorant of how testing can work to provide significant value to
the organizations. In many ways, it's easy to be a development
manager: no one says "let's just cut the development time in half"
and really expect the same result. They may cut development time,
but they realize they're not going to get the product they want. On
the other hand, too many senior management teams think nothing of
cutting the testing, and still assuming they will get a quality
product for their efforts. When I see this, I say, "Huh??" Test
managers need all the help they can get :-) |
|
Q5. What do you think
are the career paths that exist for the testing professionals, vis-à-vis both the
management and technical ladders?
|
I've
articulated four areas of technical skill (in my blog and in my
book): functional skills, domain expertise, tools/technology, and
industry expertise. The more a person gains functional skill and
domain expertise, the less limit there is to that person's career.
(I believe in dual ladders for technical and management staff.) Too
many testers stop growing their technical functional skills. Too
many testers are unable or uninterested in growing their domain
expertise. The more you learn about your craft and how to apply that
craft to the product, the more valuable you will be. In my
experience, I found that generalization I had as a tester was great
preparation for work as a project manager, program manager, and
eventually a people manager. |
| Q6. What should testing professionals do to prepare themselves
for these paths?
|
Read
about testing. Apply different test techniques to the product.
Organize the testing. Create a project dashboard. Learn the
internals of the product. Write code (if you have the technical
skills), so you understand what the developers are up against. Learn
how to facilitate project meetings. Negotiate the schedule. Keep
doing all of this, and you'll see if you want to be more technical
as a tester, more into project management, or more into people
management. |
| Q7. You are writing a book Hiring
Technical People
. What is this book about? What is the target
audience for this book?
|
The book
is about how to hire technical people, realizing that people are
much more than their technical skills. Too often, I've heard
managers say something like, "We need another developer with Java
and Unix experience." Well, that's great, but people vary greatly in
their approaches to their work, and just another Java programmer is
probably not what the hiring manager wants. I've applied how I
perform requirements to analyzing the job and writing a job
description. Then I explain about 20 different ways to find
candidates, how to sort through the resumes, how to ask questions
and what to listen for in the answers, how to make a job offer and
start a person out right in the job. I have appendices for specifics
about developers, project managers, testers, writers, tech support
staff and technical managers. The book is targeted to anyone who in
involved in hiring technical people, from hiring managers to people
who participate on the interview team. |
| Q8. When is the book going to be
available?
|
Dorset
House is publishing the book. I *think* it might be available in
January, but we may slip into February. |
| Q9. What is the main challenge in hiring good
technical people?
|
Creating
auditions is the hardest thing, because each audition is customized
for the particular environment. |
| Q10. What are chief qualities that one should keep in
mind for hiring technical people?
|
I find
the best technical people *for the projects I typically work on* are
adaptable. They see problems as issues to be solved not
insurmountable obstacles. Everyone needs to organize their work in
some fashion, although I'm not particular about how they organize
their work. I prefer people who have high initiative and take
responsibility for their work, so I know that they will take on all
the work they can and they know when the work will be complete.
|
| Q11. How does one train people to be good
interviewers?
|
Practice! Seriously, first people have to know how to
interview. They have to learn the difference between
behavior-description questions and hypothetical questions and closed
questions. They have to learn how to reframe the irrelevant
questions to learn what they are interested in about the candidate.
Then they need to practice. When I teach interviewing, I first
explain the different kinds of questions, and then have people
develop questions. Then I have them practice in groups of three, so
they have an observer to tell them what actually happened in the
interview. I find that the feedback step from observer to
interviewer is necessary for effective learning. |
| Q12. Testing sometimes entails endless hours of
repetitive regression testing. How do you keep the really good
testers motivated in such situations?
|
First, I
try hard to organize the testing so there isn't much repetition. (I
typically test from underneath the GUI as much as possible.) That
tells the testers that you care about not having them perform work
that a computer could do better and faster. When I'm involved with
agile projects, I find it easier to test from scenarios and avoid
most of the repetition (and on agile projects, it's much easier to
develop automation). |
| Q13. What are the three top skills a testing manager
should acquire or hone to become a really successful
manager? |
First, make sure you like dealing with
people. Test managers deal with people all across the organization.
Second, develop your influencing and negotiation skills. Third,
learn how to organize and report on the testing so your executives
understand the value of your testing to the organization. Hmm, that
may be more than three :-) |
| Q14.
You have written extensively on project retrospectives. Would you
like to share some of the key points? |
If you don't perform project
retrospectives, you don't increase the value of your work to your
organization. If you don't continually increase the value of your
work, you are destined to become a commodity, or worse, irrelevant.
One more thing: about projects: There is no one right way to
organize a project. You choose a lifecycle, the practices (process)
for each project based on who all your customers are and what they
need. |
| If you were your own interviewer what questions would
you like to ask yourself? |
They
are: |
| 1.
What's the most important action to take for project success?
|
Make sure the project manager understands how to
manage a project like this one. If the project manager doesn't have
experience with this kind of a project, the project manager will
need time to make some mistakes. |
| 2. What one technique is most valuable in software
projects?
|
Estimating the work to be done. If we
under-estimate, we're stuck trying to meet impossible dates. If we
over-estimate, our project doesn't appear to have enough
value. |
