1) Okay, it's time for some testing tweets. Our reluctance to talk about problems (and potential problems) is undermining our most important job as testers: finding problems that threaten the value of the product. Problems happen. If we want to help, we must focus on that. So...
2) We must obtain experience with the product; perform (thought) experiments; explore the product or its requirements. But it seems to me that a lot of common talk about testing undermines that, and focuses on demonstration and confirmation, not *testing*, not *challenging*.
3) Here is a set of straightforward, plug-and-play replacements that provide alternatives to common testing talk. These can help us to focus on finding problems that matter, at pretty much any stage of development. Ready? Let's begin.
4) Try replacing "verify that..." with "challenge the belief that..."
5) Try replacing "validate" with "investigate".
6) Try replacing "Confirm that..." with "Find problems with..."
7) Try replacing "Show that it works" with "Discover where it *doesn't* work".
8) Try replacing "Pass or fail?" with "Is there a problem here?"
9) Try replacing "test case" with "experiment".
10) Try replacing "actual result" and "expected result" with "observation" and "oracle" (that is, the means by which we recognize a problem; developsense.com/blog/2012/07/f…).
11) Try replacing "test case" with "explicit of test conditions and coverage ideas".
12) Try replacing "pass/fail ratio" with a list of problems that matter (no one cares particularly about "passing" test cases; and even if the test case passes, there can still be terrible problems on which the test case is mute.
13) Try replacing "counting test cases" with "describing coverage". And make sure you describe important testing not yet done; aspects of the product that your testing *hasn't* covered.
14) Try replacing "automated testing" with "programmed checking". Testing can't be automated, but occasionally automated checks can alert us to problems. Note, though, that creating automated checks requires programming, even if it's very high-level programming.
15) Try replacing "test automation" with "tool-assisted testing". Automated checks are among the *least* powerful and useful ways that we can use programming to help us gain insight about a product, and to help us test. Use programming for data generation, probing, analysis...
16) Try replacing "use cases" with "use cases AND misuse cases AND abuse cases AND abstruse cases." Also remember that some people are obtuse sometimes, so think about "obtuse cases" too.
17) Try replacing "measurement" with "assessment". Most of what goes on in complex, cognitive, social domains (like software development and testing) can't be measured easily in valid and reliable ways. But such things can be assessed reasonably. satisfice.com/blog/archives/…
18) Try replacing "KPIs and KLoCs and 'measuring quality'" with something far more important: *learning from every bug*. Please don't reduce engineering to scorekeeping.
19) Try replacing "preventing bugs" with "identifying bugs early". We testers CANNOT prevent bugs; whether it's running code, a design, a story, or an idea that someone gives us to test, the bug is there when we encounter it. But we identify the bug before it goes any farther.
20) Try replacing "AI might put me out of a job!" with "AI is going to need *even more* critical evaluation than stuff for which we have the source code." That behooves us to become better, more critical technologists and social scientists. Let's get on that, stat.
21) Try replacing ponderous, overly formalized, scripted, procedural test cases with concise charters. A charter is a mission statement that guides a burst of testing activity. Encourage testers to vary their behaviour *and to keep reliable, professional notes on what they did*.
22) Try replacing "we have to..." with "we choose too..." Nothing in testing is mandatory in any absolute sense. When you fall into the mistaken belief that you have NO choice, you limit your ability to find problems that matter. developsense.com/blog/2014/02/w…, satisfice.com/blog/archives/…
23) Remember those ponderous, overly formalized, scripted, procedural test cases? Try replacing them with a description or diagram of a workflow, and charter testers to report on anything that they find difficult, confusing, annoying, frustrating, surprising, or interesting.
24) Try replacing "the user" with something more specific. Consider a novice user (who may be confused); an expert user (who may be sharply critical); a distracted user (who may forget to do necessary things); a disabled user (whose needs might have been overlooked).
25) That's almost all for now. The general idea is this: try replacing all those tired, empty, folkloric, mythodological phrases and ideas that lead to unhelpfully shallow testing. Replace them with words and approaches that focus testing on finding problems that threaten value.
26) "Almost all", because there's something else. Dear testers, we need to help create better clients for testing. We need to be able to articulate the things I've said here to each other for sure, but we've also got to help our clients understand the significance of these ideas.
27) We must start to speak and think like experts, challenging the misbegotten ideas that most people have about testing. This starts with cutting out the "manual testing" and "automated testing" business. Testing isn't manual, and it can't be automated. developsense.com/blog/2017/11/t…
28) No skilled profession allows other people to talk about (for instance) "manual medicine" or "automated medicine"; "manual research" or "automated research"; "manual programming" or "automated programming"; "manual management" or "automated management". It's ridiculous.
29) The worst of it is, testers keep referring to their work this way. "I'm a manual tester." No, you're not. You're a TESTER. You use tools; that's normal. Maybe you don't write programs, but so what? Most doctors don't build blood assay machines either. But they DO use tools.
30) It's typically a good idea to have programming skills if you're working with computers. I'd recommend learning them — even if you only learn to read code without writing it. But if you're disinclined to do so, don't. The world already has too many barely-competent coders.
31) If you need code written to help you test, learn to code or ask for code to be written. But please don't call yourself or others a "manual tester". You're doing complex, cognitive, critical, analytical, scientific work, right? Try replacing "manual tester" with TESTER.
32) And finally, some words from various sponsors. Check out my blog at developsense.com/blog, and @jamesmarcusbach's blog at satisfice.com. We're performing a first-time-ever experiment next week: Rapid Software Testing Explored Online: improveqs.nl/english/rapid-…
@jamesmarcusbach 33) We're also presenting Rapid Software Testing for Managers online the following week: improveqs.nl/english/rapid-… You could join yourself; you could also tell your manager.
In the coming weeks and months, we'll be providing more stuff online. Stay tuned!
In the coming weeks and months, we'll be providing more stuff online. Stay tuned!
@jamesmarcusbach @threadreaderapp Unroll, please!
