Page 1

Page 2

Dear Reader,
I am very proud to present to you this ebook that you are
about to start reading.
In it, you will read all about the lessons that have helped
shape our company into the organisation it is today.
Essentially, this ebook is the product of my many years
in the world of software testing, compounded by the
experiences of our wonderful team at ReQtest.
Everything you will find here, every technique, process
or tool mentioned has been used by the members of our
team while we were building ReQtest. We return to them
even now, whenever were developing new versions of
our product.
In short, this ebook distils all the lessons that we have
learnt throughout the years and lays them out across
these pages for you to take and apply straight away in
your own projects.
I hope that what you will find here will help you and your
team work better together, as well as to deliver more
value with the products you create.

Sincerely,
Ulf Eriksson

Page 3

Table of Contents
Letter From Founder

5 tips to start writing better bug reports

Using agile test automation to avoiding runaway regression

What you DONT see is what you get

10

Why Agile automatically implies automated tested

13

17
The test leaders guide to troubleshooting distributed test teams
An introduction to exploratory testing

21

Did Agile make the test leader an endangered species?

24

14 requirements you should keep in mind for any system

28

The dark side of exploratory testing

33

8 simple ways to become a faster tester

36

5 tips to start writing

better bug reports

Page 4

Writing good bug reports is one of the main skills that a

tester has to master in order to establish his or her credibility
with the team. Poorly written bug reports which cant be
deciphered by the developers slow down the team and result
in loss of time, effort and resources.
In this article, we revisit a guest post written by Aleksis
Tulonen on our blog and distill his advice on improving your
ability to write better bug reports in five easy-to-practice
points.
You can find the original guest post by Aleksis Tulonen
here: Why testers need to be highly skillful at describing
bugs.
1. When writing a bug report focus on the most
essential details. These may include information
about configuration (e.g. browser, OS), a list of steps
for reproducing and attaching any files (e.g. screenshot,
video, log files) that will help programmers to reproduce
and fix the bug.
2. Dont spend too much time writing a report. Keep
your report short and simple so that you minimise the risk
of a programmer not understanding the report and failing
to reproduce the bug. Any extra time spent on report
writing is time taken away from testing and finding new
bugs.
3. Make it short but complete. You need to strike

Page 5
a fine balance between writing concise reports and
explaining thoroughly how to reproduce a bug. Failing
this will result in time spent discussing and providing
additional information about the bug. This can easily be
avoided by ensuring no important steps are omitted from
the bug report.
4. Maximise the information delivered. Layout
counts as much as content in making sure that the
information is grasped by the reader. Careless writing
is not an option since figuring out how to pack all the
relevant information in a reasonable amount of time
requires judgement and experience.
5. Ask for feedback. Surround yourself with people
who are not afraid to criticize your ideas. Fellow testers
and other professionals can help you devise better ways
to deliver bug reports; programmers can inform you
about the type of information they mainly look for in a
report and other testers can give you general comments
about the overall quality of your bug reports.

Conclusion
Finding and reporting bugs is not an easy business. The
report writing process involves various challenges that have
to be overcome and requires finding a balance between
the effort to provide all the essential information without
overwhelming yourself or the reader.
Although oracles and tools can help you to improve the quality
of the information you provide, in the last analysis it is you, the
report writer, who will make the final decision regarding which
information makes the cut or not.

Page 6

Using agile test

automation to avoiding
runaway regression
Adopting agile techniques for your software development
and maintenance needs is a popular choice among many
businesses, however, despite all the advantages that are
associated with being agile, there is one pitfall which sooner
or later theyll all fall into: runaway regression.
With each iteration, the amount of regression testing increases
as the amount of new code (and functionality) in the software
decreases whilst the proportion of original code increases.
Daily builds, especially, require the application of frequent
regression testing suites as the number of regression tests
increases from one iteration to the next.
The reason this happens is a wonderful demonstration of
Zipfs Law. The typical development sequence across
successive iterations demonstrates a pattern similar to this.
At iteration #2, about 1/2 of the total code is newly
developed with the other half being old code that requires
regression testing;
At iteration #3, about 1/3 of the total code is newly
developed with the other two-thirds being old code that
requires regression testing;
At iteration #5, about 1/5 of the total code is newly
developed with the other 80% being old code that
requires regression testing;

