Skip to main content

CAST 2022 Recap

 

Tl;dr: it was brilliant being at CAST 2022, the conference of the Association for Software Testing, in San Diego last week.

Even if I didn't get out on the water like Tina, it was brilliant to be at an in-person conference again, with the time and space and atmosphere and context to really talk to people about the presentations, about themselves, about their work, and about all the software testing things.

It was also brilliant to be at a conference with the theme hands-on, set up to actually be hands-on. We wanted attendees to leave with a set of tools that they'd at least held in their own hands and felt the weight and balance of.

Day one kicked off with three extended tutorials from experienced practitioners. Dawn Haynes gave us A Survey of Test Design Ideas which covered test design, heuristics, sampling, checklists, and other aids to generating possible areas to test.

For those in a rush to get going with automation against web sites, Boris Wrubel had Test Automation 101 for Coders. His abstract said that he would "set up a test automation framework with Selenium and Cucumber in less than one hour" but when I spoke to him just beforehand he reckoned he could actually do it inside 30 minutes (!) using downloadable project archetypes.

The third tutorial, and the one I attended (I'll link to more detailed notes for all the sessions I was in), was Usability for Everyone from Cordellia Yokum. In five hours we covered an enormous amount of ground, motivating the consideration of accessibility concerns (which includes search engine optimisation if you're looking for a business case), talking about the various standards that exist in the space, and looking at tooling for helping to assess accessibility.

The learning was given time to sink in at the conference reception where, over finger food and drinks, everybody got a chance to chat and build relationships. I love that the speakers were there enjoying the relaxed atmosphere too.  

Then, as the late afternoon blurred into the evening, we had dinner follwed by a testathon. 

A testathon? Yes, a testathon! 

Groups formed into teams to explore a website for an hour or so and then present their findings. Reports were judged by the tutorial presenters and the conference chair and credit was given for how well the report described the state of the product, risk analysis, test coverage, and presentation style.

Some great reports were given, $1000 prize money was shared out, including $500 to the winning team Twan's Swans (pictured), and then it was on to games night.

The second day was a mixture of workshops and track talks bookended by keynotes, again all tied together by the hands-on theme and all interesting. There's something to be said for single-track conferences: you don't have the difficult decisions to make!

Before proceedings started officially, if you were up early, you could have Lean Coffee over breakfast. I was (thank you transatlantic travel) and I did (and it was great fun)!

First of the talks was Cindy Lawless who had a whole room ensemble testing the classic buggy triangle before talking us through how to (and how not to) write a test report about the work we'd just done. No artefact counts and no dumb charts. Instead, include a high-level summary, description of coverage, the strategy used, and risks found and remaining! Making Test Cases Suck Less, indeed!

The first of the day's workshops were next. In one room, we had It's All About the Money, Performance Testing and Infrastructure Costs with Twan Koot. In the other, Ben Simo on Testing Without Requirements

Twan asked participants to think harder about costs as they build and run their tests. The tests monitor performance, why not also monitor how much you're paying and take action to save money? He gave some lessons in how that can be accomplished.

Meanwhile, Ben described how his thinking on on requirements has evolved over the years. From expecting requirements up front he'll now test first help understand what the constraints for possible requirements could be. After the tour through his backstory we explored an application using FEW HICCUPPS as a guide, and then discussed what we'd found.

After lunch, Sergio Riveros used exercises to illustrate why we should be building accessible, inclusive applications, and also why compromises will always need to be made. At the same time, Amber Vanderburg, Innovation Ninja, was describing strategies she uses to help boost creativity and collaboration in her teams: keep people informed and create safe spaces to have constructive conversations about how everyone feels, and why.

Another pair of workshops next, and another tricky choice. I picked Tariq King's Hands-On with AI for Testing and Testing AI but I could easily have gone for Breadth, Depth, and Prioritization: Planning and Presenting Test Coverage with Eric Proegler and Stephanie Dukes.

Eric and Stephanie asked the participants to model test coverage of an application and then split people into groups to prioritise their testing according to different criteria such as regression, exploration, maintenance, documentation, automation, time, and cost. In parallel, Tariq had his session training ML models and then applying testing thinking to try to understand and fool them.  Tons of energy and humour too, as you'd expect from him.

