SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
Lynd Seagull did in the book
Jonathan Livingston Seagull
by Richard Bach. I was doing
things that helped other good
birds wanting to fly like me,
take the step forward.
Only courageous birds could
take the leap of faith. In
December 2010, we began a
flight journey together that has
redefined our present and shall
redefine the industry’s future.
Welcome to reading
stories of tests that were never
before documented. I wish I
could play for you the appro-
priate soft background music
while you read them. It would
just make the experience better.
I trust your brains are capable
of introducing background mu-
sic or you can pull out a mobile
device and play something to
enhance the experience.
Test of the Vision
Moolya was a garage start-up.
We didn’t do a garage venture
just because every other one
we had heard of became suc-
cessful. Our budget was small
or should I say we hardly had
any money to call it a budget.
So the garage came looking
our way. We needed more than
just office space though. We
needed birds that could fly and
inspire the world. I decided to
hire an exceptional flock of
Continued on page 5
By Paul Gerrard
Testing is Long Overdue for a Change
Rumours of the death of testing
were greatly exaggerated, but even
so, the changes we predict will be
dramatic. My own company has been
heralding the demise of the ‘plain old
functional tester’ (POFT) for years
and we’ve predicted both good and
bad outcomes of the technological
and economic change that is going on
right now. Some time ago, I posted a
blog, ‘Testing is in a Mess’1
suggested that there’s complacency,
self-delusion and over capacity in
the testing business; there is too little
agreement about what testing is, what
it’s for or how it should be done.
But there are also some
significant forces at play in the
IT industry and I think the testing
community, will be coming under
extreme pressure. I summarise this
change as ‘redistributed testing’: users,
analysts, developers and testers will
redistribute responsibility for testing
by, wait for it, collaborating more
effectively. Testers probably won’t drive
this transition, and they may be caught
out if they ignore the winds of change.
In this article, I’ll suggest what
we need from the leaders in our
Continued on page 2
ALSO IN THE NEWS
“A tester is someone
who knows things can
be different” ...
Continued on page 11
How are your leadership skills?
Will the Test Leaders Stand Up?
March 2013 | www.thetestingplanet.com | No: 10
The Leadership Survey results have been given the infographic treatment - see pages 16-17
By Pradeep Soundararajan
Over the last two years, the
education forced upon me is
leadership, especially when
I thought I knew what it was
meant to be. I was in for
some tests. After becoming an
independent test consultant in
2006, I did a bunch of things.
I flew the way I wanted to
and also flew away from bad
birds, just like how Fletcher
The most important
piece of advice I give
Continued on page 21
Some people want to
know how to be a good
or even a great leader...
Continued on page 19
When I read Sun Tzu’s
The Art of War, I tend to
relate it to testing...
Continued on page 18
Testing must change if it is to survive in the 21st Century
2 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
Main story continued from page 1
industry, the market and our organisations. Of
course, some responsibility will fall on your
shoulders. Whether you are a manager or technical
specialist, there will be an opportunity for you to
lead the change.
New Architectures, new Approaches
Much of the software development activity in the
next five years or so will be driven by the need for
system users and service vendors to move to new
business models based on new architectures. One
reason SaaS is attractive is that the route to market
is so simple that tiny boutique software shops can
compete on the same playing field as the huge
independent software vendors.
SaaS works as an enabler for very rapid
deployment of new functionality and deployment
onto a range of devices. A bright idea in
marketing in the morning can be deployed as new
functionality in the afternoon and an increasing
number of companies are succeeding with
‘continuous delivery’. This is the promise of SaaS.
Most organisations will have to come
to terms with the new architectures and a more
streamlined approach to development. The push
and pull of these forces will make you rethink how
software available through the Internet is created,
delivered and managed. The impacts on testing are
significant. If you take an optimistic view, testing
and the role of testers can perhaps, at last, mature to
what they should be.
The Testing Business has Matured, but Bloated
Over the last twenty years or so there has been a
dramatic growth in the number of people who test
and call themselves testers and test managers. It’s
not that more testing happens. I think it’s because
the people who do it are now recruited into teams,
having managers who plan, resource and control
sizable budgets in software projects to perform
project test stages. There is no question that people
are much more willing to call themselves a tester.
There are now a huge number of career testers
across the globe; many have done nothing but
testing in their professional lives. The problem is
that there may now be too many of them.
In many ways, in promoting the testing
discipline as some of us have done for more
than twenty years, we have been too successful.
There is now a sizable testing industry. We have
certification schemes, but the schemes that were a
step forwards fifteen years ago, haven’t advanced.
As a consequence, there are many thousands of
professional testers, certified only to a foundation
level who have not developed their skills much
beyond test script writing, execution and incident
logging. Much of what these people do are basically
‘checking’ as Michael Bolton has called it.
Most checking could be automated and
some could be avoided. In the meantime, we have
seen (at last) developer testing begin to improve
through their adoption of test-driven and behaviour-
driven approaches. Of course, most of the testing
they do is checking at a unit level. But this is
similar to what many POFTs spend much of their
time doing manually. Given that most companies
are looking to save money, it’s easy to see why
many organisations see an opportunity to reduce
the number of POFTs if they get their developers
to incorporate automated checking into their work
through TDD and BDD approaches.
As the developers have adopted the
disciplines and (mostly free) tools of TDD and
BDD, the testers have not advanced so far. I would
say, that test innovation tends to be focused on the
testers’ struggle to keep pace with new technologies
rather than insights and inventions that move the
testers’ discipline forward. Most testing is still
manual, and the automated tests created by test
teams (usually with expensive, proprietary tools)
might be better done by developers anyway.
In the test management space, one can
argue that test management is a non-discipline, that
is, there is no such thing as test management, there’s
just management. If you take the management
away from test management – what’s left? Mostly
challenges in test logistics – or just logistics – and
that’s just another management discipline isn’t it?
What about the fantastic advances in
automation? Well, test execution robots are still,
well, just robots. The advances in these have
tracked the technologies used to build and deliver
functionality – but pretty much that’s all. Today’s
patterns of test automation are pretty much the
same as those used twenty or more years ago. Free
test automation frameworks are becoming more
commonly used, especially for unit testing. Free
BDD tools have emerged in the last few years, and
these are still developer focused but expect them to
mature in the next few years. Tools to perform end-
to-end functional tests are still mostly proprietary,
expensive and difficult to succeed with.
The test management tools that are out
there are sophisticated, but they perform only
the most basic record keeping. Most people still
use Excel and survive without test management
products that only support the clerical test activities
and logistics and do little to support the intellectual
effort of testers.
The test certification schemes have gone
global. As Dorothy Graham says on her blog2
Foundation met its main objective of “removing the
bottom layer of ignorance” about software testing.
Fifteen years and 150,000+ certificate awards later,
it does no more than that. For many people, it
seems that this ‘bottom layer of knowledge’ is all
they may ever need to get a job in the industry. The
industry has been dumbed-down.
Agile: a Stepping Stone to Continuous Delivery
There is an on-going methodological shift from
staged, structured projects to iterative and Agile
and now, towards ‘continuous delivery’. Just as
companies seem to be coming to terms with Agile
– it’s all going to change again. They are now being
invited to consider continuous ‘Specification by
Example’ approaches. Specification by example
promotes a continual process of specification,
exampling, test-first, and continuous integration.
Continued on page 3
Letter from the Editor
It’s hard to lead a cavalry charge if you think you look funny on a horse. - Adlai Stevenson
3Follow us at www.twitter.com/testingclub
The leadership instinct you are born with is the backbone. You develop the funny bone and the wishbone that go with it. -
Continued from page 2
CI and Delivery is the heartbeat, the test, life-
support and early warning system. The demands
for better testing in development are being met.
A growing number of developers have known
no other way. If this trend continues, we will get
better, stable software sooner and much of the late
functional checking done by system testers may
not be required. Will this reduce the need for POFT
testers? You bet.
But, continuous delivery is a machine that
consumes requirements. For the rapid output of
continuous delivery to be acceptable, the quality of
requirement going into that machine must be very
high. We argue that requirements must be trusted,
but not perfect.
Testers are Being Squeezed
Developers are increasingly taking on the
automated checking. Some business analysts
are taking their chance and absorbing critical
disciplines into analysis and are taking over the
acceptance process too. Combined, the forces above
are squeezing testers from the ‘low-value’ unskilled,
downstream role. To survive, testers will have to
up-skill to upstream, business-savvy, workflow-
oriented, UX-aware testing specialists with new
tools or specialise in automation, technical testing
or become business domain experts.
So how do Testers take Advantage
I set out my top 10 predictions for the next five
years in my blog “On the Redistribution of
and I won’t labour those points here.
Rather, I’ll explore some leadership issues that arise
from the pressures I mentioned above and potential
shifts in the software development and more
particularly, testing business.
The core of the redistribution idea is
that the checking that occupies much of the time
of testing teams (who usually get involved late
in projects) can be better done by developers.
Relieving the testers of this burden gives them time
to get involved earlier and to improve the definition
of software before it is built. Our proposal is that
testers apply their critical skills to the creation of
examples that illustrate the behaviour of software
in use in the requirements phase. Examples
(we use the term business stories) provide
feedback to stakeholders and business analysts to
validate business rules defined in requirements.
The outcome of this is what we call trusted
In the Business Story Pocketbook4
define a trusted requirement as “… one that, at
this moment in time, is believed to accurately
represent the users’ need and is sufficiently detailed
to be developed and tested.” Trusted requirements
are specified collaboratively with stakeholders,
business analysts, developers and testers involved.
Developers, on receipt of validated
requirements and business stories can use the
stories to drive their TDD approach. Some (if
not all) of these automated checks form the bulk
of regression tests that are implemented in a
Continuous Integration regime. These checks
can then be trusted to signal a broken build. As
software evolves, requirements change; stories
and automated checks change too. This approach,
sometimes-called Specification by Example
depends on accurate specifications (enforced by test
automation) for the lifetime of the software product.
Later (and fewer) system testers have reduced time
to focus on the more subtle types of problem, end to
end and user experience testing.
The deal is this: testers get involved earlier
to create scenarios that validate requirements,
and that developers can automate. Improving the
quality of requirements means the target is more
stable, developers produce better code, protected
by regression tests. Test teams, relieved of much
of the checking and re-testing are smaller and can
concentrate on the more subtle aspects of testing.
With regards to the late testing in
continuously delivering environments, testers are
required to perform some form of ‘health check’
prior to deployment, but the days of teams spending
weeks to do this are diminishing fast. We need
fewer, much smarter testers working up-front and in
the short time between deployment and release.
Where are the Opportunities?
The software development and Agile thought
leaders are very forcefully arguing for continuous
delivery, collaborative specification, better
development practices (TDD, BDD), continuous
integration, and testing in production using A/B
testing, dark releases and analytics and big data.
The stampede towards mobile computing continues
apace and for organisations that have a web
presence, the strategy is becoming clearer.
The pace of technical change is so high that
the old way of testing just won’t cut it. Some teams
are discovering they can deliver without testers at
all. The challenge of testing is perceived (rightly or
wrongly) to be one of speed and cost (even though
it’s more subtle than that of course). Testers aren’t
being asked to address this challenge because
it seems more prone to a technical solution and
POFTs are not technical.
But the opportunities are there: to get
involved earlier in the requirements phase; to
support developers in their testing and automation;
to refocus testing away from manual checking
towards exploratory testing; to report progress and
achievement against business goals and risks, rather
than test cases and bug reports.
Testers Need a New Mindset; so do Vendors
We need the testing thought-leaders to step up and
describe how testing, if it truly is an information
provision service, helps stakeholders and business
analysts to create trusted requirements, support
developers in creating meaningful, automatable,
functional tests. And to be there at the end to
perform the testing (in production, or production-
like environments) to ensure there are no subtle
flaws in the delivered system.
Some of the clichés of testing need to be
swept away. The old thinking is no longer relevant
and may be career limiting. To change will take
some courage, persistence and leadership.
Developers write code; testers test
because developers can’t: this mentality has got to
go. Testing can no longer be thought of as distinct
from development. The vast majority of checking
can be implemented and managed by development.
One potential role of a tester is to create functional
tests for developers to implement. The developers,
being fluent in test automation, implement lower
level functional and structural tests using the same
test automation. Where developers need coaching
in test design, then testers should be prepared to
Testers don’t own testing: testing is part
of everyone’s job from stakeholder, to users, to
business analysts, developers and operations staff.
The role of a tester could be that of ‘Testmaster’. A
testmaster provides assurance that testing is done
well through test strategy, coaching, mentoring and
where appropriate, audit and review.
Testing doesn’t just apply to existing
software, at the end: testing is an information
provision service. Test activity and design is driven
by a project’s need to measure achievement, to
explore the capabilities, strengths and weaknesses
so decisions can be made. The discipline of test
applies to all artefacts of a project, from business
plans, goals, risks, requirements and design. We
coined the term ‘Project Intelligence’ some years
ago to identify the information testers provide.
Testing is about measuring achievement,
rather than quality: Testing has much more to
say to stakeholders when its output describes
achievement against some meaningful goal, than
alignment to a fallible, out of date, untrusted
document. The Agile community have learnt that
demonstrating value is much more powerful than
reporting test pass/fails. They haven’t figured how
Continued on page 4
AUTHOR PROFILE - PAUL GERRARD
4 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
Continued from page 3
to do it of course, but the pressure to align Agile
projects with business goals and risks is very pro-
Whither the Test Manager?
You are test manager or a test lead now. Where will
you be in five years? In six months? It seems to me
there are five broad choices for you to take (other
than getting out of testing and IT altogether).
1. Providing testing and assurance skills to
business: moving up the food chain towards
your stakeholders, your role could be to provide
advice to business leaders wishing to take
control of their IT projects. As an independent
agent, you understand business concerns and
communicate them to projects. You advise
and cajole project leadership, review their
performance and achievement and interpret
outputs and advise your stakeholders.
2. Managing Requirements knowledge: In this
role, you take control of the knowledge required
to define and build systems. Your critical skills
demand clarity and precision in requirements
and the examples that illustrate features in use.
You help business and developers to decide
when requirements can be trusted to the degree
that software can reasonably be built and tested.
You manage the requirements and glossary
and dictionary of usage of business concepts
and data items. You provide a business impact
3. Testmaster – Providing an assurance function
to teams, projects and stakeholders: A similar
role to 1 above – but for more Agile-oriented
environments. You are a specialist test and
assurance practitioner that keeps Agile
projects honest. You work closely with on-
site customers and product owners. You help
projects to recognise and react to risk, coach
and mentor the team and manage their testing
activities and maybe do some testing yourself.
4. Managing the information flow to/from the
CI process: in a Specification by Example
environment, if requirements are validated
with business stories and these stories are used
directly to generate automated tests which are
run on a CI environment, the information flows
between analysts, developers, testers and the CI
system is critical. You define and oversee the
processes used to manage the information flow
between these key groups and the CI system
that provides the control mechanism for change,
testing and delivery.
5. Managing outsourced/offshore teams: In this
case, you relinquish your onsite test team and
manage the transfer of work to an outsourced
or offshore supplier. You are expert in the
management of information flow to/from your
software and testing suppliers. You manage
the relationship with the outsourced test team,
monitor their performance and assure the
outputs and analyses from them.
The recent history and the current state of the
testing business, the pressures that drive the
testers out of testing and the pull of testing into
development and analysis will force a dramatic re-
distribution of test activity in some or perhaps most
Henry Kissinger said, “A leader does not
deserve the name unless he is willing occasionally
to stand alone”. You might have to stand alone
for a while to get your view across. Dwight D
Eisenhower gave this definition: “Leadership is the
art of getting someone else to do something you
want done because he wants to do it”.
Getting that someone else to want to do it
might yet be your biggest challenge. □
AND MORE ELEGANT
TEST MANAGEMENT TOOL
5 EASY FREE
TO USE TO TRY
TO SET UP
5Follow us at www.twitter.com/testingclub
Leadership is the art of getting someone else to do something you want done because he wants to do it. -Dwight Eisenhower
Second story continued from page 1
testers including Dhansekar Subramaniam, Parima-
la Hariprasad, Sunil Kumar T and Santhosh Tuppad
to start with.
The first reaction James Bach had when
I told him I hired DS and Parimala was, “Really?
How could you afford their pay checks?” Why can’t
I? They came for the pleasure of flying and not for
the money. They do need to run a family but they
believed in my leadership and believed that I could
start paying them before their savings are depleted.
If my mission is to create a flight journey for all birds
who want to fly, fly together, I need to take care of
the logistics. The primary logistics here is – money.
DS was a part of our second testing project.
He came to me one day and said something like,
“We claim we won’t do scripted testing but I guess
on this project we are slowly leaning towards it.
Our customer is failing to understand the value of
exploratory testing and I thought I could get rid of
the scripted approach when I came over to Moolya”
This project was earning us money to
take care of our operation costs and give us a little
cushion to do a bunch of other things. So, should I
say to our customer, “we can go hungry but not do
this kind of testing!” or behave the way I have seen
(and cursed) other people do and surrender to the
customers’ expectations over our vision.
I bought time from DS to fix the problem. I
was officially a consultant to this project, so I tried
helping our customer understand why we are less
valuable to them if we were to operate on scripted
testing mode but sadly they failed to understand
the value of our proposition. Maybe I failed to help
them see the value. One of our reasons for failure
was because we did a stupendous job that made
them want cool work to first be repeatable before
doing new things.
I motivated DS and our other colleague to
keep re-iterating the point that we can be of more
value. Somehow, repeatability of our superb work
stood in front of anything else. I could sense that
DS and his colleague had lost motivation. I can sac-
rifice money but not kill the motivation of a highly
capable bird that wants to fly. So we stopped work-
ing on that project. DS came out of the project. He
knew this meant loss of revenue for the company.
However, this helped regain his confidence on me
as a leader and how serious I am about the vision.
What happened after that is a great story.
This bird setup the mobile testing division in
Moolya and came with some awesome work on
COP FLUNG GUN1
mnemonic for mobile app
testing. We now have top customers for our mo-
bile division, a great team of highly skilled mobile
app testers and revenue multiple times of what we
would have earned from that other project, flowing
in from the mobile app testing business.
As of today, Dhanasekar is Commander
– Mobile for Moolya. He is a respected leader in
Moolya and even outside of it. Our mutual respect
has risen to great heights ever since.
Test of Money
Money tests people. I actually had passed through
the money tests during my independent consulting
days. There were months I made a lot of money and
there were months that were dry. There were mo-
ments where my wife spent without having to ask
if I was okay with it and there were months where
she knew my answer if she did ask. I am very bad
at saving money. I have a bad reputation when it
comes to saving money within my family.
However, after Moolya and the first year
and two months – I borrowed as much as I could
from my brother and my father. They helped me run
my family. My wife supported me very well.
Here is an interesting thing – Moolya had
money and I could have afforded for myself a pay
check that could help me run my family without
having to borrow but I looked at people who came
to me trusting that I can help them grow by fuel-
ling Moolya’s growth. The more money I could let
Moolya have, the better decisions I could make for
its growth. It definitely fuelled our growth. I did
hire more testers and I did get more customers with
the money I saved. The best way I learnt to save
money was to not take it.
There were definitely moments where I
thought I was being stupid to have lots of money
in the bank (understand the context of the word
lot there) and not take it. My wife did question if
the business was doing good because I told her
about new customers we got and yet did not bring
money home so that she could run our household.
With our first child’s birth, our household expens-
es simply doubled. I never knew that diapers were
so expensive! I never knew that a child can give
so much joy that I would forget the world. I also
never knew that I would be reminded of money
when changing diapers.
When I shared my concern with Moolya’s
auditors they advised me to take a pay check that
could meet my household requirements. The ques-
tion I put back to them was, “Can my folks do it,
too?” We all took an equal hike in our pay checks
and yet had good cushion of money for Moolya’s
The team, who reports to me, probably
observed what I was doing and they showered more
respect for how I was handling things. They simply
believe they no longer need to worry about their
pay checks because I am there to take care of it.
Test of Passing on the Leadership
Even before I started Moolya, I knew that creat-
ing leaders was the important first step to change
the world. I just knew it but creating leaders is not
as simple as saying it. The most important blocker
to creating leaders in Moolya was none other than
– yours truly – Pradeep Soundararajan. I was the
decision maker for anything in Moolya. For more
than a year and half, people did not make decisions.
I was a strong alpha male overriding every decision
that they wanted to make. I was not power hungry
but didn’t see the trap coming. On a reflection, I
decided to distance myself with things that could be
handled by the team reporting to me. Let me be a
little more honest, it didn’t emerge out of pure self
retrospection. I was stressed and was wondering
what am I doing wrong? There emerged a light.
People need to be trained to use their powers.
Michael Bolton helped me recognize this. I was a
rookie test manager in 2007 and was talking to Mi-
chael on the challenges I had. One of the questions
he asked me, while he jiggled with the problem
was, “Have you used the power you have that
Continued on page 6
AUTHOR PROFILE - Pradeep Soundararajan
a community for software testers
6 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
Ten soldiers wisely led will beat a hundred without a head. - Euripides
Continued from page 5
comes with you at your position?” and I guess what
happened to me was, “Ah, I have powers with this
job? I didn’t know that!”
Helping my team learn how to use their
powers wisely is an important responsibility I carry.
Oh, let me explain that. I made a conscious decision
to make the team that reports to me fully respon-
sible for the testers who report to them and make
decisions independently. Earlier, I used to act like a
super hero doing a whole bunch of things. I still do
care for those who work in Moolya but most of my
caring time is spent with my team.
If you give someone a power, they’d at
times or when needed show the power to you. That
is what happened to me and I loved them when
they did that. So, my respect and love for them
increased. I must admit that I was nervous initially.
After some new alpha fighting old alpha, I called
them to a meeting and requested just one thing – be
polite when you hit me hard!
I have known these people for a long time
now and I trust them so I have nothing to worry.
They are the best team I could work with for making
Moolya what it is today and the potential it has for
the future. Someday, they would empower their own
team with more powers and get to know how I felt.
It was not my intention in writing this to set out a
path of advice or a formula to follow. I just wanted
to capture the Moolya experience report and get
it published. However, I could suggest looking at
people around more carefully, what they do. For
instance, Rosie Sherry has beautifully revolution-
ized the way online communities in testing can be
built. Weekend Testing has revolutionized the way
in which people can practice testing and learn from
other testers. Lets Test conference has revolution-
ized the idea of a testing conference. Andy Glover
revolutionized testing cartoons. The Context Driven
Testing community is revolutionizing the sapient
(ahem, Brainual) testing.
In 2006, I was intimidated by any good tes-
ter I met. I was very nervous. I felt inferior to many
whom I met in CAST 2008. I did the mistake every-
body else probably have done or are doing – that is
- I wanted to be good at everything in testing. Right
from doing conferences, doing online communities,
doing test consulting, testing, mentoring testers,
blogging and everything under the radar of testing.
The moment I recognized I live in an eco system
and I am not THE eco system, I have been living in
it beautifully. My role is to build Moolya to a com-
pany that will change the way the world tests. You
too have a role in the eco system. When you realize
your role, you would learn to live a more beautiful
life. Just like how I did and am doing.
I wish you get as good leaders as I have in
my life. I shall always be grateful to James, Mi-
chael, Vipul and Mohan who have been my consul-
tant leaders and have helped me evolve. Thanks to
Simon Knight and Mike Talks who considered this
editing worthy of their time. □
Leadership in Testing - What Really Matters
By Keith Klain
I’ve hired lots of testers. I’ve hired some great
ones, and some well, not so great ones. Some that
exceeded all my expectations for them, and some
that I thought were bound for “greatness” and fell
short of the mark. Consistently, the one quality
that I see distinguishing the ones who reach their
full potential from the ones who don’t: leadership.
I prefer to think of leaders using the definitional
term “guide” when describing them. They play
different roles under different contexts, but always
guiding the organisation, whether it be a team or an
individual towards the goal.
Now, it is a very common mistake to
conflate leadership with management. A leader
can be a manager as well, but as we all know,
being a manager does not mean you are a leader.
We’ve all struggled under managers who didn’t
have a leadership bone in their body, so to avoid
inflicting that terror on my teams, the following are
characteristics I am looking for in either hiring or
1. Honesty - I speak a lot about honesty because
it’s so important to leading with integrity. It
resonates into every aspect of how others see
you, and how you see yourself. People want
to know that their leaders are telling them the
truth to trust them to act as a co-steward of their
career. And that trust is built with a healthy
dose of self-reflection. Admitting you made
mistakes, sharing information, apologizing
when you’re wrong - good leaders have no fear
of the truth. Honesty is the building block on
which you’ll build great teams, and it has to
Keith Klain is the head of Barclays Global Test Centre, which provides functional and non-
functional testing services to the investment banking and wealth management businesses.
With more than fifteen years of multinational experience, Keith has built and managed global
test teams for financial services and IT consulting firms in the US, UK, and Asia Pacific. Keith
is also a member of the board of directors for the Association for Software Testing. Visit his
blog at qualityremarks.com
AUTHOR PROFILE - Keith klain
start with its leaders.
2. Communication - All great communicators
are not leaders, but all leaders are great
communicators. Setting the context for the
mission is essential to keep people motivated
and aligned with the business, and that means
you have to be able to relate goals to tasks.
People who tell stories that find common
threads in our shared experiences are typically
the ones who get the most from their teams. In
order to propagate an idea, it must be relatable
to something we value ourselves.
3. Humility - History is full of examples of leaders
with tremendous egos. In order to even want
to be in a leadership position, you must have a
healthy sense of self-worth. But I think the best
leaders can drive organisational change, not
as programmatic coercion, but as Dwight D.
Eisenhower called “the art of getting someone
else to do something you want done because
he wants to do it.” That kind of leadership
demands humility. A great tell on whether
someone has a humble spirit is if they use “I”
and “we” interchangeably when they speak
about earlier teams, or give a pat answer when
you ask them about their last mistake. I want
my teams to take ALL the credit because they
are the ones doing all the work!
4. Passion - People look to their leaders to keep
their foot upon the accelerator, setting the pace
for the organisation or team. Passion is what
inspires people, and inspired people can do
amazing things. I am extremely fortunate that
I love my job. But what exactly is my job? My
job is helping organisations and people improve
themselves through great software testing. I tell
my teams that we are not only responsible for
improving testing on our projects, but also in the
industry. Nothing less! If you’re not passionate
about what you are doing, trust me, no one is
going to follow you - regardless of your title.
In my experience the best leaders are honest with
themselves and others, can speak in stories that tie
things together, approach life with humility and
their passion inspires those around them. I’ve failed
more than I’ve succeeded in finding leaders, but
when I have been successful, they’ve met those
marks. Best of luck and happy hunting! □
7Follow us at www.twitter.com/testingclub
The question, ‘Who ought to be boss?’ is like asking, ‘Who ought to be the tenor in the quartet?’ Obviously, the man who
can sing tenor. - Henry Ford
From “Fractal How” to
By Neil Thompson
Are you a “born leader”? Do you want to learn to
become a leader? Does leading people make you
happy and fulfilled? Are you a reluctant leader,
because it seems to be the only way to earn more
money? Or do you wish the people who lead
you could be better at it? And here’s yet another
question: is leading software testers any different
from leading soldiers, or politicians, or sales forces?
My reason for asking all this: even within a
magazine on software testing, I must be mindful
of a diverse readership. But I am intrigued by
different attitudes to leadership, different styles, and
I wonder if and how the whole subject could be de-
stressed and re-invigorated. So I am taking a wide
yet rather personal approach to this topic:
• First, I will outline a troubling phenomenon
I have sometimes encountered in my own
experiences of leading teams – the curse of the
• Then I will make a confession – I am an
introvert – but I will explore the implications of
that for leadership, and try to surprise you with
the positive aspects; and
• I will outline some of my reactions from my
recent attendance at the legendary Problem
Solving Leadership course run by Esther Derby,
Jerry Weinberg & Johanna Rothman.
• And to summarise: what do I think all this
means for the future of testing leadership
(including my own participation)?
I have worked in IT / information systems for
35 years so far, and I have specialised mostly in
software testing for about the latest 20 of these.
So it’s inevitable that I get asked to lead stuff.
Do I think I know more about software testing
than the people I lead? Usually yes – but is that
always an advantage? Do I prefer leading to doing?
The more one knows, the wider the
possibilities for moving forward in any given
situation. “What shall we do now, boss?” “Hmm,
well, that depends...” In my experience this often
spooks team members, and clients don’t seem to
much like it either. At the very least people want
specific options and a recommendation, right? In
testing, I suspect a little knowledge is a dangerous
thing. Many testers seem to have taken ISEB/ISTQB
Foundation (only), have a few years’ job experience
(maybe in a single business sector), and they think
they know everything! “What do you mean Neil, `it
depends’? What kind of leader are you?”
On other occasions, team members seem to
be looking for too much guidance – how to do test
planning, analysis, design, execution, exploratory
testing, progress reporting, bug reporting? And
I would respond, maybe by writing templates,
guidelines, procedures. But it seemed that whatever
I said or wrote, it was never enough; more detail
and specifics were wanted. “Yes but how do I do
that? I need you as leader, Neil, to do x before I
can proceed.” I read recently a claim that whereas
bosses “tell” their team how to do things, “leaders”
show them. But if the leader is working at an
overview level and the “leadees” are working on
the details, how does this showing work?
Here’s another approach to leadership:
set out the main purpose and objectives / goals,
then encourage team members to derive their own
detailed approaches – invite them to contribute
ideas, and express preferences. But sometimes the
response seems to be “that’s your job – when will
your Test Strategy be signed off? I don’t want to
rely on it until it’s signed off.”
Perhaps this is systems thinking at work –
if one starts telling people how to do things, it turns
into a vicious circle of increasing detail wanted
– the Fractal How. But if one starts leading just by
objective, does that become a virtuous circle or just
a different kind of vicious circle? Can too much
diversity lead to disorder? It certainly wouldn’t
win you a CMMi / TMMi level 5 certificate, but
perhaps surprisingly in its special manifestations
of chaos and complexity, diversity can catalyse the
emergence of order!
So I wonder: do the personalities of leaders
and leadees affect the outcomes?
The Power of Introverts in a Noisy World
There have been many attempts to define and
classify human personalities, but the two which
I choose to illuminate my argument here are
the Myers-Briggs Type Indicator (MBTI) and
the Belbin Team Role Model (BTRM). By a
fortunate coincidence, both these were described
in a recent edition of Testing Planet1
. I have taken
tests of MBTI and BTRM on several occasions
over the years, and what struck me most is that
my MBTI seems fixed (or nearly so), regardless
of circumstances or mood, whereas my answers
to BTRM depend on whether I am in business
or leisure mode, how energetic I feel, and other
context factors. Since then I have read 2,4
difference is real and deliberate.
In BTRM, a key principle is that an
effective and efficient team should have all the
roles represented (even if, especially in a small
team, each individual can have two or three roles
combined). A team with one or more of the roles
absent will be unbalanced. The Co-ordinator
role seems an obvious leader, with Shaper and
Implementer also candidates. The other roles
(Plant, Resource Investigator, Monitor- Evaluator,
Completer-Finisher, Team Worker and Specialist)
are arguably more suited to team membership than
being a leader.
Because MBTI is about personality and
BTRM is about context-influenced contribution to
teams, the two are not directly linked, although it
seems obvious that some correlations should exist,
and some authors 2,3,4
have tentatively attempted
to map relationships. Although these all differ in
details, there is a tendency for “leading” Belbin
roles to be Myers-Briggs extroverts. In Figure 1
I illustrate my own summary of these tentative
But isn’t it obvious that leaders are
extroverts and leadees are introverts? More broadly,
doesn’t success in business demand extraversion?
One must communicate with customers, and
quickly impress them; give entertaining and
compelling presentations; motivate and energise
Continued on page 8
Neil Thompson has worked as a consultant and manager in information systems, especially
software testing, since the late 1980s, having previously sold, programmed, project-man-
aged and maintained systems in a variety of sectors. He studied Natural Sciences at univer-
sity, which included some Psychology so he feels some entitlement to write about this kind
of stuff. His website is currently being revamped but he is visible on Twitter as @neilttweet
(also on LinkedIn and Facebook).
AUTHOR PROFILE - Neil thompson
8 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
Continued from page 7
one’s team. An introvert can tell the team what to
do, but to show them, to help them over obstacles
day-by-day, hour-by-hour, minute-by-minute, needs
an aptitude and appetite for human interaction.
No, it isn’t that obvious, and it should not be seen
In a recent book 5
Susan Cain (a self-
declared introvert) analyses critically the rise of the
extravert in the modern world, but particularly in
the business culture of the USA and its followers.
Some other cultures value introversion more, and
this might help to explain the rise to global success
of some Asian business cultures. There is some
evidence that introverts make better problem-
solvers – and better leaders in some situations. But
in other situations, for more traditional types of
leadership (especially “command-and-control”), the
extrovert is king (or queen). Working environments
have changed over recent years to favour extroverts
(e.g. open plan offices), although there are now
some moves towards more flexible arrangements.
The most obvious response for an introverted
leader, and one which several authors have
recommended, is for the introvert merely to behave
like an extrovert. But this involves the person
operating for most of the business week outside his/
her comfort zone, leading to lots of stress. There
are however other ways for introverts to maximise
their leadership potential (for example, managing
/ overcoming fear of public speaking, forming
powerful partnerships with extrovert “front men/
women”, using the internet as a primary mechanism
for influencing others).
So, one of my objectives as an introvert is
to improve the signal-to-noise ratio in testing, the
business world and society as a whole (depending
on how far I can influence!). Winning friends and
influencing people, insisting that all problems
are solved in group situations, equating creativity
with verbosity, “groupthink” conformity, style
over substance... these trends have become
too pervasive, and are arguably a hindrance to
A couple of years ago I attended the Problem
Solving Leadership course, run in the USA by the
revered Derby-Rothman-Weinberg team.
One of PSL’s many strengths is that it
asks each attender to do some formal preparation,
including mapping out personal objectives for
the course – both for his/her benefit and for the
information of the facilitators. Although obviously
much of this is personal, I am willing to share
here that I wondered what kind of a leader I really
wanted to be best at, or to do most of – my project
management days are probably over, but I often
work as a programme or project test manager,
and for fun I write presentations and papers
for conferences. I enjoy much less the public-
speaking part of delivering the presentations, but
it seems a price worth paying for claiming to be
a “thought leader” (and for sometimes getting a
free conference ticket). Although my personality
is more suited to process improvement and
I am more afraid of an army of 100 sheep led by a lion than an army of 100 lions led by a sheep. - Talleyrand
similar consultancy work, I typically alternate
such engagements with delivery-focussed project
assignments, which I find helps maintain all-round
A large part of PSL consists of
“experiential” exercises, conducted in various
groupings of the attenders, and involving some
role-play. Some people choose to stay within their
comfort zones, while others deliberately (or maybe
accidentally) experiment with what happens when
one goes outside the usual boundaries.
Of course Jerry Weinberg has written many
books, and one in particular 6
closely covers this
subject. Although it was written over 25 years ago,
Jerry’s view remains that problems in our industry
are much more human than technical. Two points he
particularly emphasised back then: people can and
should contribute as “leaders” without necessarily
being labelled as such by a job title in a threat-
reward culture; and academic psychology seems
irritatingly (surprisingly?) dogmatic.
Since taking the course I have pursued
several lines of further enquiry:
• In my own presentation “Testing as Value Flow
Management: Organise your toolbox...” 7
explained how use of psychological models
should be treated as a scientific hypotheses and
experiments (not dogma);
• Steve Myers 8
distinguishes eight leadership
styles (ideological, theorist, visionary, goal-
oriented, change-oriented, executive, action-
oriented and participative), suggests alignments
to MBTI, and considers their variable
suitabilities and tailoring to different contexts
such as computing, engineering, academia,
research, project management, administration,
accountancy, education, human resources,
entrepreneurship, marketing and sales (all of
which I could argue have some relevance to
• Susan Cain’s book explores the ways introverts
have contributed to leadership in history,
currently contribute, and could lead better in
future (introversion aligns to Steve Myers’
ideological, theorist, visionary, goal-oriented
Cain makes several assertions, backed up by
selected evidence and stories:
• Many introverts started life as “high-reactive”
babies – very sensitive to adverse stimuli and
conditions, but conversely capable of great
things when appropriately nurtured (the orchid
• Introversion persists into adulthood but people
can learn ways to manage the symptoms and
turn the situation to their advantage (as outlined
in the previous section);
• The results achieved by introverted leaders are
often in excess of others perception of their
success – in other words, there exists cultural
bias against introverted leaders;
• People can learn and manage to operate outside
their comfort zone for periods of time and
under specific conditions, particularly when
they understand the factors and forces involved
– an “elastic” model of personality.
So, in Figure 2 I summarise a mooted evolution
of temperament (as a child) into personality (as an
adult) into context-driven exercising of roles in a
working team. Now, what does all this mean for the
future of leadership in software testing?
I suggest that the traditional style of command-and-
control leadership is (despite the recent Olympics-
security triumph of the UK military over the “lean”
G4S company!) fundamentally unsuited to the
increasingly rapid and pervasive emergence of
innovation in the world (and hopefully in software
testing). Some authorities 9
embody this principle in
a distinction between management (using already-
established values and principles) and leadership,
which sets new visions and directions.
Continued on page 9
9Follow us at www.twitter.com/testingclub
Continued from page 8
In Susan Cain’s book 5, she quotes some new
research by Adam Grant, which offers evidence that:
• Extravert leaders enhance performance when
employees are passive; but
• Introvert leaders are more effective with
In Figure 3 I project these findings onto my own
experience, giving illustrative quadrants of the
combinations of extravert and introvert leaders with
active and passive leadees.
By encouraging and facilitating ideas and
contributions from upcoming generations – not so
much telling them or showing them what to do, but
instead channelling and maybe filtering their ideas
in the light of our longer (but maybe outdated)
experience, we leaders can catalyse the emergence
of the innovations which will increasingly be
needed as technology-enabled change continues to
accelerate. For myself, I seek a tipping point, which
will turn the vicious circle of Fractal How into a
virtuous circle of empowerment. This is not meant
to be an entirely laissez-faire attitude, but neither is
it authoritarian or prejudiced.
So, to make practical use of this argument, I
• Try to understand at least something of your
own personality and the personalities of
those around you. It might seem sinister, or
manipulative, or even politically incorrect, but
if you treat the perceptions or confidences with
respect, and be mindful of their limitations
and caveats, it should help you understand the
leader-leadee dynamics in your situation.
• Be aware that appearances can be deceptive:
people’s personalities may be mapped onto
secondary or tertiary Belbin roles according
to context and depending on how far a person
wants, or is forced to, operate outside his/
her comfort zone. Whether you are a leader,
want to be a leader, or are being “led”, try to
understand what style of leadership is in use,
and whether it is appropriate to the context.
• What improvements could you make in your
behaviour, or would you like your leader to
• And if like me you are an introvert and
want to be a leader, you may seem to be at a
disadvantage. But think hard about what kind
of a leader you really want to be, which Belbin
roles you can fulfil which are not your primary
inclinations, and when and how far you are
willing to transcend your comfort zone.
• And if you are an extrovert and already a leader
– please listen well to your quieter colleagues! □
To lead the people, walk behind them. - Lao Tzu
10 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
A real leader faces the music, even when he doesn’t like the tune. - Anonymous
It Takes a Village: Training, Leading,
and Inspiring a Young Testing Team
AUTHOR PROFILE - DEVON TOOLEY
By Devon Tooley
Four years ago I was tasked with setting up a QA
team at a small firm in New York. The company
was young, with enthusiastic developers and
dedicated project managers. In skinny jeans and
t-shirts (and the occasional mohawk), they had
experimented with programming languages,
development methodologies, and open workspaces
filled with beanbag chairs and whiteboard walls.
More San Francisco than Big Apple, they cultivated
a flexible and optimistic vibe populated with
talented, successful employees. The one thing that
had not fully taken root was a solid QA department.
That was my job.
I needed to grow an effective QA team that
fit in with the current development process. This
meant training new hires to be as good at identifying
bugs as they were at dreaming up better ways to hunt
for them, and developing a QA culture that jived
with the other passionate and engaged groups of the
The lack of a “why?” was the biggest plague
to traditional training programs I tried in the past.
New-hires were inundated with information but not
yet sure how to put it together. This was especially
apparent because most new team members were also
new to testing. The problem was that on a busy team
we needed people to ramp up quickly.
With my first hires there was no formal
training. We limped along with documentation
and job shadowing, but the results were not
great. I had one member with a computer science
background who saw this job as a stepping-stone
to a future development job. Another stumbled on
small tasks because the details got lost without the
I knew something had to change to get
the strong cohesive team I envisioned. What was
missing? Ability? No - everyone was more than
qualified. Culture? Doubtful – we had a relaxed,
and supportive working environment. It was
something less tangible than experience or relational
shortcomings. The newest members, many of whom
were in their first real job, simply lacked the vision
to see their role in context of the whole. I set about
trying to provide that big picture for them.
I had new hires help developers with unit
tests and sit with more experienced testers while
debugging. They even went over documentation
with project managers. They were treated like more
senior employees – responsible for their section of
the code, although they started with a smaller set of
functionality – and they had an opportunity to soak
up experience from all aspects of the team. I let them
see their role at the start of the project, and feel their
role at the end when test-escapes came back. I tried
to constantly provide ways for them to expand their
impact to all parts of the development cycle.
What results did I see? A better
understanding of what they needed to do led to more
initiative on their part. Giving them responsibility
encouraged them to seek even more responsibility.
But the most surprising thing, which I noticed almost
without exception, was passion. When they saw the
“why” of what they were doing – the effects their
work had upon the entire company, the QA function
became not just about the result, but also the process.
I saw computer science students become excited
about testing because they understood that technical
ability could be applied to their tests; humanities
majors dug into the requirements to see how all the
functional components fit together. They saw the
impact they could make, and their passion awoke.
There are few better places to develop
passion for your work than in a start-up, but I
believe the methods could be the same no matter
the company size. I was able to see who was good
at what, and assign projects that matched their
strengths. However, this was not always a fool-proof
I recall one new tester in particular who
never moved beyond the wall, failing to get involved,
and eventually moved on. Despite the stumbling
blocks, the majority of people made progress. I
gave one new-recruit the ownership of a project and
watched with suspicion as he fumbled, fudged, and
failed to engage. I knew I could not let the project
fail but, at the same time, I needed him to step up.
I had him schedule a meeting to present
his test plan and progress to the developers. I was
worried and asked for progress reports and continued
to struggle with conveying the importance of his
work. The meeting rolled around and I was tempted
to intervene and prepare something myself, but I
held back: knowing that this internal deadline might
be my only chance to turn things around before the
external deadline. He came in, as I feared, totally
unprepared. The developers asked questions, raised
concerns, made suggestions, and left disappointed. I
met with him afterwards to go over expectations and
debrief. I saw something change in him. He wanted
to get his test plan in place; not because it was a job
task, but because he saw the direct consequences of
inaction. He felt personally responsible for correcting
the weakness of his tests. His whole approach was
transformed. Suddenly he asked questions, dug in,
and worked hard to hold up his end of the project.
The product launched successfully.
A later new-hire also benefited from this
integrated method. He came in as a freshly minted
computer science major that felt he needed some
experience before jumping out of testing and into full
development. Without much background in the field,
he was not initially excited about his new role. Like
the others, I let him get to know the team and see the
depth to which testing could be taken. He took to
automated testing right away, particularly enjoying
the ability to code integrated tests. Soon he started
asking questions about our test harness – the system
we used to track, run, and monitor our automation.
He started looking at ways we could run tests more
efficiently and integrate with some great open source
software options. Over time, he became a contributor
to open-source testing code for a variety of projects.
He and I went to a conference to present on our test
infrastructure. The team was soon using his solution
full-time. He has gone on to take more advanced jobs
in QA and still works in the field.
Passion isn’t developed because of beanbag
chairs and white board walls, but because of the
environment a company fosters. If testing is to be
an integrated effort, training should include all team
members as early as possible. Each tester may have
an area of interest or a special skill, and a “cookie
cutter” ramp up approach might train them on process
but does little to inspire. Those of us who love testing
know that it is passion for the intricacy of the job that
makes it rewarding, challenging, and worthwhile.
Testing is often lumped together as part of
developer tasks, but an engaged test team can help
guide a project and keep the whole team striving for
quality. Growing an engaged test team takes engaged
co-workers to help QA engineers – at all stages of
their career – find passion in testing.
It takes a group effort to make great
software, and it takes a village to raise new testers. □
11Follow us at www.twitter.com/testingclub
Testers and Leaders
By James Christie
“A tester is someone who knows things can be
different” – Gerald Weinberg
Leaders aren’t necessarily people who
do things, or order other people about. To me the
important thing about leaders is that they enable
other people to do better, whether by inspiration, by
example or just by telling them how things can be
different – and better. The difference between a leader
and a manager is like the difference between a great
teacher and, well, the driver of the school bus. Both
take children places, but a teacher can take children on
a journey that will transform their whole life.
My first year or so in working life after
I left university was spent in a fog of confusion.
I struggled to make sense of the way companies
worked; I must be more stupid than I’d always
thought! All these people were charging around,
briskly getting stuff done, making money and
keeping the world turning; they understood what
they were doing and what was going on. They must
be smarter than me.
Gradually it dawned on me that very many
of them hadn’t a clue. They were no wiser than me.
They didn’t really know what was going on either.
They thought they did. They had their heads down,
working hard, convinced they were contributing to
company profits, or at least keeping the losses down.
The trouble was their efforts often
didn’t have much to do with the objectives of the
organisation, or the true goals of the users and the
project in the case of IT. Being busy was confused
with being useful. Few people were capable of sitting
back, looking at what was going on and seeing what
was valuable as opposed to mere work creation.
I saw endless cases of poor work, sloppy
service and misplaced focus. I became convinced
that we were all working hard doing unnecessary,
and even harmful, things for users who quite rightly
were distinctly ungrateful.
It wasn’t a case of the end justifying the
means; it was almost the reverse. The means were
only loosely connected to the ends, and we were
focussing obsessively on the means without realising
that our efforts were doing little to help us achieve
Formal processes didn’t provide a clear route
to our goal. Following the process had become the
goal itself. I’m not arguing against processes; just the
attitude we often bring to them, confusing the process
with the destination, the map with the territory.
The quote from Gerald Weinberg absolutely
nails the right attitude for testers to bring to their
work. There are twin meanings. Testers should know
there is a difference between what people expect, or
assume, and what really is. They should also know
that there is a difference between what is, and what
Testers usually focus on the first sort of
difference; seeing the product for what it really is
and comparing that to what the users and developers
expected. However, the second sort of difference
should follow on naturally. What could the product
be? What could we be doing better?
Testers have to tell a story, to communicate
not just the reality to the stakeholders, but also a
glimpse of what could be. Organisations need people
who can bring clear headed thinking to confusion,
standing up and pointing out that something is
wrong, that people are charging around doing the
wrong things, that things could be better.
Good testers are well-suited by instinct
to seeing what positive changes are possible.
Communicating these possibilities, dispelling the
fog, shining a light on things that others would
prefer to remain in darkness; these are all things that
testers can and should do. And that too is a form of
leadership, every bit as much as standing up in front
of the troops and giving a rousing speech.
In Hans Christian’s Andersen’s story, the
Emperor’s New Clothes, who showed a glimpse
of leadership? Not the emperor, not his courtiers;
it was the young boy who called out the truth,
that the Emperor was wearing no clothes at all. If
testers are not prepared to tell it like it is, to explain
why things are different from what others are
pretending, to explain how they could be better then
we diminish and demean our profession. Leaders
do not have to be all-powerful figures. They can be
anyone who makes a difference; teachers, children.
Or even testers. □
AUTHOR PROFILE - James Christie
EDUCATION • COLLABORATION
12 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
to be a
By Bill Matthews
“If we call a tail a leg, how many legs does a dog
have? Four! Calling a tail a leg doesn’t make it a
leg” - Abraham Lincoln
The above quote is one that comes to mind
when I meet people with the word Leader in their
job title or worst still they are a self proclaimed
Thought Leader or Industry Leader. Culturally we
think of leaders as being the person in charge so
having the word leader or manager in your job title
is one kind of leader. However there is another
perspective we can take where a leader is someone
who takes actions that resonates with others such
that they recognise you as a leader.
In this sense, being a manager or having the
word leader in your title is not a pre-requisite to being
seen as a leader; anyone can be a leader. To be seen as
a leader you need to take a conscious decision to take
the lead at times that need leadership.
Whether you aspire to be a leader at work
or in the testing community or both it all starts with
taking action. However it’s not about taking any
action or taking action all the time; instead you
have to choose when action is actually needed and
how best to lead that change. It’s a subtle art and
timing is often the difference between being viewed
as a leader or a meddler. Here are some ideas to
help you get started on the road to leadership.
Be a Problem Solver
Solving problems is a hallmark of leaders across all
contexts; however it is not about solving any problem,
only those that are important for people who are
important to you. You can solve as many problems as
you want but if no one cares about the problem then
you are unlikely to be perceived a leader.
Problems occur when people have a
reaction to an actual or potential event; if those
people are important to you, you should consider it
to be an important problem regardless of whether
you perceive it to be a problem. Remember, being a
leader is a relationship between you and others that
is determined by your actions.
Developing the ability to observe a
situation, formulate and communicate a plan and
then delivering that plan is a key to being a leader.
How do you know if you’ve solved a problem?
Well you solve a problem when those that are
important to you no longer perceive the event as
being a problem. In reality you are not changing
the event, only the perception and reactions to that
event. Not convinced? Consider:
• If the event has already occurred and you are
dealing with the aftermath you can’t change the
event but you can change how others perceive the
consequences of the event. The actions we take to
reduce the immediate and potential consequences,
and to reduce the likelihood the problem will occur
again in the future, all strive towards ensuring the
event is no longer perceived as a problem.
• If the event has not yet happened, it may never
happen even if you don’t take action, but by
taking action to minimise the chances of this
event happening then you are changing people’s
perception of that potential event so it is no
longer perceived as a problem.
The challenge with solving problems is that, just
because we have solved the problem for one group,
it might still be a problem for others. Additionally
your actions might introduce or uncover further
problems for those that matter.
Be a Problem Finder
Being a problem solver is important but can lead to the
development of a Hero Culture where problems are
left until they become BIG PROBLEMS and the Hero
arrives to save the day. It’s one way to solve problems,
but constant fire-fighting isn’t really leadership.
One idea is to be alert for signs of potential
problems and proactively act to resolve them before
they become actual or even worse, big problems.
However this is a difficult and subtle art because we
cannot predict how a potential problem will develop:
• Some are just illusions.
• Some will not grow into anything significant.
• Some will develop into something beneficial.
• Some will become problems that few people
• Some will become significant problems.
Leaders should focus on identifying those potential
problems that are likely to become significant
problems for the people that matter. If you spot
such a potential problem you may sometimes be
in a position to take action directly. At other times
however you might need to consult with others to
decide how best to avoid the potential problem.
Leaders need to be able to consider each situation
on its own merit and decide how best to take action
and indeed whether to take any action at all.
Sometimes as a leader your actions will not have
the effect you expected and you will feel like you
have failed; dealing with the consequences of
failure is part of leadership.
The first step is to take responsibility for
your actions – leadership is a choice and if you
choose to lead then you need to be prepared to take
personal responsibility for your actions whether you
are personally accountable for them or not.
The second step is to learn from the
situation; asking yourself (or others) questions such
as the following are helpful:
• How do you know it was a failure?
• What have been the consequences, both
positive and negative?
• Were there specific signals that you missed or
ignored that might have changed your actions?
• In hindsight, could you have acted differently?
The last step to accepting failure is quite simply to
move on; nothing you can do now will change what
has already happened but the actions you take next
can change what might happen in the future.
Become a Student of People and Communication
Warren G Bennis, a pioneer in the field of
leadership studies, said “the basis of leadership is
the capacity of the leader to change the mind-set,
the framework of the other.” People are at the heart
Continued on page 13
13Follow us at www.twitter.com/testingclub
Bill Matthews has been a professional tester for 18 years and is the owner and principal test
consultant at www.TargetTesting.co.uk; most of his time is spent consulting and leading
the delivering testing projects for companies with particular focus on the more technical
elements of testing such as systems integration, security and performance. He has start-
ed blogging at www.rethink-testing.co.uk
AUTHOR PROFILE - BILL MATTHEWS
Continued from page 12
of leadership and to be a good leader you
must become a student of people and how to
communicate effectively with them.
The challenge with people is that while there
are similarities there are also differences; these
mean that they don’t all respond in the same way
to the same motivations and stimulus. To further
complicate matters, people will often respond
differently in different contexts.
A good leader should recognise these
differences and similarities and adapt to the
people and context. A leader who can’t adapt
may find success in certain contexts with certain
types of people but seem ineffective in others. As
Bernard Baruch said “If all you have is a hammer,
everything looks like a nail.” So:
• Develop your rapport and empathy skills – if
you can’t engage or empathise with others then
leading will be difficult and probably limited to
• Learn to be flexible in your style of
communication - practice or role-play
communicating with different levels of
formality, authority, softness. Learn to match
your style to the people and the context.
• Learn to be flexible in your use of language –
language is based on shared experience so consider
that the language you may be using is part of the
problem. This can come in many ways, overuse of
clichés, technical jargon or even sticking to specific
definitions of words. Be prepared to accept the
shared experience of others rather than force them
to accept yours; but also be prepared to expand
their shared experience to include yours.
• Be flexible in your thoughts – it’s easy to be caught
up with your own ideas and plans and ignore or
dismiss those put forward by others. Learn to accept
that someone else might have a better idea; being a
leader is not about delivering only your ideas.
Observe Other Leaders at Work
There is no single model of a leader; sure there are
many books on leadership that identify specific
characteristics, skills, processes and attitudes but
these are just the symptoms of leadership not the
leader themselves. A good way to understand a leader
and leadership is to observe them or it in action. The
intention here is not to imitate or emulate another
leader only to understand how leadership works.
Think of someone you consider as a leader;
what is it that they do that makes you regard them
as a leader? At what point did you begin to regard
them as a leader? How do their actions impact you?
Do you think you have changed as a result of that
leader, if so how and in what way? Is there anything
about them that you don’t like? Are they perceived
as a leader by others? How do they differ from
others you perceive as leaders?
Observing from afar is a good start but
why not reach out to your leaders and ask them for
advice and guidance? Many leaders I’ve known are
very generous with their time and knowledge.
It’s a common misconception that you need to
be popular or well liked to be a leader but this is
not the case. A more likely scenario is that people
become popular because they are leaders.
A number of the people I perceive as leaders
have qualities that, in different contexts, would
prevent them from being popular or even liked;
many are grouchy, cantankerous, argumentative or
just plain rude. By the same token, many are open,
warm, friendly and generous. These characteristics
are not what make them a leader; it is their actions
and how these resonate with others that make them a
leader. It’s true however that some characteristics can
make their leadership easier to see or accept but the
presence or absence of these does not mean they are
So an important point about being a leader
is to be yourself and accept who you are. Learn
from others but don’t try to imitate them since
what works for them may not work for you. When
talking about martial arts, Bruce Lee said “Absorb
what is useful, reject what is not, add what is
specifically your own”; this is very apt for your
development as a leader.
One last point, the actions you take must be
congruent with who you are, your beliefs, values and
ethics. Without this you will lack the passion and
conviction needed to be a good leader and this will
be evident to those you are hoping to lead. Action
without congruence is not the path of a leader. □
a community for software testers
14 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
Trent Peterson is a founder at AppThwack, a company focused
on making app testing fast, painless, and easy via automated
testing on real devices. Prior to AppThwack, Trent spent seven
years leading the design, development, and deployment of
the automation framework used for testing all of Intel’s wire-
less products. Trent has a B.S. in Software Engineering from
Oregon Institute of Technology and studied data mining and
visualization at Stanford. Besides automated testing, he enjoys
running, playing guitar, and drawing pictures.
AUTHOR PROFILE - TRENT PETERSON
So you guys started AppThwack about a
year ago. Can you tell us a bit more about
the early days?
What were you both doing before you
We started with the same basic problem AppThwack
addresses today: Allow developers and QA teams
to quickly test apps on real, physical devices. In the
beginning, early development was on completely
emulated devices. We received a couple of old,
broken phones from a friend and those were the first
real devices we used, tethered to the same laptop that
ran AppThwack, the database, and our automation
platform. Our earliest demos to potential investors
and customers were on that setup.
Pawel and I both worked at Intel for nine and
seven years respectively. During that time we led
the design, development, and deployment of the
automation framework used to test all of Intel’s
wireless products (Wi-Fi, WiMAX, Bluetooth, etc.).
At Intel, we had taken a product from the early
conceptual stages to widespread distribution,
effectively working as a small company-within-a-
company. For a long time we had kicked around
various business ideas, and in the beginning of 2012
we were ready for a new challenge and became
aware of the complexities of mobile testing. All
of those years working with large-scale system
automation and testing gave us an interesting
perspective to a popular problem, so we jumped
ship to work on mobile testing and QA, starting
with Android fragmentation.
We maintain an ever-growing collection of phones,
tablets, and other devices in our lab. Developers
and QA teams upload their apps to our site and we
automatically test it in parallel on their selected
devices very quickly. In 5-10 minutes we install,
launch, explore, stress, and uninstall a given app,
gathering screenshots, performance data, and low-
level logs along the way. A report is generated in real
time that makes solving issues and analysing the data
easy. AppThwack can also run custom scripts using
a handful of popular frameworks like Robotium and
Calabash, so as a developer’s testing becomes more
sophisticated we can easily accommodate it.
All of the devices are controlled over USB
and sit on a Wi-Fi connection so apps can interact with
the outside world. The backend of AppThwack is a
distributed automation platform we developed using
our knowledge of large-scale system automation. This
has allowed us to grow extremely fast and spread
beyond just native Android tests. We now support
testing responsive web designs in actual browsers on
real phones, and iOS support is coming soon.
Development was surprisingly smooth and scaling
has been straightforward as well. Most of our
up-front time was spent building the automation
platform AppThwack uses. Our background
in system automation and building large-scale
automation platforms definitely helped us avoid
some common issues and pitfalls.
I think the line between “mobile” testing and
software testing in general will continue to blur.
Phones, tablets, televisions, cars, laptops, desktops,
and on and on - there’s an expectation that our
digital experiences will span all of these in one way
or another, and a testing strategy and tool-set for
each simply doesn’t scale. Tools and methodologies
will mature to ensure our increasingly complex
world works the way we expect and the way
Continued on page 15
“...the line between “mobile” testing and soft-
ware testing in general will continue to blur”
15Follow us at www.twitter.com/testingclub
Our challenges are largely business-related, and
run-of-the-mill young company issues. Things like
who and when to hire, how much to charge for
our product, and how to get in front of the right
developers and QA organizations. On the technical
side it’s just prioritizing new features. We have way
more ideas than we have time to implement them,
and we’re extremely picky about what we decide to
work on. Our service is extremely powerful but also
really simple to use; it’s a constant struggle to keep
We were part of PIE (Portland Incubator
Experiment), an accelerator run by
Wieden+Kennedy, from July-October. We were
lucky to work with a great team at W+K on the
branding. We wanted to accomplish two things.
First, we make a boring, painful, and complicated
task easier and fun and the branding should reflect
that, and second, we’re not like every other QA,
automation, or run-of-the-mill technology company
so our branding should differentiate us.
Testing is a science and should be treated as such.
It’s very easy to get sloppy and test without regard
to the environment, or, even worse, working
chance into an official part of the test process.
By all means, include randomized testing if you
so wish, but it pains me to see “random” as the
foundation for a test plan. Also, I’m biased, but
work testing and automation into development. The
most successful test teams I’ve seen were almost
indistinguishable from the development team.
For entrepreneurs, trust your judgement
when it comes to your product. If you think
it’s great and useful, chances are it is. Listen to
feedback and suggestions, but at the end of the day
if you feel differently don’t be afraid to say “no.”
Also, people always say to release early and release
often. I can tell you it’s much easier said than done,
but you should definitely strive for it. Lastly, start
experimenting with pricing as soon as possible.
We started playing with pricing models before we
were entirely comfortable with taking money for
our product, but it turns out we could have had
happily paying customers much earlier, and, more
importantly, learned much earlier what works and
what doesn’t. □
Continued from page 14
Need to know what browsers are being
used? Stats Counter is a very useful tool
that shows you, in bar chart or line graph
format, the most popular browsers,
operating systems, search engines,
screen resolutions and social media
sites. You can view stats globally or select
stats by a region/country to see how it
affects where you are. A great source of
information that goes back to early 2008.
Translating your whiteboard into Visio
diagrams can be a time consuming task.
If you are only creating them to share a
daily update or a one-time visual aid, stop
doing it! Save tons of time and effort; take
a photograph of the board instead. You
could snap it on your phone, email it to
yourself and then share it with others in
just 2 minutes. Easy!
Found a bug? Want to quickly add your
browser details to your defect? Give
‘Support Details’ a try. Just open a new
tab in your browser, pop in the link (add
it to your favourites for even speedier
access) and the page will instantly display
your browser, version, operating system,
IP address, screen resolution, browser
colour depth and flash version. Oh, and
it lets you download this information
in a handy .csv or .pdf format for quick
attachment to your defects.
Does it pay to be promiscuous?
Promiscuous Pairing is an effective means
of knowledge transfer. While two people
are paired, they share knowledge. When
the pair splits for a promiscuous pair
swap, the knowledge then spreads to all
four participants. In this way, knowledge
will slowly but automatically spread
around the group.
Read more at http://tinyurl.com/bwjarme
lunch? Why not help your team learn
something new by organising a learning
lunch session? Take turns in your team
so that everyone has a chance to share
some knowledge and effectively grow
the team’s capability. Share some useful
SQL statements, discuss Session Based
Testing or even teach someone how
to build a computer. Get your thirst for
knowledge flowing and start one today!
Read more at http://goo.gl/ktZjZ
Too many emails? Not enough time
for testing? We can spend far too much
time checking our emails and this can
distract us from actually getting on. Try
separating your emails into 4 folders;
Inbox, Needs Reply, Follow Up and Trash.
Then use these tips to keep your inbox
from getting on top of you:
• If you can reply immediately do it!
• If the message needs a longer
response, or more information to get
before replying to it, put it in the Needs
• If you have read it and don’t need it or it
just is of no relevance to you, delete it!
If you use a Mac you can even set up
smart folders, which will do this for you
automagically. Find out how at http://
I don't know
I believe there is a meaningful
difference between the concepts
of management and leadership.
I don't know
I believe it's necessary to have performed
the work of those you lead or manage,
in order to be an effective lead/manager.
I don't know
I believe I could carry out the
task of my immediate lead/manager
better than they can.
Please tell us if you
are Male or Female.
What skills do you think are required
to be an inﬂuential and effective
software testing leader?
What skills would you like to receive
more training/coaching in?
At what stage of your career are you?
Mostly they do
I'm not sure
provides me with all the training and
support I need to excel in my role/career.
I use the internet/social media to network/
increase my skills/knowledge.
All the time!
I go to conferences/meetups to network/
increase my skills/knowledge.
All the time!
I get trained/coached elsewhere in order to
increase my skills/knowledge.
All the time!
I read industry magazines/papers to
increase my skills/knowledge.
All the time!
Only outside of work
What proportion of your time, if any,
do you spend managing and/or leading?
What is you current employment status?
Who has inspired/inﬂuenced your
testing career the most?
First test manager
Gojko Adzic Pradeep Soundararajan
No onePrevious test manager
18 March 2013 | www.thetestingplanet.com | Use #testingplanet hashtag
When I read Sun Tzu’s TheArt of War, I tend to
relate it to testing. Particularly Chapter 13, The Use
of Spies. For those of you without TheArt of War
on your bookshelf, you can find a variety of online
In Chapter 13, of TheArt Of War, Sun Tzu lists
“foreknowledge” as one of the key elements that allows
enlightened rulers and good generals to achieve success.
Foreknowledge not from spirits, or spooky stuff.And
not from experience, or plans. Instead from observation
based knowledge of the enemy, gained by using spies.
The kind of things testers do. Looking at the
system, using the system, probing its weaknesses and
reporting back on its capabilities and flaws. Providing
information back to the project so that subsequent
decisions can use the observations as a basis, rather
Sun Tzu provides sage warnings on how to
deal with, and manage, spies. Which we as testers
take should pay attention to. For instance Sun Tzu
cautions against trusting the spies implicitly and
encourages questioning the scope and accuracy of their
observations.And then I watch “Burn Notice” on TV.
“You know spies; bunch of bitchy little girls” -
SamAxe, Burn Notice.
Sadly SamAxe’s statement resonates, because
sometimes it seems like a whole mass of testers acts as
the whiny, moaning, subservient person in the corner.
Sometimes I accidentally stumble on a LinkedIn
post that triggers a “just count to 10” moment, or a
“semantic pause”. These posts tend to involve someone
in a leadership or management position, who doesn’t
seem to know what to do, hasn’t taken any action, wants
everyone to do a ‘proper’process, and instead makes
catty statements about their position in the world.
I moan too, about things that aren’t working.
But I try to do it supported by evidence.And I take
action (within the limits that I can take it) to change the
things I can change. But I don’t expect everyone else
around me to change to fit my process. Take this lesson
I didn’t learn this from direct experience.
I was reading the Gary Halbert “Boron Letters”.A
series of letters he wrote to his son Bond (see spies
get everywhere). He wrote the letters from prison to
distil some life experience and his ‘secrets of direct
The Evil Tester’s
AUTHOR PROFILE - ALAN RICHARDSON
marketing’.And much as I want to relate Sun Tzu and
James Bond to the world of
Software Testing, sometimes I find the ‘nice old guy’in
the Boron Letters a good fit for a lot of the tester attitude
in the real world.
I’ll let Gary explain: “Defensive Behaviour
InvitesAggressiveAction! ... in life in general (and in
prison in particular) there is very little sympathy for a
weakling.” In the letters, Gary describes an old man who
in prison becomes overly obsequious, and irritatingly
fawning. “...I am a very non-violent person, and if this
guy... can irritate me, just think how some hard vicious
hard-nosed jerk in a real prison would be affected by
him...You see, this guy is sending out signals and those
signals are saying, ‘I’m scared... I’m Vulnerable’“
We don’t want to be that ‘nice old guy’on
the project. We learn from spies, certainly in the films
and books that I absorb, that because they work alone,
they develop a toughness. Using Gary Halbert’s words
“Rely on your own strength instead of somebody
Spies become tough enough to allow
them to pass on hard information, work in stressful
circumstances, rely on their own decisions, know
when to take risks and back away. They can stand their
ground supported by observations on the ground.
And the last advice from Gary Halbert that
we can all take on board? “Big strong arms. Start
developing them right now. There are no drawbacks
and many benefits.” □
19Follow us at www.twitter.com/testingclub
ome people want to know how to be a good or even a great leader. Being a good leader is hard however,
so let us go down the opposite road - how to be the most terrible leader possible. I will give you ten
simple steps to becoming the worst leader you can be!
Tell everyone on your team they need to follow
certain procedures. If they’re not using the
system correctly, they’ll catch hell for it. You,
as their leader, don’t need to follow those,
however. You’re above them, anyway. If they
can’t figure out that you’re the exception to all
of the rules, you don’t need them.
Do your best at every turn to make your
subordinates extremely uncomfortable, ideally
to the point of crying. Get openly angry with
them, especially if they don’t follow those
policies and procedures they should be (see
Step One). If you don’t make at least one
employee cry per week, you’re not being
effective enough. Try harder! They need to get
it out, anyway - you’re offering a service here!
Email is below you, after all. If they can come
into your secluded office, then they shouldn’t be
bothering with a silly email. Besides, if they don’t
come to you in person, you can’t make them cry.
Lure them to you by not answering their emails.
If they don’t respond to your emails, that’s a
different matter entirely (see Step One).
If you have leaders below you asking for
help on personnel issues, it’s best to say “I
don’t know what to do” and stare at them
blankly. This will make them a better leader.
It’s like “whatever doesn’t kill you makes you
stronger;” only it’s really - “whatever I don’t
want to deal with, you get to do instead”.
You can also accomplish the task of
making others do your work by confusing them
with (non-) decisions. For instance, they say,
“I need you to decide what I should do for The
Smith Contract.” You respond, “Ok, but for
me to know what you should do for The Smith
Contract, I need to know what you will do for
The Smith Contract”.
This generally puts them in a state of
confusion such that you can walk away, and
the decision is now on them. If they don’t want
to disappoint you, they’ll do their work. You’ll
probably be disappointed anyway (see Step Six)...
Offer an “open door policy” but don’t show up
in the office. “Work from home” for weeks at a
time, being available via email only (see Step
Three). You know you’ve done well when your
employees don’t recognize you once you’ve
decided to come back to the office. To be even
more effective, ensure the “working from
home” policy to allows only you that privilege
(see Step One).
Make huge decisions but don’t tell anyone,
and then yell at the team (after the deadline, of
course, or it won’t be effective) for not doing
what you decided. They should know what you
want. It was on a sheet of paper in your office
for weeks. It’s their own fault for not seeing it!
Also, shouldn’t they know what you
expect of them? It was in the job description 10
years ago when they sent in their resume, right?
Whiners, wanting your “expectations”
spelled out for them...
Continued on page 20