Ryan Barrington Cox bio photo

Ryan Barrington Cox

Ryan makes things in Asheville, NC.

Email Youtube Github RSS

Last week, I took a Rapid Software Testing Applied (RSTA) course from James Bach. It was a fantastic, three-day intensive about managing complexity and doing quality, creative work under stress and time constraints.

I believe these methods can be applied to any type of learning and process improvement, whether it’s writing jokes/music, learning a programming language, exercising, improving relationships, etc.

Here are some RST takeaways I don’t want to forget:

  • RST is about rapid, self-regulated learning, when there is nobody to tell you what to do (the way I like it).
  • It’s normal to be disorganized, overwhelmed and confused when you start a new project. Don’t panic. Be patient. Grow your ideas over time. Most people crumble. Confidence is key.
  • You can only do good testing when you’re engaged. Turn on your brain.
  • Good testing starts as play. Fiddle around with the product, perform sanity checks, then do survey testing, which builds mental models of the product in your head, creating a foundation deep testing.
  • Deep Testing keeps you sharp. You must constantly practice determination and deliberation skills.
  • Create a Product Coverage Outline (PCO) early on, describing the aspects of the product your testing will cover.
  • Create a Risk Coverage Outline (RCO) that addresses all the specific risks you are aware of. Does you have tests that cover each risk?
  • All your documents are in constant flux. Keep them lean.
  • Testing involves:
    • Oracles: A means to recognize a bug.
    • Environment: People, technology, procedures and much more
    • Coverage: What I’m examining
  • Session-Based Testing is a continuous create-perform-evaluate loop. Perform in focused exploratory chunks of time (i.e. ninety minutes). Always take notes, describing what you did in enough detail to remind yourself what you did later on. Notes also serve as credible reporting. Start your notes with:
    • Name, date/time, length of test session
    • Product version/environment
    • Charter statement: A clear mission for the session.
    • Any way in which you have not fulfilled charter
    • Any bugs you found
    • Any questions or issues that came up
  • Sessions help you find flow and rhythm, keep you from getting stuck on one thing too long, help you track where time is spent. This is a valuable metric.
  • Threads keep tasks going over multiple sessions, keep focus in chaotic environments i.e. If you’re stuck waiting on something, switch to a new thread. A single testing thread might stretch over several sessions.
  • Learn to critique yourself and alternate between spontaneous and deliberative testing.
    • Spontaneous: Feels easy, following natural impulses, playful, energetic, fun.
    • Deliberative: Careful decisions are made. You stop and think, “What really needs to be done? What are the steps to get there?”
  • “Bug reports are the single most important deliverable that tester produces.” You must support all claims you make.
  • A Test Strategy is a set of ideas that guide your choice of tests, not necessarily a document, can be in your head. Strategy influences what you do, but isn’t rigid. Strategies can and will change. Any time you’re testing, you have strategy.
  • Test lead should always be able to report status of testing of the top of her head.
  • Strategies are product-specific, risk-focused, diverse and practical. When making a strategy, consider, “What’s easy? What’s important? What’s expected by people who matter?”
  • Learn the product, think of important problems and potential bugs, think about how to search for those problems, how to search product in general.
  • Safety Language gives honest feedback without giving false confidence. i.e. “So far, apparently, I think, I assumed, it appears.” Don’t give false confidence. Never say, “The feature worked.” Instead say, “I have not seen any failures in the feature.” Caveat: If you overuse safety language, it sounds like you’re not taking responsibility. Walk the line.
  • A basic test report, in three levels:
    • A story about status of product “It looks pretty good.”
    • A story about how you tested it “We tested it in this specific way…”
    • A story about the value of testing. “What are the risks and costs of testing, how testable is the product, recommendations.”
  • Consistency Heuristics may be used unconsciously. These are not authoritative oracles, but they are useful. Oracles often start with a feeling and you must explain the essence of the issue. Consistency Heuristics examples
    • Familiarity: I have seen another product that handled this better.
    • Explainability: Product works in a way I can’t explain. It’s either a bug or something I need to learn. Either way, speak up about it.
    • Also - World, History, Image, Comparable Products, Claims, User’s Desires, Product, Purpose, Statutes & Standards
  • Relationships are important so people see your name or you and listen, pay attention.


published .

Next Post : More Lines
Prev Post : Socks
All Posts