If it sounds like a long day, it didn't feel like it. There was still plenty of energy around the conference for the last two track talks from Curtis Pettit and Dawn Haynes.

It's important to know your role at work and Curtis helped the testers in his session to score ourselves on tester-relevant characteristics with Critical Role: Filling Out Your Character Sheet. At the same time, Dawn was euthenising an old campaginer in Death to Test Cases! She asked if we used them, when, how, and why. Then we each wrote a case, came back to the group to talked about weaknesses and potential value, and then wrote a better version. 

Last but not least, Eric Proegler stepped up for his second stint of the day, and the closing keynote, Anyone Can Performance Test?!? Hands-on to the end, with a few clicks, and using public tools, Eric got the whole conference runing and interpreting basic performance tests on his site as he told the story of the performance testing profession.

And that was it. We had a brilliant time and now Tina can move all her tickets to Done. 

See you there next year?
Images: Chris Kenst, Tariq King, Tariq King, Tristan Lombard, Joel Montvelisky, Joel Montvelisky, Tina Toucan, Tina Toucan.

Comments

Popular posts from this blog

Notes on Testing Notes

Ben Dowen pinged me and others on Twitter last week , asking for "a nice concise resource to link to for a blog post - about taking good Testing notes." I didn't have one so I thought I'd write a few words on how I'm doing it at the moment for my work at Ada Health, alongside Ben. You may have read previously that I use a script to upload Markdown-based text files to Confluence . Here's the template that I start from: # Date + Title # Mission # Summary WIP! # Notes Then I fill out what I plan to do. The Mission can be as high or low level as I want it to be. Sometimes, if deeper context might be valuable I'll add a Background subsection to it. I don't fill in the Summary section until the end. It's a high-level overview of what I did, what I found, risks identified, value provided, and so on. Between the Mission and Summary I hope that a reader can see what I initially intended and what actually

Why Do They Test Software?

My friend Rachel Kibler asked me the other day "do you have a blog post about why we test software?" and I was surprised to find that, despite having touched on the topic many times, I haven't. So then I thought I'd write one. And then I thought it might be fun to crowdsource so I asked in the Association for Software Testing member's Slack, on LinkedIn , and on Twitter for reasons, one sentence each. And it was fun!  Here are the varied answers, a couple lightly edited, with thanks to everyone who contributed. Edit: I did a bit of analysis of the responses in Reasons to be Cheerful, Part 2 . --00-- Software is complicated, and the people that use it are even worse. — Andy Hird Because there is what software does, what people say it does, and what other people want it to do, and those are often not the same. — Andy Hird Because someone asked/told us to — Lee Hawkins To learn, and identify risks — Louise Perold sometimes: reducing the risk of harming people —

Enjoy Testing

  The testers at work had a lean coffee session this week. One of the questions was  "I like testing best because ..." I said that I find the combination of technical, intellectual, and social challenges endlessly enjoyable, fascinating, and stimulating. That's easy to say, and it sounds good too, but today I wondered whether my work actually reflects it. So I made a list of some of the things I did in the last working week: investigating a production problem and pairing to file an incident report finding problems in the incident reporting process feeding back in various ways to various people about the reporting process facilitating a cross-team retrospective on the Kubernetes issue that affected my team's service participating in several lengthy calibration workshops as my team merges with another trying to walk a line between presenting my perspective on things I find important and over-contributing providing feedback and advice on the process identifying a

Testing is Knowledge Work

  The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester , which aims to provide responses to common questions and statements about testing from a context-driven perspective . It's being edited by Lee Hawkins who is posing questions on Twitter ,  LinkedIn ,  Slack , and the AST mailing list and then collating the replies, focusing on practice over theory. I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "We need some productivity metrics from testers" OK. I'd like to help you meet your need if I can but to do that I'll need to ask a few questions. Let's start with these: Who needs the metrics? Is there a particular pr

My Favourite Tool