Page 7
At iteration #10 about 1/10 of the total code is newly
developed with the other 90% being old code that
requires regression testing.

The answer to this quandary is test automation.

Avoiding runaway regression

If you want your project team to survive a new agile
development in the sprint, a large number of the regression
tests you have running will have to be automated. Otherwise,
your team is going to be stuck spending most of their time on
manually testing old code.
In an ideal world, you want to save the manual testing for
features that are changed or newly-developed.

Page 8

Automation in major agile

development or maintenance
projects
A simple way to handle this is by having the various
development teams submit parts of their unit/component
tests to a single team that focuses on system testing.
This team can be considered as equivalent to the client, and
any code the other teams deliver to them has to have been
through the same readiness tests as if it were being delivered
directly to the client.
The system test team combines various tests into a context
that resembles the real-world functioning of the system.
As additional iterations add new functionality and/or change
whats already been delivered, the team adjusts the system
tests based on new unit/component tests created by the
development teams. In this way, development teams can
focus on coding and component testing the current iteration,
while system-wide testing is being taken care of by another
team.

Automating existing systems

When a larger system is already in play and youre going to
develop further certain aspects of its functionality, the simplest
way to go about this is usually by automating the systems
principal workflows.
Its not realistic or cost-effective to try and retroactively

2
Page 9
automate every test. On the other hand, it might be possible
to automate the regression tests youve identified at a higher
test level, which you might do with a recording tool.
Recorded regression tests can be combined with the tests
that the development team delivers to the system test team,
which adapts the recorded tests to include the new tests, so
that the entire system is tested again quickly and efficiently.

Page 10

What you DONT see is

what you get
Youre probably already familiar with WYSIWYG (pronounced
wizzy-wig), a computing concept which implies that what you
see on the screen will closely correspond to what the finished
product will look like.
But the quality of the end-product doesnt only depend on
what you see, the bugs you find and resolve, but also on
everything else youve missed.
This inattentiveness to certain elements in our field of
perception is known in psychology as perception blindness
and it the consequences of this quirk in the way our brain is
wired can be as frustrating as it is hilarious.
Watch the video below to see (or not-see) what I mean.
https://www.youtube.com/watch?v=vJG698U2Mvo

What kind of monkey business is

this?
There is a prodigious amount of information reaching our brain
through our field of vision at any given moment.
Researchers have estimated that our retinas carry about 10
million bits of information per second (boi/s) to be processed
by the brain, accounting for just over 90% of the total amount
of information that reaches our brain through all our senses

Page 11

combined. However, only 50 boi/s reach out consciousness,

with the rest being filtered out.
Although it may sound like an inconvenience, there are some
very sound evolutionary reasons why we have such a setup.
Your brain doesnt want to be overloaded so it only focuses
on what you tell it to focus on.
Filtering out the majority of the information coming through
and reconstructing any gaps using your memories is an
energy-efficient mechanism to have in place if it prevents your
brain from overloading all the time.

Why perceptual blindness can hurt

testers?
The problem lies here; perceptual blindness can and does
affect us in critical and dangerous situations.
Although testers arent likely to face any life-or-death
situations in their job, like astronauts or commercial pilots, the
details they miss can be the cause of costly mistakes which
could have easily been prevented.
But if perception blindness is hardwired in our psychology,
how can we mitigate its effects?
The answer, surprisingly, isnt in being more experienced in
handling our jobs. Studies have actually shown that experts
are more vulnerable at filtering out data that doesnt match
with their expectations; a finding which probably also explains
the phenomenon commonly known as beginners luck.

Page 12

No, the way we can combat perception blindness is by

feigning ignorance.

Fooling around
The ancient Greek philosopher Socrates, known as one of
the wisest persons in history, used to routinely embarrass and
frustrate his contemporaries by asking obvious questions and
generally making a fool out of himself by playing ignorant.
This technique, shocking as it may sound, is an excellent way
to attack any assumptions that cloud our perceptions and
judgement and help us see everything in a clearer light.
So dont be afraid to ask silly questions. Questions like:
Did we spell it right? It might uncover a couple of
terrible typos in the headers;
Is this the right address? Pointing your users to
yourwebstie.com instead of yourwebsite.com isnt a good
idea.
Other ways to reduce the effects of perceptual blindness
Apart from questioning the obvious, there are three other
methods you can use to combat perceptual blindness in
software testing:
Testing in pairs;
Communicate better;
Use cross-functional teams.

