Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Using Exploratory Testing in User Acceptance Testing

January 18th, 2008 · No Comments

I recently got involved in an email list discussion about exploratory testing. I thought I’d post one of my comments here:

I think it’s worth noting that for most terms there is a difference
between practice and theory in the way they are used. So, while I
call the part of my projects (I’m a PM BTW, for those who don’t know
me) where users come in and test UAT, the purpose of this testing is
to BOTH find bugs and determine whether they accept the product,
never mind the literal meaning of the words behind the abbreviation
UAT. I have found that exploratory testing is extremely effective for
both of these activities. Real users who have been trained in
exploratory testing are able to find bugs very quickly – usually in
the first two or three days of UAT. They also very quickly develop an
opinion of whether or not the product is shippable.

This works for my projects. Here are some reasons why:
– My pool of testers is very friendly towards me. They report to my
business partner, who fully supports my often-controversial approach
to project management.
– I have considerably lengthened UAT to give us time to fix defects
(I get away with this by shortening functional testing).
– UAT testers don’t come out of my project budget. This is an oddity
that may be specific to my situation. As a result, my projects cost
less if real users do the bulk of the testing.
– Finding a bug in UAT is not a bad thing for my projects. Everyone
is on the same page in this regard.

The truth is, my “UAT” is really functional and acceptance testing at
the same time. While this may not meet the typical testing model, it
works very effectively for me. In fact, I have typically taken more
time off of functional testing than I add to UAT, which means
schedule-wise I am better off. This works because I have a rather
large pool of very cooperative UAT testers to draw from, and
typically only have one or two functional testers available to me
(who I have to pay for).

I am convinced that this approach would not work for many projects.
Here are some situations where I think taking my approach would be a
horrible mistake:
– When contractual obligations regarding the software are being tested
– When your UAT testers don’t like you
– When your business partner freaks out if you find bugs in UAT
– When you don’t have time to fix bugs you find in UAT
– When you need to test something very technical about the product
that cannot be verified functionally

In theory, I suppose, what I do may be considered a really bad thing.
But in the context of my world, it has been tremendously effective.
My production launches have been fantastic – we rarely get bug
reports from the field since we started this approach, and my
projects tend to end more quickly.

I guess the point I’m trying to make is that sometimes the
distinctions between terms are not that important. Sometimes they
are. You need to be able to tell the difference and not make
assumptions about the types of activities going on at a particular
point in a project just because it has a particular label or because
it’s using a particular approach. You can argue that UAT is only for
determining whether a product is contractually finished or not, or
that exploratory testing is only for finding bugs, but if that’s not
the way a project is doing it and it’s working for them the academic
distinctions aren’t particularly important if they are limited to a
single implicit context.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Agile

0 responses so far ↓

  • There are no comments yet...Kick things off by filling out the form below.

Leave a Comment