Want to
read a case study
One
CPU is better than two
and biography of the
author
Patrick Martin
|
|
Introduction
This is
the
introductory article to
a series
of
occasional
articles
related
to
testing,
from the
perspective
of a
developer.
These
articles
are
intended
to pass
on some
simple
techniques
to help
a QA
team to
debug
and test
application
application
builds.
In many
instances
these
will be
the
kinds of
technique
that
might
also be
used by
developers
during
development
or even
for
debugging
customer
issues.
|
What we aim
to do
Pass on examples of high
bang to buck tips in the
most digestible format.
In some cases this will
be in the form of a case
study that aims to
illustrate a key
concept; this kind of
format helps exposition
by having multiple
"bites at the cherry" to
get a key rule of thumb
across. Everyone
understands differently;
the aim should be to try
all the possible routes
in.
In other cases what is
required is a very
simple exposition of a
technique that is often
overlooked or not
handled imply enough to
extract all the latent
value. This may often be
as simple as reading the
manual of a well known
tool with a focus on the
task in hand. Some IT
administrators would
find these articles very
familiar.
What we don't aim to do
To tell you how to
test/debug/fault
find.
What we
aim not to do Write test
tools for you that you
will use: the aim is to
choose examples where
the understanding is the
key point: the simple
technique to illustrate
the point should be
simple in case you need
to modify it to fit your
purpose or replace it
with something else.
Overview
It is a fact of
life that
development
teams and QA cannot
explore every
scenario during
application
development for a
number of reasons.
Quite
often developers and
internal users are
on a homogeneous set
of Operating
Systems; some build
processes only work
with administrative
rights and are
incompatible with
the customers'
profile; influencing
environmental
factors are present
only on the end
users' machines.
In short, there will
always be a role for
QA and in the field
fault finding, and
this series of
articles will be
about boosting your
arsenal of tools to
help get to root of
certain archetypal
development issues
as quickly and
precisely as
possible. The
benefit of boosting
the arsenal is that
quite often what
starts out as a
field test for a
problem can become a
self-test or a
regression test and
thus the virtuous
circle of improving
the QA process can
be completed.
In a number of
environments there
is a quite complete
and consistent set
of testing and
diagnostic tools:
Java is an excellent
example of a field
where there are
tools that are both
freely available and
very accessible.
One of the areas
that is somewhat
inconsistently
served for testing
that of native code
applications for
Windows: the reasons
for which might make
of an interesting
article. Nonetheless
there are many many
excellent tools
which are typically
much under-used.
In this series we
will focus on issues
affecting Native
Windows
applications:
partially through
necessity as the
author's experience
is primarily in this
realm, and partially
because we perceive
a genuine and
significant gap
between existing
capabilities and the
take-up by users.
The tools presented
will in general be
compatible with a
wide range of
Microsoft operating
systems: we aim to
have some kind of
support from NT4 to
Windows Server
2008.
As it is our belief
that testing is
intimately linked to
the development
process, we will
also focus on a
number of tools that
*should be*
indispensible parts
of the testing
process:
There are
many tools available to
choose from, some of
which can be an
all-encompassing
solution. However in
these articles we will
strive to either:
Hopefully
the last recourse will
be rare, else the
fundamental premise of
the series is in
doubt...
And
without further ado: on
to the series - hope to
see you there!
|