Page 13

Why Agile automatically

implies automated
testing
A tendency which has always struck me as odd is that where
people assume that agile development is simply restricted to
automating the component tests and unit tests; completely
ignoring automation at the levels of integration testing and
system-wide testing.
One reason why testers seem to resist automating testing
on all levels is that the system theyre working on is prone to
change very frequently from one iteration to the next.
Conducting the aforementioned tests manually affords a great
sense of control, however this sense of control comes at a
high cost of both time and effort.

Creating an architecture that

supports automation at every level
of agile development
I believe that the biggest obstacle that testers face when
automating systems in an agile context is the fact that it
requires a high level of maintenances and continuous finetuning in order to keep up with the constant changes that the
system undergoes.
Despite this obvious difficulty, automated testing still emerges
as the winner in the long-term as it is not possible to work fully

Page 14

in accord with Agile principles under any other circumstance.

In other words, automated tests ensure that the team can
achieve a sufficiently high test coverage in each sprint
and thus provide the high quality and rapid feedback that
characterise a truly Agile project.
An agile project without test automation is simply a waterfall
project in phases. It is practically impossible to conduct
regression test in each sprint if the tests are not automated.

What should be automated first?

It is easy to think that you should automate all regression
tests, and that it should be done immediately. However, this
is not economically justifiable; it is far better to automate the
process in incremental steps.
This process should occur in a strategic manner by
determining first and foremost a list of all the tests worthwhile
automating and then prioritising which tests should be
automated first.
There are many factors which determine what should be
automated first, including:
Business-critical functionality;
Functions that are used frequently by many users;
Configuration testing where tests will be run with
different configurations;
Test cases which will be run several times with different
test data or conditions;
Test cases where the expected result is obvious;

Page 15

What do I gain from test

automation?
The advantages of test automation are various.
Firstly, there is all the time that is saved when executing tests
automatically instead of carrying them out manually.
Secondly, test automation can lead to more exhaustive testing
since the same test can be applied multiple times with a
different data set and even under different test environments.
Finally, the principal benefits of test automation is that testers
can be more confident in the system and the overall quality
of testing is increased when more comprehensive tests are
performed.
All this makes it possible to improve and customize the
system to the needs of the product owner in full accordance
with Agile principles.

Page 16

Page 17

The test leaders guide

to troubleshooting
distributed test teams
More and more often todays test leaders have to contend
with managing teams that are connected together on a purely
virtual basis.
When your office is the whole wide world, leading test teams
can be a challenge of global proportions that can tackled
locally, right where you stand, by adopting the ReQtest teams
tried-and-tested techniques to manage distributed test teams.

Testers without borders

Although I believe it is truly amazing that you can tap talented
people no matter where in the world theyre based, leading a
distributed test team is not without its problems.
Among the difficulties that you are likely to encounter are:
1. Communication problems
2. Role ambiguity
3. Duplication of roles
4. Poor team spirit
5. Conflicting priorities
Ill tackle each problem in turn and I hope that by the end of
the article youll have a clearer idea on how to successfully
lead a distributed test team.

Page 18

#1 - Communication problems
When testers are spread across the four corners of the world,
maintaining open and effective communication channels can
be difficult to say the least.
Dealing with testers in different time zones can be tricky and
requires much patience and juggling of schedules. Having
different tools to cater for your teams communication is
crucial in this regard to ensure that the team functions as a
whole even though the members are separate in time and
space.
Tools for effective communication include popular ones like
Skype of Google Hangouts, as well as specific tools such as
ReQtest, that are designed purposely for testers collaborating
online on requirements management and testing.

#2 - Role ambiguity
The longer the distance a signal has to travel, the more
degraded it will be at its point of arrival.
The same concept roughly applies to decision-making in
teams. In distributed teams, people are more likely to take
the lead and take decisions independently of what the team
leader decrees.
In these cases it is essential to define the particular role of
each team member, as well as to clarify the hierarchy around
which the team is structured.

