Justin Harrison and I recently attended CAST – the Conference for the Association for Software Testing, and over the past week as we got back into the flow after our time away, a few things stuck with me and got me thinking – a good sign after a conference!

I have a bunch of random takeaways that I’ll share by and by, but the session that made perhaps the strongest impression on me was the session that started with a “Trigger Warning.”

At a typical conference, attendees spend their time trying to absorb the latest best practices so we can get back to the home office and try and finally solve everything.  A session I went to called “Explaining Testing with Exercises” by speaker Matt Heusser threw best practice out the window.  He began with a slide that read “Trigger Warning.”

At first I couldn’t be sure if he was kidding, and he assured us he wasn’t.  The basic idea of the session was to actually test a very simple website, but under far less than ideal circumstances.

Heusser explained that even though this exercise was supposed to be FUN, participants in the past had reported genuine feelings approaching PTSD as the exercise took them immediately back to their own memories of bad experiences in terrible work environments on awful projects.  That said, and given the chance to leave, no one did, but it put the audience on edge –what was about to happen here?

What happened was an exercise in which testers were rather roughly asked to test a simple website, with no requirements, no documentation, minimal access to a developer, access to a disinterested and impatient Product Owner, and oh yeah, it has to ship tomorrow!

The speaker, Matthew Heusser was a skilled devil’s advocate, playing the role of the evil (but plausible and realistic) boss constantly asking, “are we ready to ship?”

Some of the attendees DID feel their blood pressure rise and said so. They said,  “We don’t like this, and we don’t like working here!”  At the same time, they also added a ton of value to this demo product even under terrible conditions.   In the ongoing TESTERS vs DEVELOPERS saga (the cats and dogs of software), the exercise helped demonstrate just how much testers add to the quality of releases, even without best practices, even under lousy conditions.

The exercise seemed to strike a balance between practice – testers doing what they’re trained to do – and striving for perfect practice. Heusser seemed to at once encourage testers to suck it up in terms of their roles in the process while highlighting how much value they really add.   Testers in this exercise quickly found lots of bugs both obvious and hidden, and they demonstrated that they would make the product better.  We saw that testers don’t need to work under optimal conditions to add a lot of value; management and developers need to recognize the value of this skill set.

More interesting perhaps was the way people in the exercise reacted to being told, “Hurry up, hurry up!” In this environment, they were willing to raise issues, but they were not interested in dying on the hill of principle for a manager who didn’t seem to care very much about quality.  No one was really interested in “going to see the VP.” 

My takeway was that testing (working?) in an environment where a lot is demanded of us IS STRESSFUL; people on the team need to believe leadership cares about quality. It has to be worth it.

This session worked on a few levels:

• Working through a problem teaches more than sitting through a lecture.
• Working in adverse conditions ultimately improves skill.
• It is very difficult to stick to your guns when you’re not supported by those more powerful in the organization.
• The more technically savvy a tester is, the stronger their position is, and the more powerful their advocacy will be.