My brother and I are experimenting with short podcasts. Here are the first two 15-minute segments:Testers say the darndest things. One issue in coaching testers is getting them to speak carefully about evidence and about what they can and can’t do. For instance, we talk about how we react when someone tells us that “a [...]

2010 brings a winter wonderland to much of Europe, and the first good auditions for Software Craftsmanship 2010 have been carried in on those freezing cold arctic winds.
David Laing has sent me a link to an already pretty slick-looking session on TDD for databases, which touches on lots of great stuff and utilises a good range of test and build expertise which I personally need to get my head around.

Over the last several months, B.J. Rollison has been delivering presentations and writing articles and blog posts in which he cites a paper Defect Detection Efficiency: Test Case Based vs. Exploratory Testing, [DDE2007] by Juha Itkonen, Mika V. Mäntylä and Casper Lassenius (First International Symposium on Empirical Software Engineering and Measurement, pp. 61-70; the paper can be found here).

I’ve been working through Growing Object-Oriented Software (henceforth #goos), translating it into Ruby. An annoyingly high percentage of my time has been spent messing with the end-to-end tests. Part of that is due to a cavalcade of incompatibilities that made me fake out an XMPP server within the same process as the app-under-test (named the [...]

Excellent testers recognize that excellent testing is not merely a process of confirmation, verification, and validation.  Excellent testing is a process of exploration,discovery, investigation, and learning.

A correspondent that I consider to be an excellent tester (let's call him Al) works in an environment where he is obliged by his managers to execute overly structured, highly confirmatory scripted tests. Al wrote to me recently, saying that he now realizes why that's frustrating for him:  every time he runs through a scripted test, he gets five new ideas that he wants to act upon. I think that's a wonderful thing, but when he acts on those ideas and fulfills his implicit mission (finding important problems in the product), it diverts him from his explicit mission (to complete some number of scripted tests per day), and he gets heat from his manager about that.  At the end of a couple of days, the manager wants to know why Al is behind schedule—even if Al has revealed important problems along the way—because the manager is focused on test effort in terms of test cases completed, rather than test ideas explored.