Tweet

More from @michaelbolton

Michael Bolton

@michaelbolton

Jun 7

The world used to know how to airport, but has forgotten.

There’s a cascade: not enough Customs agents in Toronto, because attrition and furloughs due to COVID; incoming flight gets held; airplane isn’t ready for the groomers; grooming crew gets shifted; catering gets messed u; loading gets messed up. Flight lands four hours late.

Now people who were supposed to go out on our plane will be three hours late. This is what a fragile system looks like.

Read 5 tweets

Michael Bolton

@michaelbolton

May 21

1) Time for a few words on *experiential testing*, a positive replacement for one aspect of "manual testing". In the RST Namespace, experiential testing is *testing via an encounter with the product that is practically indistinguishable from that of the contemplated user*.

2) Experiential testing emphasizes direct, naturalistic interaction with the product as a human would interact with it. That's important, because much of what goes on in testing may be *instrumented*; not direct, not the way real people really use it. That's both feature and bug.

3) Instrumented testing can be feature, super-useful when we want to extend or accelerate or enhance SOME ASPECT of what we can to operatate and/or observe the product, so that we can learn stuff about it that's hard or slow to learn by normal, human interaction with the product.

Read 16 tweets

Michael Bolton

@michaelbolton

May 12

8) You can write programs to help you

- overwhelm (or, sometimes, starve) the system;
- probe the internal state of the system or the data while a test is being performed...

Using code in these ways can make testing much deeper, richer and more powerful.

9) As you're developing your testing code, you'll be steered towards interacting with the product and analyzing it in ways that emphasize discovery over confirmation. The key is to remember that the task is to find problems that matter, using tools to help you *investigate*.

10) And finally: if you want to learn to write code, do it. But if you don't want to learn to write code? Don't worry about it. Develop your testing skills, and ask for help from programmers or other testers who can help you out with developing code to help you test.

Read 7 tweets

Michael Bolton

@michaelbolton

May 12

1) Here's a heuristic for your career as a tester: avoid learning about "test automation".

(A heuristic is a means for solving a problem that can work and that might fail. This heuristic might help you advance in your test career, and it might not.

2) The key is not to follow a heuristic, but to apply it at your own discretion. That requires you to using your own knowledge, judgment, and wisdom, and to exercise responsibility.)

3) Why avoid learning about "test automation"? On the one hand, testing can't be automated, though tasks within it can. On the other, most "test automation" instruction is about simple output checking, which is a very limited way of thinking about tools and code in testing.

Read 7 tweets

Michael Bolton

@michaelbolton

Mar 12

21) The mission of building the product takes focus, and as Marc Porat says in /General Magic/, that focus to some degree requires the builders to push the possibility of failure aside. Allowing that possibility to enter one's headspace can be disruptive to making progress.

22) That's why we belive having some person(s) on the project focused on testing, focused on looking for trouble rather than addressing it, is a powerful heuristic for addressing the possibility that there are problems not obvious and/or not very important to the builders.

23) Subtle problems are especially non-obvious at the beginning of any burst of work, at any level of granularity. As the work progresses and we try to solve the intial problem, we have the opportunity to learn. New problems, new risks, and new questions can emerge—if we look.

Read 5 tweets

Michael Bolton

@michaelbolton

Mar 12

11) Every now and again, while you're testing a product (feature, function, story, code change,...) it's worthwhile to pause and reflect. The pause is one of the subtle, too-often-ignored tools that we can apply to sharpen and deepen our testing. (therockertester.wordpress.com/2021/11/05/the…)

12) A pause offers a moment to reconsider the questions above AND the questions we've asked AND the experiments we've performed so far. We might be getting the right answers, but are we (still) asking the most important, relevant, risk-focused questions?

13) Are we spending too much time on the care and feeding of questions that have been answered satisfactorily, and whose answers are very unlikely to change? If we're worried that the answers might change, it seems that better awareness of *how* they might change could help.

Read 10 tweets

Share this page!

Michael Bolton

People who liked this thread also liked...

Try unrolling a thread yourself!

More from @michaelbolton

Michael Bolton

Michael Bolton

Michael Bolton

Michael Bolton

Michael Bolton

Michael Bolton

Did Thread Reader help you today?

Don't want to be a Premium member but still want to support us?