Testing in 2019, according to my Twitter bookmarks

I’m not a particularly active twitter user, but I do find it a great way to get a wider perspective on software testing and development. I’ll often bookmark interesting tweets or threads as I come across them so I can remember to come back to them, either to read later or to think more about. To give you a snapshot of some of what’s been influencing my thoughts around testing this year, here’s a roundup of (almost) everything I bookmarked on twitter in 2019.

In automation and development:

• Russel Johnson highlighted Angie Jones’s article about blurring the lines between UI and API testing to bring the DRY principle to test automation.
• A quick lesson on xpath to counteract all the hate for it.
• Gerard K. Cohen aptly points out that the best way to learn accessibility in React is to learn HTML.
• T.J. Maher tipped me off to The Internet, a good playground for experimenting with automation.
• Ministry of Testing started a thread on testing tools.
• I learned about generative or property-based testing via Lisa Crispin.
• Manuel Matuzovic points out the limitations of Google Lighthouse with an example of a site that passes all accessibility tests but remains woefully inaccessible.
• A tip from Jon Kuperman to check out web.dev pages for help with various frameworks.
• This tweet spurred me to dig more into the Chrome DevTools Protocol, realizing both that I was already using it with knowing it and that I could leverage it more.
• A checklist of thins to look for when testing web pages from Lena Pejgan Wiberg.
• Samuel Nitsche, for developers: “If you don’t know how to test something you wrote, you did it wrong“
• This tip from Rick Scott on evaluating your test automation: “take away the software [and] see what still passes“. My old boss used to tall those “coffee break tests”.

In product management/ownership, John Cutler continues to be a significant influence:

• A good definition of done can still lead to a bad product,
• 15 things to know about product managers,
• An illustration on how trends in development practice live and die that helps me cut through both hype and hate
• On how the key to getting something done is 6 months is getting first first version done in 6 days.
• A thread on how a shared infra/ops (and test?) team can grind things to a halt.
• On working fast and slow that made me think about what level I tend to work on, and this great thread to go with it.
• A maturity model for maturity models that I’ll pull from the next time someone gripes about maturity models.
• His take on how to define an MVP.
• How to deal with top-down solutioning and taming big egos: assume the idea is good and test it.
• Tips on writing good one-pagers,

On the DevOps front, there’s always fun to be found in threads for or against deploying on Fridays:

• Prompted by Kelly Sommers, Jez Humble points out that config changes are more likely to break production than code changes, so configs should be part of the pipeline too.
• Charity Majors says if you can’t push on Fridays, you need to prioritize improving your CI/CD and observability until you can. I’ve been using something similar as a litmus test for a team’s technical agility.
• Matt Long made a mind map about CI pipelines as applications.
• Or, you can think of CI pipelines as part of the application itself.
• On the skills testers need in DevOps.
• “Testing is the feedback we seek“, from Ashley Hunsberger via Dan Ashby.
• The 2019 Accelerate State of DevOps report came out.

And speaking of frequency and agility:

• Jason Yip asks “How do we get better so we can do this faster” instead of “how do we do this faster”.
• A word of caution on measuring lead and cycle time from John Cutler, as well as pointing out things that feel like going faster versus actually making us faster.
• Forget agile, just as “where’s your feedback loop?“
• Rebuttals to “Agile won’t work here” based on the excuse and who’s giving it from Jeff Gothelf.

In UX, design, and customer-first approaches:

• A thread from Dan Abramov that started about a drawback of TDD, but caught my attention because he emphasized that nothing beats actually using a product to get a good understanding of it.
• Nate Sanders talked about the importance of involving engineers in discovery.
• Andy Budd points out that design research is about finding the problems your users face, not just solutions.
• A poem illustrating designer perspective vs user perspective.
• A fun illustration of how users see unlabelled icons.
• I like this fill-in-the-blank exercise from Cindy Alvarez to make thewhyof what you’re developing clear.

On how teams work, communication, and collaboration:

• Liz Keogh describes how it takes three tries to work with WIP limits: first people ignore them, then they feel bad about ignoring them, then they actually start staying within them. I wouldn’t be surprised if other changes evolve similarly.
• A reminder not to get too caught up in pedantics from @vandroidhelsing.
• A simple development maturity model from Richard Minerich
• On the value of stating the wrong answer instead of asking a question
• Elisabeth Hendrickson asked a question about wide band delphi and 68% of people (including myself) didn’t know what it was
• There’s a nice one-pager on agile testing from Janet Gregory and Lisa Crispin.
• How to run a Lean Coffee from Matt Heusser
• Some commentary on how agile started technical and has ended up as a project management thing.
• I love this scale for describing complexity from Liz Keogh.

Other miscellaneous testing stuff:

• In March I bookmarked a tweet about Janet Gregory’s Whole Team Testing course, and I’m now going to be taking the course in February.
• Ministry of Testing asked about testing tools
• The concept of “qualtability” raised by Richard Bradshaw but originally from Anne-Marie Charrett.
• Is going live with the least testing possible our goal? Beware of throwing away things that aren’t actually waste.
• On Mob Programming – “quality goes down as the number of people touching the codeindependentlygoes up.” (emphasis mine)
• Related to that, evidently company org structure is the biggest predictor of the number of bugs in code, not the code itself.
• Ministry of Testing asked “what should not be automated“, which I’ve been known to ask in job interviews.

Several things made it into my bookmarks but are still on my “read/watch/do later” list:

• Myles Lewando drew my attention to Design for Developers by Sarah Drasner.
• Vladimir Tarasov suggested this article on How Complex Systems Fail should be required reading for all testers.
• “An Elegant Puzzle“, thanks to the recommendation from Charity Majors.
• An executive crash course on the DevOps phenomenon from Nicole Forsgren.
• This article on testing structure changes from Kent Beck.
• The “Shape Up” way of working from Jason Fried. Alan Page highlights this quote: “Therefore we think of QA as a level-up, not a gate or a check-point that all work must go through. We’re much better off with QA than without it. But we don’t depend on QA to ship quality features that work as they should.”
• “Escaping the Build Trap” because of the connection Richard Bradshaw pointed out with effective testing.
• “The North Star Playbook”, yet another way of working, this one from John Cutler and co.
• “Leading Quality” thanks to this slew of recommendations.
• I want to try Armstrong, an app for exploratory testing that Richard Bradshaw highlighted.
• “Operations Anti-Patterns with DevOps Solutions” from Jeff Smith.

Finally, just for fun, there was this figure of a black hole published at 1:1 scale.

And that, folks, was my year on Twitter.