Page 19

Typical roles in a distributed team includes those of test

manager, testers, test environment manager and test data
manager, although these naturally differ according to the
magnitude and scope of the project.

#3 - Duplication of roles
A natural consequence of role ambiguity is role overlap, or
worse, duplication. Not only does this lead to wasted time,
resources and effort, it also breeds resentment in the team.
It is important to assign a person in every location the role
of test manager and delegate to them the responsibility of
coordinating with other managers and overseeing that their
team does not duplicate the work being done by another one.

#4 - Poor team spirit

Team spirit doesnt occur spontaneously; doubly so when the
individual members are based in different locations!
To foster a stronger team spirit it is important to dedicate
enough time to know the members on your team as well as
creating opportunities through videoconferencing and other
methods for members of teams in different geographical areas
to be aware of each others contribution to the project as a
whole.

#5 - Conflicting priorities
When testers are spread over a wide geographic area there
is an increased risk that the individual members may have

Page 20

conflicting priorities due to different styles of working.

A method to counter this eventuality is to draft a formal
contract which states what the team priorities should be and
how test resources should be allocated in order to satisfy
these priorities.

Summary
Having a geographically distributed test team can be a
challenging situation for any team leader, however any
difficulties that may arise can be easily avoided by proper
planning and troubleshooting any problems the moment they
arise.

Page 21

An introduction to
exploratory testing
Many people think that testing is boring and repetitive. I beg
to differ.
Testing allows me to dig deep into the thicket of code to
uncover bugs that need fixing, allowing me to use a range of
skills from the analytical to the intuitive.
You could compare our work to that of an archeologist. Or
a psychoanalyst for software! We go deep into the layers of
code to resolve the deep-seated problems that lie within our
product, thus helping it attain its full potential.
Thankfully, no cajoling or tears is involved -- apart maybe
from those of an overworked tester grappling with a bug that
refuses to be cracked.

Exploratory testing
Exploratory testing is a technique in the testers toolbox which
allows one to locate critical bugs earlier as well as stimulate
the creative and inquisitive side of the tester.
In a nutshell, exploratory testing involves running tests as
they are being created in order to become more intimately
acquainted with the system being scrutinised.
The concept of exploratory testing originated in the 1990s and
was developed by Cem Kaner and James Bach.

Page 22

The concept is easy enough to understand, although a certain

degree of skill is necessary to implement the technique well.
In the next section Ill provide a simple introduction to this
fascinating approach to testing software.

Putting it in practice
The first step before testing it to break the system down into
smaller parts in order to get a more comprehensive overview.
A list of all the areas of the system that need to be explore
should follow. Consider this as your map that charts the
territory youre about to explore. Its a good idea to include
an inventory of the testing tools that will be utilised during the
test.
Exploratory testing doesnt have a clearly defined outcome.
The point is the process being used. When using exploratory
testing, a tester will use alternative approaches to probe the
system and gather feedback from a 360 perspective.
Skilled testers arent content with testing a problem one. They
will retest using different methods, even regression testing,
to ensure that no new bugs were introduced in the system
following any changes they themselves affected.
Since exploratory testing uses a variety of testing approaches,
the best practice is to log the types of tests performed to the
system and the results obtained.

Page 23

Conclusion
Exploratory testing is an approach that taps into the abilities
of a testers in a holistic manner, putting to rest the usual
accusation that our profession is a monotonous one.
On the contrary, exploratory testing challenges testers to
expand their abilities and put into play all their skills not only to
solve a problem but to improve the end product.

Page 24

Did Agile make the test

leader an endangered
species?
Agile techniques have literally revolutionised the way we do
testing, yet nowadays theyre so widespread that we rarely
give thought to how they impacted the roles of the individual
members on the testing team, notably the test leader.
Scrum methodology have been a catalyst that flattened the
team structure and encouraged a more egalitarian distribution
of responsibility in the team.
In the face of these changes, I believe that we can no longer
skirt the issue. Is its time for a Testers Spring? Shall we do
away with test leaders or do they still have a distinctive role to
play in an agile world?

Anarchy in the UX?

