I believe that the traditional software QA model is fundamentally and irretrievably broken.
I think there is something fundamentally broken in the way we are used to build and ship product. Triggered by Elisabeth I had an eye on stuff while starting to read The Psychology of Computer Programming only recently – yeah, I didn’t read all of Jerry’s books so far. Shame on me. These are my early raw thoughts on what might be broken.
Stick in software testing long enough, and you will see enough ideas come and go to be able to sort out the ones that look promising to work, and the ones that you just hope will go away soon enough so that no manager will pay any of her attention to it. There have been quite a few in the history of software testing, and from my experience the worst things started to happen every time when someone tried to replace a skilled tester with some piece of automation – whether that particular automation was a tool-based approach or some sort of scripted testing approach. A while ago, Jerry Weinberg described the problem in the following way:
When managers don’t understand the work, they tend to reward the appearance of work. (long hours, piles of paper, …)
The tragic thing is when this also holds true for the art of discovering the information about how usable a given piece of software is.
On my way back from the Agile Practitioners Conference 2013 in Tel Aviv, Isreal I digest lots of information and bar discussion content. After attending Dan North‘s tutorial on Tuesday, I have six sheets of paper on notes with me, that will probably fill my writing buffer for the next half year. Time to get started. Here I connect Dan’s model of the Three Ages to Software Testing.
Since it was shortly before Christmas, I put a wish on twitter last week:
Anyone who wants to give me a gift for x-mas, consider writing a programming language where “if (* == true)” results in a compiler error.
This inspired some ideas on the twittersphere, and I decided to bring this topic to the Hamburg Software Craftsmanship user group on last Tuesday. Here’s what we brainstormed together: The best programming language, ever.
Probably the ugliest thing about going to conferences is that you pick up a lot of books to read. That even held for XP 2012 in Malmö, Sweden, although I just attended the first day at the tutorial of J.B. Rainsberger & Ruud Wijnands on Agile Coaching. They recommended two books from Patrick Lencioni for my to-read pile at home, The Five Dysfunctions of a Team and The Three Signs of a Miserable Job. While getting close to finishing the latter one, I noticed that the three signs of a miserable job map easily to signs that your Scrum implementation is miserable as well. Here’s the rationale.
The other day I was going through the first few drafts of the German translation of ATDD by Example – A practical guide to Acceptance Test-driven Development. Since some days I had been watching the list of issues that Dan Woodward and Arjan Molenaar were heavily working on some updated to the UI system, and FitNesse in general. Then Mike Scott told me that he just did a presentation at the Agile Testing Days, and used the recent version of FitNesse from the CI-server – and it looked awesome. Putting all together I decided to use new screenshots from FitNesse in the German translation. Until I get to update the English version of the book, here are some screenshots for the next version, which should be officially announced within the next week or so.
About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.
One of the three things that bring innovations, is copulation. That’s basically two already good ideas having sex with each other. I learned this from Jerry Weinberg’s Becoming a technical leader. The longer I stay in test automation and agile, though, I think this does not hold for combinations of testing tools, like a testing framework, and a UI-driver.
