Software testing has come a long way. We have more than thirty years of experience with software testing. The world turned around in that time period. Depending on who you listen to, there are various opinions on what to learn about testing. Thinking about testing and learning, I am aware that there are different learning methodologies, and preferences. Nonetheless, I think the topic of testing can be split up on three general skill-levels that have brought me value: beginners, practitioners, and journeymen. Let’s see what’s in for you on each of these.
I am currently reviewing a book on domain testing. While doing that I realized I can put up a testing challenge based on what I annoyed my colleagues with a few years back. I disabled comments on this post in order not to spoilt future visitors of my blog. You will have to find another way to respond to this.
Imagine a service which is rated on a monthly basis like Spotify, Watchever (they don’t pay me for writing this blog), pay-TV, phone lines, or mobile phones. Usually that means that you have a fixed monthly rate.
Now, the business prescribe that you have a monthly fee that you need to pay. For example for Spotify premium this is 9.99 EUR, and something else for some other service. The business rules also provide that you can cancel this service mid-month before payment. Then you will be charged only the pro-rated amount of the monthly fee for the current month. For example, if the payment period starts on the 1st of the month, and you cancel the service on the 3rd of the month on a 30 day month, you will only pay 2/30th of the monthly fee for the final month.
Unfortunately we deal with a larger system. In that system the pro-rating is transporting from the domain subsystem to the billing subsystem via the percentage of the prorating. That means that for the above scenario we will trigger some process on the billing backend with 1/15th in percent, yielding 6,666666666667 percent. The value used here is a double-precision floating point value.
Analyze this program (consisting of both subsystems) for interesting variables, what could go wrong, and how would you test it?
On the bottom of James Bach’s recommendations of people there is a small paragraph:
That One German Guy
Germany has no excuse. There are TONS of smart people there. How is it only one intellectual software tester has emerged from the ISTQB-addled masses to demand my respect with his work? My theory is that Germany has a more command-and-control culture, which perhaps disparages independent thought of the kind required to achieve excellence in testing. This pains me, because I am descended from Germans and I would love to visit and teach there.
Anyway, the one German guy who shines in my community is Markus Gaertner. I’ll do a write-up on him, shortly.
Yeah, it’s about me. From time to time I am asked by James and other people in our community where the German testers actually are. Here are some folks I am in touch with, that have raised my attention, and I think will need some attention from the wider community. There is not only one guy testing in Germany, seriously.
There is a misconception floating around that Agile Testing is mostly about automated checking. On the other way the whole testing community fights since decades about the value of test automation vs. the value of exploratory testing. I find these two different extreme position unhelpful to do any constructive testing. Most recently I ended up with a model that explains the underlying dynamics quite well, to testers, to programmers, and to their managers. Here’s the model.
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.
On my last blog entry I introduced some zero-order measurements for agile software teams which I use quite often. One reader asked for an explanation:
Could you elaborate more about zero-order measurements? What does it mean?
Here is the primer.
On my way to EuroSTAR 2012 I was starting to think about the Cynefin model, and landscape diagrams which I know from giving some courses. I tried to relate them to software testing, different techniques, and I was not sure where this could lead me.
I had some exchanges with Michael Bolton, Bart Knaack and Huib Schoots on my early draft, and I wanted to share what I had ended up with. So, here it is.
Two weeks ago the second GATE workshop took place in our offices in Munich. Unfortunately some of the participants couldn’t make it. So, there were the three of us, Meike Mertsch, Alexander Simic, and myself. Although we were a bit low on energy in the morning, the day turned out to be a wholesome day of transpection – or if you prefer, we did a lot of test chat. Here’s what still sticks with me from the day.