Slides and follow-up material from all CAST presentations are available through the CAST 2007 wiki.
Software testing is tough. It can be exhausting, and there is rarely enough time to find all the important bugs. Wouldn't it be nice to have a staff of tireless servants working day and night to make you look good? Well, those days are here. On Thursday, March 22, I'll give a lunchtime presentation titled "How to Build Your Own Robot Army" for the Quality Assurance SIG of the Software Association of Oregon.
Two decades ago, machine time was expensive, so test suites had to run as quickly and efficiently as possible. Today, CPUs are cheap, so it becomes reasonable to move test creation to the shoulders of a test machine army. But we're not talking about the run-of-the-mill automated scripts that only do what you explicitly told them. We're talking about programs that create and execute tests you never thought of to find bugs you never dreamed of. From Orcs to Zergs to Droids to Cyborgs, this presentation will show how to create a robot test army using tools lying around on the Web. Most importantly, it will cover how to take appropriate credit for your army's work!
The first-ever industry Developer-Tester/Tester-Developer Summit was held at the Mountain View Googleplex on Saturday, February 24th. Hosted by Elisabeth Hendrickson and Chris McMahon, the all-day workshop consisted of experience reports and lightning talks including:
Al Snow - Form Letter Generator Technique
Chris McMahon – Emulating User Actions in Random and Deterministic Modes
Dave Liebreich – Test Mozilla
David Martinez – Tk-Acceptance
Dave W. Smith – System Effects of Slow Tests
Harry Robinson – Exploratory Automation
Jason Reid – Not Trusting Your Developers
Jeff Brown – MBUnit
Jeff Fry – Generating Methods on the Fly
Keith Ray – ckr_spec
Kurman Karabukaev – Whitebox testing using Watir
Mark Striebeck – How to Get Developers and Tester to Work Closer Together
Sergio Pinon – UI testing + Cruise Control
There were also brainstorming exercises and discussions on the benefits that DT/TDs can bring to organizations and the challenges they face. Several participants have blogged about the Summit. The discussions continue at http://groups.google.com/group/td-dt-discuss.
If you spend your days coding and testing, try this opening exercise from the Summit. Imagine that:
is a spectrum that has "Tester" at one end and "Developer" at the other. Where would you put yourself, and why?
Posted by Harry Robinson, Software Engineer in Test
Several readers have commented that our current blog slogan, "Life is too short for manual testing," implies that we don't value manual and exploratory testing. In fact, we are big fans of exploratory testing, and we intended the message to be liberating, not insulting.
Manual testing can find bugs quickly and with little overhead in the short run. But it can be expensive and exhausting in a long project. And manual testing is gated by how fast and long humans can work. Running millions of test sequences and combinations by hand would take longer than most people's lifetimes - life is literally too short for manual testing to reach all the bugs worth reaching.
We originally featured the "Life is too short ..." slogan on T-shirts at the Google London Test Automation Conference. One theme of that conference was that it makes sense to get machines to do some of the heavy lifting in software testing, leaving human testers free to do the kinds of testing that people do well.
If you'd like to find out more about computer-assisted testing, check out the LTAC videos as well as Cem Kaner's excellent STAR 2004 presentation on High Volume Test Automation . And if you can wait a bit, I will be doing a talk on "The Bionic Exploratory Tester" at CAST 2007 in Bellevue, Washington, in July.
I asked Jon Bach 's opinion on the slogan, and he suggested that what we are really trying to say is:
Life's too short to only use an approach for testing that relies solely on a human's ability to execute a series of mouse clicks and keystrokes when the processing power that makes computers so useful can be leveraged to execute these tests, freeing testers from especially mundane or repetitive testing so that their brains can be used for higher order tests that computers can't do yet.
I agree, but it would've been a heck of a T-shirt. :-)
Future slogans:
Testing is about being willing to try different approaches and entertain different perspectives, so a single slogan can't do it justice. We are planning to feature different slogans on a regular basis, and already have a few of our favorites lined up. If you've got a slogan to share, we'd love to hear it. Post it in the comments below or email us.
On Saturday, February 24, the Mountain View Googleplex will offer hospitality, support and free munchies for the first-ever "Developer-Tester/Tester-Developer Summit" -- a peer-driven gathering of developer-testers and tester-developers from around the industry to share knowledge and code.
The Summit is being organized by Elisabeth Hendrickson of Quality Tree Software and Chris McMahon of Lyris Technologies, who describe the day this way:
Our emphasis will be on good coding practices for testing, and good testing practices for automation. That might include topics like: test code and patterns; refactoring test code; creating abstract layers; programmatically analyzing/verifying large amounts of data; achieving repeatability with random tests; OO model-based tests; creating domain specific languages; writing test fixtures or harnesses; and/or automatically generating large amounts of test data.
Check out this post at Test Obsessed to learn more about the inspiration behind DT/TD and how you can participate.
