Testing has been part of the secret sauce at VPS since we got started in 2002, and while it may be a bit boring, we maintain that QA pays for itself. Working on Appian development projects, our testers stand out in that they are familiar with Appian and can go
A message from the CEO If you’re like us, you’re had enough of winter and you’re looking forward to spring. This spring, we’re looking forward especially to Appian World, coming up on April 23rd-25th in sunny Miami. As an Appian Trusted Partner, VPS is excited about sponsoring Appian World for
I got tipped off to this podcast at CAST.
“Join your faithful host James Pulley and special guests every week for analysis on globally crashing websites and system failures while he reviews the disastrous sins of the evildoers in the IT department…”
The show is called NEWS of the DAMNED!
Listen for a few IT-flavored chuckles and learn about Performance Testing via a series of cautionary tales!
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.
CAST 2017 is the Conference for the Association of Software Testers. The conference this year is in Nashville, August 16-18th.
Our Lead Performance Tester, Justin Harrison will be a featured speaker, presenting his talk, “Just What do Performance Testers Do, Anyway?”
See our CAST Podcast here!
For the past few years, both on customer projects and also on internal development projects, we have used the Agile Methodology* I add the asterisk because no one seems to agree on what exactly agile should be, and no team I’ve ever seen (even within an organization) does it the