Past Presentations
You can find an extensive list of presentations and courses that I've taught, including the slides and speaker notes for many of them, here.
Coming up—let's meet!
Check out my schedule, and drop me a line if you'd like to get together when I'm in your part of the world. If you'd like me to work with you and it doesn't look like I'm available, remember that my clients' schedules are subject to change, so mine is too. Finally, note that some conferences offer discounts—and even if they don't advertise it, maybe we can work something out.
October 9-10, 2019
Riga, Latvia
On my first visit to Latvia this fall (and also my first visit to Latvia ever), I'll be presenting Critical Thinking for Software Testers, a full-day workshop, on October 9. Then, on the 10th, I'll be presenting a keynote talk on a topic to be determined.
October 11, 2019
Riga, Latvia
A day of corporate consulting with a private client.
October 14-16, 2019
Utrecht, Netherlands
A return to Utrecht for another public session of the three-day Rapid Software Testing Explored class. You'll find info here.
October 21-23, 2019
Toronto, ON, Canada
Home at last! I'll be presenting Critical Thinking for Software Testers as a one-day tutorial on Tuesday October 22, and giving a keynote on The Logic of Verification on Wednesday the 23rd.
October 28-30, 2019
Moncton, NB, Canada
A private three-day Rapid Software Testing Explored class for a corporate client.
November 11-13, 2019
Prague, Czech Republic
I'll be participating in the EuroSTAR conference for the thirteenth year in a row. This time, I'm presenting Using Risk to Guide Testing.
November 15, 2019
Riga, Latvia
Funny how one visits a city for the first time, and then visits it twice in two months. For my second visit to Riga, I'll be presenting at an in-house conference for a private client.
November 18-20, 2019
Vienna, Austria
For the first time in Vienna, a public presentation of Rapid Software Testing Explored, organized by TechTalk. Register here.
November 15, 2019
Riga, Latvia
Funny how one visits a city for the first time, and then visits it twice in two months. For my second visit to Riga, I'll be presenting at an in-house conference for a corporate client.
November 27, 2019
Waterloo, ON, Canada
For the first time in ages, I'll be delivering a lunchtime presentation for the Kitchener-Waterloo Software Quality Association (KWSQA). The topic is TBA.
December 2-5, 2019
Munich, Germany
A private three-day Rapid Software Testing Explored class for a corporate client.
Test case is a noun, test is a verb.
Test case is the means, test is the objective.
A test case is a recipe used by the tester(chef) to test(cook).
Test case is the script; tester is the actor; test is an act.
A tester can test without a test script.
The most important of all three is the tester, as the test is as good as the tester.
[…] post was triggered by thoughts following on from a Michael Bolton tweet and blog post making analogies to explain that test cases are not […]
[…] The Test Case is Not the Test […]
Absolutly right! … and nobody wrote in test case: “Now you should galumphing for 1 hour to find some bugs” 🙂
Exactly. And likewise, “How many recipes do you have” doesn’t tell us anything about your cooking skill.
It’s a sacrilege to say something against them or be placed in a different light. Somehow this emphasis on test cases is encouraged by tools also, for example TFS. It seems that some pseudo-managers are won over by the simplicity of this management, meaning testing by just counting test cases.
[…] • ?????????-???????????: test case – ??? ?? ????. […]
[…] • ?????????-???????????: test case – ??? ?? ????. […]
[…] of steps (and because of that it can’t be done by a machine – more about that later). A test case is not a test. At best, it is a test guide or idea. There is no way a “test case” could ever be […]
Absolutely right! … and nobody wrote in test case: “Now you should galumphing for 1 hour to find some bugs”
Michael replies: Yes. It would be a good idea to do that (although it might be helpful to be clear on what “galumphing” means; so here’s a reference).
In my view, a Test Case is the unit of measurement of the effectiveness of a Test. Segregating a Test into Test Cases can help us determine the Test Coverage. A Test tends to be generic whereas a Test Case is specific.
Michael replies: People might think that way, but I can’t agree.
With repsect to your first sentence: if a test case is a unit of measurement, what is the scale for the unit? Is a test of six steps and three evaluations to be counted the same way as a test of 24 steps and one evaluation? Before you answer, notice that “step” and “evaluation” suffer from the same scaling problem: is moving the mouse and clicking the button one step or two? Is selecting a check box a step? If it is, is typing a single keystroke in a field a step? Is typing 16 keystrokes into a credit card field a single step? Does that step include pressing Tab to go to the next field, or is pressing Tab a new step? What if the test case is composed simply of a set of data values—inputs and outputs—with no steps specified at all? For something to be a unit of measurement, you need a model such that units are commensurable. That’s hard enough to do when you leave out the cognitive aspects of the test, but how are you going to claim a “unit” when you add in the tacit stuff&mash;that is, what we’re observing and learning that is not explicit; the stuff at the very heart of the test.
That’s a problem with treating a test case as a unit of measurement at all; even as a unit of effort. But there’s a deeper problem: there’s no intrinsic link that I can see that makes a test case a unit of measure of effectiveness. That seems like a pretty wild leap.
With respect to your second and third sentences: I’d say there are other, more specific ways to describe our testing and our coverage. I agree that describing our coverage is important, but I don’t think you’re talking about test cases here in the way that most people talk about them. In Rapid Software Testing, we think of a test condition as “something that could be examined in a test, or that could influence the outcome of a test”. It seems to me that a test case covers many conditions—and here again some are explicit and some are tacit; some anticipated, and some only recognized after the fact. To the degree that you’re talking about conditions, rather than cases, I would find it easier to agree with you.
“PowerPoint slides is not a conference talk” smile words 🙂
[…] https://www.developsense.com/blog/2017/02/the-test-case-is-not-the-test/ […]