Long before the user sets eyes on the final product, the
testers would have laboured long and hard on the product
over many iterations, usually by following a schedule that
roughly approximates the below:
1. The Product Owner briefs the team about the desired
functionality;
2. The Scrum Master ensures that the team members
follow the established approach;

Page 25

3. Team members select tasks from the Scrum board

and work on the current sprint.
As you can see the team seems to have done swimmingly
despite lacking any recognisableleader figure. Therein, I
propose, is the answer to the question posed by this article.
The team lacks any recognisable leader figure.
But what if everyone is simultaneously a leader and nota-leader? What if the leader manifests within the cognitive
processes that collectively characterise the team while picking
their tasks and carrying out their job.

Schrdinger revisited: The

paradoxical leader
Underlying the seemingly odd conclusion that the leader both
exists and doesnt exist in an agile team is the observation
that any team of testers, provided their adequately trained in
their professional, will behave in predictably rational way when
facing the Scrum board.
Consciously or not, the testers have employed their own
leadership qualities in strategically selecting the tasks to
execute in the sprint. The testers have effectively taken on
duties that normally are performed to a test leader.
Essentially, team members carry all the duties that a test
manager normally carries out when are in a more formal, less
Agile team.

Page 26

Leaders (still) wanted

So has the traditional leader figure gone the way of the dodo?
Not quite. In the examples above I only considered scenarios
involving one testing team. The situation is different when
parallel teams are working on a given project or the project
involves a distributed team spread over a wide geographic
area. When it comes to testing in agile contexts, testers
typically lead themselves. When it comes to specialized test
types, such as performance testing or usability testing, these
tests are led by someone who is appointed leader for this
situation, typically one of the testers.
In bigger teams, the complexity of the group dynamics and
resource management involved increases exponentially. In this
cases having a traditional leader figure (even more than one) is
essential to maintain a coherent team effort.

We are all leaders!

I think its an encouraging sign of maturity in our professional
that leaders and followers have converged in a unique
individual that can independently carry out his job while
coordinating with fellow team members to advance the
project.
However, lest readers think Im suddenly writing self-help
articles on our blog, I believe I should qualify my conclusion a
bit further.
At any given moment in a team there is always somebody
taking the role of the leader. What I suggest is that rather than
being fixed, agile methods have made the leadership more

Page 27

malleable and team members can step in and out of that role
depending on the group dynamics and circumstances.
When someone distributes work between what is internal
team work, reports the results of testing, puts up the strategy
for test work and plans the order in which the work should be
carried out, that someone would rightfully be called the test
leader.
What is different in an agile context is that from one task to
another, a different someone may be leading the team and
that there can be as many leaders as there are decisions to
be taken within the team.

Page 28

14 requirements you
should keep in mind for
any system

Its probably impossible to compile a list of every possible

requirement that applies to a given system, however we tried
to come close with this list of 14 requirements that you should
never overlook.
As with any requirement, implementing too late increases
development costs. Using this list as a starting point and
supplementing it with your own experiences will help you write
more comprehensive and complete requirements.

#1 - System shut down

A system needs to be turned off for both emergency and
planned downtime. Ideally, the shutdown process should
provide the system administrator with a simple way to
minimize errors that would arise if shutdown were a manual
process. What information will the system display to users
when it is going to be taken down or already is down?

#2 - Permissions
Who should be allowed to see or change what data? What
happens when a user tries to use the features that he
does not have access to? Can you see features youre not
authorised to use, or are they hidden? Who should administer
permissions and how will they do it? All of these are questions
you need to ask.

Page 29

#3 - Error messages
Remember to specify where the error messages are to be
displayed. Do they use a message box or do they notify users
in the programs status bar? Error messages are very rarely
specified in the requirements, but without this requirement
in place, theyre often written by developers and that could
cause the system to display messages that are hard to
understand for end-users. Without requirements, messages
will probably not even have been tested, which can result in
bad usability.

#4 - Alarms when failures occur

When errors occur, the system should log the error and
contact operational staff, the maintenance manager or
an equivalent. The great advantage of making the system
send an alarm is that errors become more obvious and
conspicuous, so the administrator is more likely to take action.

