|
|
Manual
testing is
the oldest
and most
rigorous
type of
software
testing. In
this
particular
type of
testing,
test cases
are designed
and reviewed
by the team
before
executing
it. There
are many
variation of
this basic
approach,
test cases
can be
created at
the basic
functionality
level or
they can be
created at
the scenario
level. |
Value of the scripted
testing has been questioned
by many experts in the field
and they consider scripted
testing as a waste of
resources, in most of the
situations. They claim that
scripted manual testing
closes the mind of tester
and inhibit them to use
their creativity. Also, this
approach is very heavy on
the documentation and
require considerable amount
of resources to create the
test scripts in the first
place and they often get out
dated because of the
inevitable changes in the
system.
Despite these drawbacks,
manual scripted testing is
used in many organizations
of all the sizes. They make
test cases repeatable and
easy enough for a new person
to come on board and start
testing with minimum
supervision. Manual scripted
testing is also used in
places where contractual
agreement states that
written specification of the
software must be met for the
successful implementation of
the project. Scripted test
cases might be useful where
tests are used for the
benchmarking purpose and
tests have to be executed
exactly in the same way,
every time.
Since in manual testing test
cases are created
beforehand, it can be
assumed that testers have
knowledge of the system. In
most of the cases, this
knowledge is often
theoretical, and various
documents like requirement
documents, functional design
specifications and so on
become the primary source of
information for the testers.
Effective testers working in
this type of scenario can
use supplementary sources of
information to increase
their knowledge of the
system by discussing with
development team, by
comparator product or by
earlier knowledge of testing
similar system and so on.
This type of testing is
mostly seen in places where
a waterfall methodology
along with the V-Model is
followed. This approach is
also suitable for projects
where requirements are
frozen and likelihood of
changes in those
requirements is very
little. This might also be
suitable for the situations
where safety or regulatory
situations demand proof of
testing in this particular
way.
Generally, this approach is
considered old and is
relevant in very little
situations in the current
era of market driven
applications.
Organizations following
this approach must evaluate,
if there are any compelling
reasons to use this
particular approach over
others. If they struggle in
finding the answer, may be
there is a need for change.
|
