December 7, 2015
Autism, Family and fun, Softwaretesting
atWork, business, change, collaboration, context, decisions, eurostar, LEGO_friends, value
TL;DR: Testing is always something that we choose to do – and how we test is similarly a matter of choice. As is Christmas traditions. .. it’s just man-made rules, we can choose to change them.
So I was discussing what we should have for Christmas with the stakeholders. One of them wants the traditional rice pudding, the other wants – untraditionally: chicken. And you know what – that’s ok. Traditions are guidelines, not rules – we can make new traditions, just by choosing to.
Testing in production used to be a great no-no. I’m still feeling odd when we do it, but I have come to see it as another tool of the trade. It has a name now “testing in the wild” TTitW as has been presented at EuroStar 2015. Also this is how Netflix have been testing for years, from GitHub, as it is open source too (!).
You might argue that changing testing (in the wild) is not allowed. I will challenge that assumption – being allowed to do something is a choice too. You choose to follow the the process frameworks, requirements, rules… and you can choose not to. The tradition of manual predefined testcases are so four years ago!
Sometimes it’s just a matter of saying up-front, that you are tailoring the process. So choose an approach that actually gives meaning and value to the stakeholders and context. Deconstruct the traditions and commercial bodies of knowledge and make some new!
November 27, 2015
atWork, knowledge, skills, special_needs, unknown_unknown
Amongst my secret weapons are intuition, square lashings, preparing for the unexpected,
… and that things will sort themselves out.
- I had planned to step into the parents group (aka PTA, aka forældrerådet) in one of my boys classes. But the day of the election meeting, I was pretty stressed and missed the meeting. Now a couple of months later, there’s a free spot, and I could step in and be very welcome.
- At work I saw my boss had assigned me a new project for next month. I missed to talk to him about it, but when came around to it – the project allocation had been cancelled.
So recently I have come to value: letting things sort themselves out OVER looking into everything. THAT IS while there is value on preparing everything, I value the first opportunity more. You might think of it of being sloppy, unprepared and not even tester like.. your loss… What is your secret weapon then?
November 15, 2015
There is no such thing as bug free solutions. Zero defects – is just human definition of what a defect is – oh, and the acceptance criteria of no severity 1-critical defects, is always negotiable. Acceptance of the delivery may be outside the test result… You always find things, you always choose how to handle them. There is always a threshold on what you want to fix. What sets you apart from others is HOW you handle the unexpected issues you DO find.
Google has Canary builds, Spotify their chaos monkeys, others have continuous delivery. Some even test in the Wild. How you choose to handle the things discovered is – a choice, similarly as it is a choice to handle them at all.
In all business environments errors happen – even or context new issues / bugs / defects / findings / incidents… happens, when you evaluate (test) a solution. Even in the strictest GxP Pharma validation there will be situations that is not specifically on par with the reviewed and approved scripts. Even the best CMMi or ISO29119 accredited company will stumble into new information, or test only limited subsets of total coverage.
If you fail to prepare for the unexpected – you chose poorly.
November 8, 2015
Enterprise IT, Softwaretesting
atWork, collaboration, communication
If all you bring to the meeting is what you have prepared in advance – what new do you learn by meeting?
I once was at a company that should have the motto “always prepared”, “semper fi” and “errors are not an option”. Every meeting had a check sheet, a resume form and a registration of preparation time. Because if it wasn’t measured it didn’t count. If it wasn’t in the play book it didn’t count either.
So one day we sat at the meeting reviewing a development story – the developer, an architect, me and the other roles required by the check sheet. Some had prepared written comments: everything from simple rephrasing, code changes and test case headlines. Some had not prepared a tangible thing – I had not.
So the interesting question came up: why meet at all, if the only purpose of the meeting was to go through the written changes. These could be sent directly to the developer or discussed bilaterally, and not heard by all five. The answer to this was not in the play book, and the meeting was puzzled.
I had prepared nothing in advance, yet I had prepared myself in advance to listen, think and wonder during the meeting. To me the purpose of meeting* was the joint collaboration of the participants.
The sum of the whole. That 1+1+1+1 can be five.
*: meetings can have other purposes. Sometimes I hold orientation/elaboration meetings, when things cannot be elaborated sufficiently digitally.
November 4, 2015
Family and fun, Softwaretesting
I can be obnoxious, arrogant, mister know-it-all and devil’s advocate – that seem to only want it done my way “the right way”. Like Skipper in this clip from the Penguins of Madagascar series battling Gus*: They both want this done the right way:
Sometimes this just the way I am – sometimes I even do it on purpose. Usually it’s my way of challenging what is being discussed – let me rephrase: I am testing, I am wondering, I come with counter examples, I articulate that testing is a business choice – that there are always more angles to it.
My personally preferred way is to test and think based on values – but explicit and intrinsic. I know testers that are way more process driven that I am, and more detail oriented too. That’s what makes the testing field great – we are a diverse bunch. But hey, that’s okay. We all have our own personal styles, and all styles are needed.
When I’m testing and challenging I’m prepared that I say something wrong. That my suggestion get’s rejected, that is part of the game. I probably know it’s not the 100% correct question in context. If you see only a challenger, you see only half of a testers competence. And you are reading her wrong.
I am ambitious to get the job done and devoted to advance, develop the testing craft of the company, myself and the testing community. My way to do this can be to speak boldly or to throw articles, stories and external information at you. Much like the Penguins throw everything but the kitchen skin at Gus. If you see only your own silver bullet, that is a shame – acknowledge my feedback and I am yours.
*: “Work order” is on the DVD “Operation Antarctica”.
October 29, 2015
Enterprise IT, Family and fun, LEGO, Softwaretesting
atWork, bugs, communication, community, decisions, gofigure, testingclub, value
I wonder if… the Norwegian and Swedish texts are correct on this picture:
“I wonder if“ is surely among the things that I as a tester say or think a lot. You will also hear me cheer when we find a critical bug. Every defect / bug / observation / issue / problem / incident we find is our chance to learn about the product. It’s a natural part of the game to find things and then to handle them. Defer them if so inclined, mitigate the risks, fix the bugs, update the processes – but always take a decision based on the new knowledge you have.
Here are some other things I often say:
Originally at the Ministry of Testing Facebook page, but the twists above are mine.
October 18, 2015
Enterprise IT, Family and fun, Softwaretesting
acceptance, atWork, communication, context, cynefin, exploratory, gofigure, requirements, test_strategy, unknown_unknown, validation, wicked problem
Many test processes and test tools mention that you have to establish the expected results to every test. It is at best risk ignorance not to take the notion of expected results with a kilo of salt #YMMV.
If you can establish the result of your solution in a deterministic, algorithmic and consistent way in a non-trivial problem, then you can solve the halting problem. But I doubt your requirements are trivial.. or even always right. Even the best business analyst or subject matter expert may be wrong. Your best oracle may fail too. Or you may be focussing on only getting what you measure.
When working with validation in seemingly very controlled environments changes and rework happens a lot, as every new finding needs the document trail back to square one.. Stuff happens. Validation is not testing, but looking to show that the program did work as requested at some time. It is a race towards the lowest common denominator. IT suppliers can do better that just to look for “as designed” .
Still the Cynefin framework illustrates that there are repeatable and known projects, and in those contexts you should probably focus on looking to check as many as the simple binary questions in a tool supported way, and work on the open questions for your testing.
Speaking of open ends – every time I see an explicit expected result I tend to add the following disclaimer inspired by Michael Bolton (song to the tune of nothing else matters ):
And nothing odd happens … that I know of … on my machine, in this situation 
And odd is something that may harm my user, business or program result
But I’d rather skip this test step and work on the description of the test and guidelines to mention:
And now to something completely different:
See also: The unknown unknown unexpressed expectations, Eating wicked problems for breakfast
1: Anyone can beat us, unless we are the best, todays innovation becomes tomorrows commodity
3: I’ve heard that somewhere…