#5 - Logging errors
Its much easier to troubleshoot the system if it records the
details of each error to some type of log. This is especially true
in the production environment, where its not possible to use
development tools for troubleshooting. Often its worthwhile to
log more than just the error itself. For example, you might log
all calls to all functions, since the error might have occurred
because the calls were made in the wrong order.

#6 - Handling overloads

Page 30

What happens if the system gets overloaded? Do you

automatically roll back transactions in case of overloads?
Does the system show an error message? Should the system
shut down automatically? Think of the consequences and
perceived risks of any of these choices and choose well,
before overloads start happening.

#7 - Managing high volumes

High usage volumes is something you need to think of and
plan beforehand. Ask yourself the question: Will there be
times when the system has to deal with a large number of
users doing more things than usual? Think of and plan these
things beforehand!

#8 - System integration/
connections
Develop a traceability matrix that shows which test cases
or test areas are affected. Are there sufficient requirements
specified for these relationships?

#9 - Things the system must or

must not do
There are things which any system must not be allowed to do.
Have you identified all the situations of this kind? Are there any
exceptions to normal handling rules? Make it a habit of asking
yourself: Will this be valid in every case?

Page 31

#10 - It should be easy to

implement changes
After you launch any new system, youll probably find a
multitude of minor defects that you want to correct. Make
sure the architecture supports simple changes so that you
dont have to recompile the entire system to make simple
fixes such as changing the text of system messages.

#11 - Requirements for

documentation
Many systems are expected to be up and running for years.
Determine what documentation will be required for future
teams to maintain and operate the system cost-effectively.
Determine early on what kind of documentation the system
owner expects.

#12 - Identify implied and expected

requirements
Implied requirements are easy to overlook, specifically
because they are not expressed by definition. To find them,
you have to read between the lines, imagine yourself in the
users shoes, and generally think outside the box.
Expected requirements, on the other hand, are the ones that
the client expects but thinks are so obvious that one doesnt
need to specify them. For example, customers dont usually
tell you that they need and existing functionality to continue to

Page 32

operate or to only be changed if they request it.

#13 - Reports
Are there any reporting requirements or other ways to extract
data from the system? How often will reporting happen, who
will carry it out and what metrics will they need to extract? Is
there any delay in reporting data being populated?

#14 - Legal requirements

These requirements should never, ever be forgotten. Failing to
adhere to this will result not only in lots of extra work, but in
some cases, legal liability. Do your research diligently and get
a professional opinion when in doubt.

Page 33

The dark side of

exploratory testing
Ive covered exploratory testing extensively and, one might
say, enthusiastically in this book.
Little wonder though. I think that exploratory testing offers an
alternative perspective to software testing that is diametrically
opposed to the dreary picture of our profession that is painted
by the critics.
However, lest people accuse me of providing a onedimensional description of exploratory testing, I will dedicate
this subject to exploring the pitfalls that testers are likely to run
into when using this approach.

Lets get this straight

Exploratory testing is more of an approach to testing, rather
than a technique in itself. When testers use exploratory testing
they strive to constantly modify the tests they apply to the
software in response to the real-time feedback they gather
from the previous test.
Thats right. No test cases.
Exploratory testing is the Zen way of approaching
software testing, with the tester freeing his mind from any
preconceptions and attending only to the data presently
available (see Mushin).

Page 34

In recent years, the term exploratory testing became one

of the more popular buzzwords in the testing world. The
benefits of exploratory testing are many but success is not
automatically guaranteed.

The challenges of exploratory

testing
#1 - Lack of structure
One of the major challenges of exploratory testing lies
precisely in its biggest strength: the lack of structure.
Whereas a more traditional tester will follow the test
specifications, write test cases based on them, execute test
cases and write bug reports, a tester who uses an exploratory
testing will not be able to depend on this information.
Instead, the tester will have to figure out which tests to carry
out on the spot as well as which aspect of the system to
analyse next.

#2 - Lack of feedback
Exploratory testing uses documentation just like the traditional
way of testing software, however the information contained
within it is qualitatively different.
The documentation in this case will only report the findings
from the tests carried out by the tester and as I mentioned
earlier, it is at the testers discretion as to which tests to apply.

