My TestBash Hangover Remedy - A Recap
I've returned from TestBash 3, a “one day affordable software testing conference in Brighton on Friday March 28th 2014.” I have to say it was, without a doubt, the highest quality, content rich, energetic, lively, best attended, most educational and fun one day testing event I have ever attended – and I’m not just saying that because I had the honor and pleasure of being the opening speaker for the event!
Okay, you’re right, that’s a bold statement to make without any supporting information (especially with my potential bias). How ‘bout I summarize what you missed and let you decide for yourself.
First off, check out the schedule of events:
Okay, the pre- and post- meetups and Lean Coffee are fairly common, but a run and a morning after “brunch”?! That’s pretty exceptional.
I admit that due to my somewhat insane travel schedule, I was only able to attend Lean Coffee (which was standing room only), the actual event, and the after party (which I left early at 10 p.m.), but I’m told that the rest of the events were quite well attended as well. That’s some dedication… especially for locals!
Lean Coffee was fantastic. Honestly, I think folks would have kept working on their “Agile Testing Exploration Exercises” for at least another hour before they noticed that the actual event start time had come and gone had it not been for event volunteers rounding them up to move to the auditorium.
It really wasn’t until I stepped the stage after the opening announcements that I really grasped just how many people were there. I was expecting to see 50 attendees - 75 on the upside. To my surprise, there were 250 energized and enthusiastic testers there – which made my job as opening speaker easy because instead of having to try to “wake up and energize” the audience, it was already teeming with energy before I said a word. And that energy didn’t wane a single time throughout the day.
What about the speakers?
The first thing worth noting is that, of the 10 scheduled speakers (all in a single track), no fewer than five of them have delivered keynote addresses previously at “well-reputed” conferences. And based on the deliveries from the other five, I’ll be surprised if I don’t see all of them speaking more or less at their conferences of choice in the future. I’d even be willing to bet that two or three of them get high profile keynotes in the next year or two. If you follow conferences at all, you know how rare that is. And it’s not just that these are good presenters, they all really brought their “A” content to TestBash 3. Here are some highlights:
Managing Application Performance Throughout the LifeCycle
This is an educational, experiential and often amusing introduction to my “Target, Test, Trend, Tune” approach to getting the whole team involved in delivering performant applications. If Twitter is to be believed, the highlights of my talk were:
Contextual Decision-making in Testing - Apathy or Indifference?
A fabulous talk about neuroscientific lessons that show just how biased testing can be if we aren’t active in preventing bias by employing apathy (Illustrated with an animation of a cat that spins clockwise… and counter-clockwise… concurrently! In my opinion, I think this cat might even have Schrödinger’s Cat beat in terms of brain bending “weird”). My key takeaways were:
- Understand, pay attention to, and account for
- Known, Knowns
- Known, Unknowns
- Unknown, Unknowns
- Know when “You must unlearn what you have learned.”
- Realize that even things that look like math have context. For example, in certain contexts, each of these are valid and correct equations:
- 1+1=love (3 or more!)
- Sometimes “apathy” improves our ability to explore the unknown. In other words, know when to let go of your biases & pre-conceived notions.
How to win [Developer] friends and influence [business] people
Jez proposed that developers and business people both know that testing is “the right thing to do” and something that “should be done” but can’t quite tell you why, thus making it the testers responsibility to figure out how to speak a language that these two different groups understand. My favorite quotes from this talk were:
- “Getting testers involved early to understand the business in startups is important in helping target the right value”
- "Asking developers to test is like asking a teenager to tidy their bedroom"
- “pretty graphs can help to change behavior” and
- Who’d say no to reducing stress?
Helping the new tester to get a running start
Joep spoke from his own experience about getting new testers up to speed quickly using the analogy of learning how to navigate a new city. Interestingly, through this analogy, he pointed out that many of the most common ways to get a new tester up to speed fall short. Of course, he concluded by sharing some alternatives that may be better. Some gems from this talk:
- When you’re testing I am interested in what you did, but I am more interested in what you were thinking
- If modeling tools aren't working for you, draw it yourself on paper/whiteboard, take picture, share it (e.g. don’t be crippled by the limitations of your tools).
- Interacting with an application guided by a model can be much more interesting and useful than reading documents because…
- A document is where information is going to die.
Context-driven testing in an agile context – A happy marriage?
In a talk near and dear to my heart, Huib starts by asking the common question of “...But what is Agile testing?” and providing an answer considered heretical to some; there is no such thing, testing is testing, Agile is context (or at least that’s how I say it).
Throughout the rest of his talk, he explores the goodness of fit of Context-driven testing in Agile contexts. Just a few of the gold nuggets in this talk include:
- Perspective is one of the greatest things about being in a team.
- Being a single point of failure in testing is bad in so many ways
Get Out of The Testing Game
Another talk after my own heart, Bill reminds us that testing isn’t an end in itself, but rather a means to an end.
To paraphrase, he reminds us that not to delude ourselves that we’re playing a testing game. We’re actually playing an information game. I literally broke into spontaneous applause when Bill used the same Business Model Canvas to cement his point that I’ve been using in my current role as a product owner.
For all the talks I’ve given over the years about the “business side of testing” I never thought to make my point by using the same tools “the business” uses to assess project or product value. This is brilliant!
My summary kind of implies my key points from this talk, but here they are anyway:
- Testing is a means to an end, not an end unto itself
- A Business Canvas Model can be extremely valuable for improving business alignment of testing because it focuses on defining relationships, problems and opportunities.
I attended Stephen’s first public talk about a year ago. He was nervous. I was impressed. But not nearly as impressed I was with how far he’s come as a presenter since then! His first talk was well structured, technical, educational, insightful, and effective. In this talk about inspiring testers, he wasn’t just effective, he was inspiring! A few of my favorites from his talk were:
- An artful, appropriate and poignant use of a Voltaire quote: "He must be very ignorant for he answers every question he is asked.”
- A reminder that “requirement specifications can never be clear enough that's why conversations are best.”
- And an echo from Bill’s talk "Testers you are not the most important people in the company."
Automation: Time to Change Our Models
As always, Iain had me riveted. Of course, his use of one of my favorite quotes didn’t hurt:
“Some models are useful, all models are wrong.” - George Booth
What I loved was how well he demonstrated that a twist on that quote of “Some test automation is useful, all test automation is flawed” is equally true. Some points Iain made that we’d all do well consider:
- “Homogeneity bad, diversity is good. Constraints imposed by our mental models can lead us to homogeneity.”
- "Schematic Promiscuity" <- What does the system look like through a changed lens in your spectacle glasses?
- Look at a problem, changes lenses and look again. You think differently
- Our choice of tools shape our behavior – so choose wisely!
Easing the Pain of Legacy Tests
After more than 10 years spent (primarily) as a trainer and consultant, I felt Chris’s pain related to legacy tests before his introduction was even complete.
Do they still add value? Are we spending more time maintaining them than we’d spend to just execute the tests by hand? Worst of all, are we getting a false sense of security from tests that long ago outlived their usefulness? His abstract claimed that “By the time we’re finished, you’ll be ready to cauterize, triage and heal your legacy test pains with surgical precision.” I’m not sure that’s possible in under an hour, but he came mighty close! Consider:
- Do quick wins first: It unclutters your desk, allows you to learn and it motivates! Then dive into deeper issues.
- Don't dive into the code, resist and analyse the failures. Categorise them to understand more about failures.
- Hard problems are usually just a bunch of little problems… jump in and fix them.
- Reducing run times on automation simply by getting tests to automatically clean up database resources.
How to Talk to a CIO About Software Testing (If You Really Have to…)
In the final pre-planned talk of the day, Keith hit the nail on the head and tied up the many of the themes that emerged throughout the day by sharing what he’s learned about talking to executives, specifically CIOs, about software testing. I have to say that many of his experiences mirror my own, and I agree with his main points, namely:
- "We suck" at talking about testing and quality to CIOs
- Remember, CIOs live in the cost, quality, time triangle
- When talking about testing to C*Os, don’t talk about testing.
- when talking about testing to your C*O: focus on what you want them to KNOW or what you need them to DO
- Focus on the big problems that could be caused to users if something goes wrong with the product.
99 Second Talks
And if that wasn’t enough content…
The event closed with attendees giving “99 second talks.” These were not pre-planned talks, there was simply an announcement calling for volunteers at around 11 a.m. and by late afternoon we were regaled with poems, silent skits, personal stories, lessons learned, inspiring tales, and a *fantastic* seeming spontaneous list of more than 25 software testing myths (my personal favorite being “24… umm… I can’t remember what 24 was, I'll keep going” – an unintentional, but appropriate reminder that no matter how much we may wish it were otherwise, bugs will always escape. The best we can hope for is that the ones that do are ones that we, and our businesses, can live with.