[TIP] Web Application Testing Code of Ethics?

C. Titus Brown ctb at msu.edu
Thu Nov 20 06:52:27 PST 2008

On Thu, Nov 20, 2008 at 01:37:56AM -0500, Noah Gift wrote:
-> The web is a weird world, because of the mixture of technologies, like PHP,
-> javascript, ruby, python, perl, actionscript, etc, that are often quick and
-> dirty functions in a couple of files.  I have a friend that has to deploy
-> applications quickly for many of these languages, it isn't me I promise :),
-> and he often finds that a developer tells him.  Oh, it works, don't worry,
-> just update the production site...and do it NOW!
-> About 50% of the time, things break, when he goes to deploy, and it turns
-> out to be a hardcoded database password that is wrong, absolute paths, and
-> more.  Other than telling this guy to get another job, which is probably a
-> wise move, is there a commonly accepted minimum level of testing that a web
-> developer should ethically subscribe to across all languages?
-> If I was in his position, I would tell the developer(s) that routinely give
-> him broken web apps that they were poor developers for not including at
-> least some basic tests.  These could even be minimal, like a script that
-> connects to the database and tests a couple of URL parameters for example.
->  Is there anything I could point him to that could help convince the CTO and
-> developers at this company that testing is just ethical?

Layering additional requirements on people (whether or not you tell them
that they suck first) generally doesn't work unless you're in a position
of power, and even then they often find a way around your requirements.
So I think it's unlikely to work well.

Why don't you tell your friend to build some simple smoke tests --
using Selenium or twill, for example -- that exercise the deployed
site(s)?  Then he can figure out quickly and easily if things are

Another strategy might be for him to set up a simple staging environment
on his own and deploy things there first; that would let him break
something other than the production site.  If he automates the
deployment from staging -> production and also automates the test
running, then he'll be just as fast when it all works but he won't
deploy broken stuff.

Both of these strategies duck the systemic problem (developers not
testing) but make it easier for your "friend" to do a good job.

C. Titus Brown, ctb at msu.edu

More information about the testing-in-python mailing list