9
Page 35
In practice, this means that the documentation could fail to
report any bugs whatsoever because the tester failed to use a
test which revealed any.
Of course, a tester may feel hard-pressed to justify the lack of
any bugs! After all, finding them is his or her job.

#3 - Lack of clear outcomes

Exploratory testing can sometimes be very ambiguous as it
sometimes fails to provide any clear results.
This may cause resentment within the team, or suspicions
that the tester is not carrying out his or her job properly.
Too high expectations from exploratory testing can interfere
with the ability to the tester to utilise a creative approach,
preferring instead to revert to a more structured way that
defeats the purpose of exploratory testing.

Summary
Achieving exploratory testing that is both successful and fun
requires a lot of work.
The less interest from the organization in supporting this
riskier approach to testing, the harder the tester must work
to justify using this method.
In this cases, the testers have to mount an argument in favour
of exploratory testing. My previous articles about exploratory
testing on our blog can help you formulate points in support
of exploratory testing, as well as balancing that out with the
pitfalls that are outlines here.

10

Page 36

8 simple ways to
become a faster tester
Here at ReQtest were all about efficiency. We work hard to
trim off the fat and fine-tune our testing process to be as lean
as possible.
But efficiency shouldnt come at the cost of effectiveness.
Our lean testing machine must also be mean enough to tear
through any testing situation.
In my experience of continuously working to improving the
testing process, Ive noticed eight simple changes that boost
tester efficiency without compromising on the quality of their
work.
Check out the eight points below to find out how you too can
shift gears and start blazing through testing.

#1 - Write fewer test cases

Less is more. As counterintuitive as that may sound, I noticed
that there tends to be a great deal of wasted effort among
testers who insist on going overkill when writing test cases.
Instead, write enough test cases for what is really necessary.
Speed up the writing process by reusing test cases as
templates.
Apply the just in-time approach and add test data just before
test execution. Test data needs to be fresh and should

10

Page 37

therefore never be hard-coded in the test case.

Another time-saver is to only write something in the expected
result field when the result is not obvious.

#2 - Shorter test cases

Simplicity is the basis of a more efficient approach when
writing test cases. Like any good writer, avoid long pieces
and split up your cases into smaller subtasks which can then
be combined in practice during the test-run. Writing separate
pieces will also make it easier to update test cases if the
system changes.

#3 - Tailor test case forms to your

work
If youre using a program like ReQtest you can easily forms
templates for test cases and bug reports so that any
redundant fields are avoided and time spent on filling these in
spared.
If there are fields in your form that you havent used for a
while, consider striking them off from the form. Again, ReQtest
makes it very easy for testers to hide and restore fields
according to their needs.

#4 - Checklists are your friends

Using a checklist is an easy way to keep track of the
activities that have been completed and those that are yet to
be done.

10

Page 38

Keep pen and paper nearby to jot down any points, or if you
prefer to go paperless, make use of a program like ReQtest
that lets you create checklists that integrate seamlessly with
your workflow.

#5 - Tell a story
We all like a good story. A typical user opens a program
Maybe the punchline to that opening wont result in a belly
laugh, but writing requirements in the form of user stories is a
very time-efficient alternative which will give you more time to
head to the bar later and swap some real jokes!
If user stories are used for requirements, you can become a
faster tester by writing acceptance test cases sooner, as soon
as the user story is done. This helps you finish the job earlier.

#6 - Exploratory testing
We have spoken about exploratory testing several times
on our blog, so check out our previous articles to learn
more about it and how you can start applying it to your job
today. Checklists and exploratory testing are a very effective
combination to ramp up productivity.

#7 - Carry out usability tests

Usability tests are a great way to gather feedback from an
early stage and make timely changes. Use mockups and
prototypes before the project starts sinking underneath the
weight of all the code that will go into it.

10

Page 39

#8 - Repeat. Repeat. Repeat

Iterating in short cycles makes far more efficient use of time
than working over an extended period. Although this might
not always be feasible, breaking down a big project into
smaller, more manageable tasks helps you work faster.

Testing at the speed of light

Do you already use any of the tips mentioned above? How
did it work out for you? Tell us what your favourite productivity
hacks for testers are in the comments section below.

10

Page 40