Smart Contracts

Updating Solidity code and Testing a Smart Contract

Books on the Blockchain

Publica Self Publishing

Goodbye Contracting

Hello brave new old world...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Sunday, 9 September 2007

Configuring Test Environments

Read the paper on Configuring Test Environments

"It works on my machine!", I'm guessing there are many test professionals who've heard this too many times for it to be funny. The problem we usually encounter though is that we wander over to the developers desk only to discover that ... it really does work on their machine.

The other version of this is 'the customers are finding bugs, how did you miss them?'. Now, having overcome your desire to beat the crap out of them for asking that ill informed question, you might run their test case and find a bug. At which point you'd be well advised to review the way you test cases are writen, the steps they include or functionality they cover. But what if you can't reproduce the bug?

Deep joy, it happpens, but why do these situations happen? Simply put there's something different. That something might be test data, the software version, hardware, the testing algorithm your steps present , who's to say. The main thing is you need to know what that something is.

The easiest way to do that is have as many elements affecting testing defined in advance of encountering issues. Easier said than done? Actually reasonably easily done, you just need a sensible and considered approach. The approach when I'm setting up a Test Function is outlined in my paper, Configuring Test Environments, an approach that brings many benefits.

It's abstracted from ITIL and has proven very valuable in helping to be assured about the status of the environment in which software is tested. Assuming there's good software configuration happening your walking in the park...

Mark Crowther - Optimus Configuratus