Last week I did a presentation to a software testing course at EC Utbildning in Sweden titled Exploring with Automation where I demoed ways in which I use software tools to help me to test. Following up later, one of the students asked whether I had a favourite tool. A favourite tool? Wow, so simple but sooo deep!  Asking for a favourite tool could make a great interview question, to understand the breadth and depth of a candidate's knowledge about tools, how they think about an apparently basic request with deep complexity beneath (favourite for what task, on what basis, in what contexts, over what timescale?  what is a tool anyway?) and how they formulate a response to take all of that into account. I could truthfully but unhelpfully answer this question with a curt Yes or No. Or I could try and give something more nuanced. I went for the latter. At an extremely meta level I would echo Jerry Weinberg in Perfect Software : The number one te

Risk-Based Testing Averse

  Joep Schuurkes started a thread on Twitter last week. What are the alternatives to risk-based testing? I listed a few activities that I thought we might agree were testing but not explicitly driven by a risk evaluation (with a light edit to take later discussion into account): Directed. Someone asks for something to be explored. Unthinking. Run the same scripted test cases we always do, regardless of the context. Sympathetic. Looking at something to understand it, before thinking about risks explicitly. In the thread , Stu Crook challenged these, suggesting that there must be some concern behind the activities. To Stu, the writing's on the wall for risk-based testing as a term because ... Everything is risk based, the question is, what risks are you going to optimise for? And I see this perspective but it reminds me that, as so often, there is a granularity tax in c

Use the Force Multiplier

On Fridays I pair with doctors from Ada 's medical quality team. It's a fun and productive collaboration where I gain deeper insight into the way that diagnostic information is encoded in our product and they get to see a testing perspective unhindered by domain knowledge. We meet at the same time each week and decide late on our focus, choosing something that one of us is working on that's in a state where it can be shared. This week we picked up a task that I'd been hoping to get to for a while: exploring an API which takes a list of symptoms and returns a list of potential medical conditions that are consistent with those symptoms.  I was interested to know whether I could find small input differences that led to large output differences. Without domain knowledge, though, I wasn't really sure what "small" and "large" might mean. I prepared an input payload and wrote a simple shell script which did the following: make a

Done by Friday

The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester , which aims to provide responses to common questions and statements about testing from a context-driven perspective . It's being edited by Lee Hawkins who is posing questions on Twitter ,  LinkedIn ,  Slack , and the AST mailing list and then collating the replies, focusing on practice over theory. I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00--  "Will the testing be done by Friday?" If the question relates to some prior discussion about scenarios we've agreed to run through before Friday then I'll do my best to base my answer on experience gathered so far . How sim

The Great Post Office Scandal

  The Great Post Office Scandal by Nick Wallis is a depressing, dispiriting, and disheartening read. For anyone that cares about fairness and ethics in the relationship that business and technology has with individuals and wider society, at least. As a software tester working in the healthcare sector who has signed up to the ACM code of ethics through my membership of the Association for Software Testing I put myself firmly in that camp. Wallis does extraordinarily well to weave a compelling and readable narrative out of a years-long story with a large and constantly-changing cast and depth across subjects ranging from the intensely personal to extremely technical, and through procedure, jurisprudence, politics, and corporate governance. I won't try to summarise that story here (although Wikipedia takes a couple of stabs at it ) but I'll pull out a handful of threads that I think testers might be interested in: The unbelievable naivety which lead to Horizon (the system at th

A Model Project

And this is how it goes. One thing to another ... At the weekend I  was listening to Gene Kim's Idealcast interviews with Dr. Nicole Forsgren and Jez Humble . Jez Humble was talking about the importance of rapid feedback and referenced a  Brett Victor  talk that had stuck with him over the years: ... he built this little JavaScript game and he was changing parameters and the game was changing in real time. And his whole comment is like, if you can change something and see the change as you are changing it, it's incredibly powerful.   And so I looked it up in the show notes and watched it. Wow ... Inventing in Principle shows examples of experimental tooling for creative activities, particularly those that include a temporal dimension. The essential idea is to reduce the friction of having to maintain a model outside of the tool. In the image at the top, the left side is a traditional IDE and the right side is a dynamic visualisation of the function being developed. You might i