I wonder if


I wonder if… the Norwegian and Swedish texts are correct on this picture:

2015-10-29 21.38.35

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:

revert_thatsodd  strange

Originally at the Ministry of Testing Facebook page,  but the twists above are mine.

The Expected


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” [1].

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 [2]):

And nothing odd happens … that I know of … on my machine, in this situation [3]

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 expectationsEating wicked problems for breakfast

1: Anyone can beat us, unless we are the besttodays innovation becomes tomorrows commodity

2: https://www.youtube.com/watch?v=tAGnKpE4NCI 

3: I’ve heard that somewhere…

Can you see beyond the visible

1 Comment

As mentioned in “Diversity is important in testing” my view is that the best testers are those that know that testing can be done in many ways. “Testing practices appropriate to the first project will fail in the second. Practices appropriate to the second project would be criminally negligent in the first.” ( http://context-driven-testing.com/) There is no “one way to do testing” (despite what standards tells you). Granted there are – in context –  best practices.

The best testers are those that can see beyond the current project and company framework. Those that realize that there is a fundamental difference between life-science validation and modern enterprise IT projects – and for agile projects even more. If the company frameworks fails to keep current and allow clear tailoring, then “life finds a way“.

There will be contexts where UX is not very interesting, where there is no software as such, where they release directly to production (so what we have TitW). There will even be contexts where structured software testing has very little business value. As well as, there will be contexts, where it’s one-shot only and testing and dress-rehearsals are done, over and over again. (consider though that for space launches superstition and good-luck charms play a very large role).

But don’t confuse your one context and what you have seen in some domains to be directly applicable in others. See beyond the visible, extrapolate your testing knowledge and approaches for different contexts, and you are the better tester.

Iceberg Factory. Torsuut Tunoq Sound and Kulusuk Island. Southeastern Greenland. http://www.mikereyfman.com/

What testers find

1 Comment

Not all my projects are thundering successes… Different early decisions have set the scene – but still the play, so to speak,  have been full of lessons in what testers find – when asked open questions:

  • A team had previously synchronized information in the old context, so they where invited to test the new solution… which turned out would eliminate the need for synchronization. but nobody had troubled them to tell them so.
  • That the development team was not acting agile, sprints and scrums in words only
  • That the biggest PBI (product backlog item) in hours, actually was to get GUI automation of modal-windows to work.
  • That despite having a requirements sheet, the actual value of the sheet was zilch
  • That despite putting in extra hours and overtime, the quality and stability of the delivered did not improve
  • That the biggest problem towards integration was problems between .Net and java implementation of SOAP
  • That simple requirements on virus scanning documents, was both hard and expensive to solve
  • That part of the project deliveries was upgraded business guides, when tested they needed corrections too

Calling them all defects or even software bugs, does sound odd to me, because those that really take time is not the software issue it self, but misunderstandings and due to not knowing everything (will we ever). Standards tell you that testing finds risks in the Product, the Process and the Project – it seems to me even more we find issues in management decisions, architecture decisions, cultural issues, organisational change… it’s just software but it does have a business impact.


Diversity is important for testing, prejudice isn’t


I want the field of testing to have high diversity

  • Different personality types:
    • we need people to get ideas, and people to finish them
    • We need people to see the strategic view, and people to get into the details
  • Different backgrounds
    • We need people that can code
    • We need people that understand the business domain
  • Different business domains
    • We need testers in the field of software development
    • We need testers in the field of IT / ITIL service delivery
    • We need device testers, embedded software testers….
    • We need testers that understand the GxP regulations
    • We need testers that understand rapid and agile delivery
  • Different people
    • Parents, singles, women, men, people with kids and without
    • Young people, experienced people
    • People who take it as a lifestyle, and people to whom it’s just a job

…most of all people. People who knows that things can be done in many ways. Let’s get rid of the prejudices that testing is for the detailed and i-dotting only. Testing is about bringing information to the stakeholders about what works and what doesn’t – it’s never about “failure is not an option”.

Recently I was required to do a Cubiks Problem solving test. It’s a 12 minute online test in word patterns, calculations and geometric patterns. Apparently I “failed” to complete all in time, but had a high degree of right answers, so my score was “average” #whatever. That apparently made me perfect to the testing area… OH NO – it only tells you that I put pride in my own work. Everything else is pure speculation and prejudice, as mentioned by Gerry Weinberg in Psychology of Intelligent Problem Solving there is a challenge with these kinds of tests for problem solving – they test, but not for problem solving.

Testing is about solving problems – business problems. Like can we ship?

See also:

Read for your kids – special interest edition


If you are a parent to (early) school children you should know that it is important to read  to your kids. Reading the words out trains vocabulary, recognition, imagination, wondering etc etc. So I read subtitles from movies… because

The boys currently have Star Wars as their special interest [1], and wanted to see the “people” movies. The have played the scenes via the LEGO Video Games (GC) and have a range of the LEGO sets – so they had the basic plot already. Feature movies like Star Wars are usually subtitled in Denmark – while animation movies are dubbed [2]. So in order both to keep up with “PG” [3] and helping them read the titles – I get to watch the movies and read the subtitles…

Poor daddy, it’s almost as hard as when he has to finish the ice cream they can’t ;-)

In the last months the (soon to be) 9yo have cracked the reading code and have gone from LIX11 books to the shorter subtitles. The 11yo have rest covered, but some of the longer texts are tricky (I’m looking at you – opening Scroll).

2015-04-04 16.51.08

I tried reading Harry Potter (in Danish) but even if the story was very elaborate and detailed it didn’t catch their interest. Neither did classics from when I was a kid (Sorry Bjarne Reuter), so I had to rethink the acceptance criteria for “read for your kids“.

See these two boys are not as easily motivated – it has to tie into something they can see a direct interest in. Their autism makes them very picky on the choice of subject. What I try is to meet them where they are, expand their competencies and give them a lot of positive feedback until they master it on their own.

Links: The yardstick of mythical normalityAcceptance is more than what can be measured

  1. special interest, as in overly dedicated into the topic and cannot talk about anything else.
  2. The Danish “dubbers” are usually world class, luckily.
  3. Episode 3 is still to come, though.

Bug Return Policy


We find bugs, irregularities, this that should be there, and things that shouldn’t. From that we create a bug report, and from that someone looks into it, and then it’s a wrap. Unless the information is not returned, an no-one is the wiser. A bug report to me is a representation of an observation of the system, usually something that’s wrong. Some tools and vocabularies calls this “defects”, “bugs”, “tickets”, “incidents”. A bug report can be an email, post-it, or even a mentioning in passing [2].

Here are some recent sample headlines:
– The design is unclear, please elaborate
– With this role, I can access this, which I shouldn’t
– When I compare the requirements to the delivery list, I find these ..
– There is no data here, but there should be
– We thought we wanted this, but now we want something else

Notice that a bug report usually originates with a person, making an evaluation. This person is the tester, no matter the functional hat (SME, SDET, PO, VP). This may be tool supported, coming from a log of automated checks, or from BDD or Jenkins or what not. No matter the amount of tools, a person is making an informed decision, and raising the bug.[4] Come to think of it, she could choose to do nothing. But something is bugging her [5].

Here are some recent replies to my bug reports:
– it is by design
– it works on the development environment
– that’s how the COTS (or framework or platform) handles it
– ok, got it. seems like an easy fix
– awrh, now we have to rethink the whole thing
– Defferred, FixedUpStream, Rejected,
– Hmm, I see what you mean. Let me look into it

These replies come from some other person than the tester – let’s call him the fixer. First of all the fixer evaluates the report – he makes a decision, based on his context and his available information. Sometimes it’s an easy fix, sometimes it cannot be reasonably fixed. Sometimes the fix have diminishing returns. And everything in between.

What is very important to me, is that the fixer communicates his immediate evaluation to the tester. As quickly and transparent as possible. The fixer, to me, does not have the option to close it [1] alone. Nor can he fix the bug without letting the tester know. In the end the tester calls whether it is resolved or acceptable given the updated information. If the tester and fixer cannot agree, then call for outside help. And only then, let the two people work it out first.

The bug report and “fixer reply” has to be returned to the tester. Either the fix has to be tested, or the no-fix has to be tested too. It’s all part of the game – and it’s all integral to improve the quality in the short run – by fixing this specific project. It is an integral part in improving the quality in the long run, by adding knowledge and collaboration to the solution of the bugs found. Every bug, every clarification, every wish from the test to investigate something about the product counts towards collaborating about the quality of the solution.

TL;DR: Always direct the reply to a bug back to the person who found it.

1: Closure http://www.ministryoftesting.com/2014/11/closure/
2: Mentioning in passing, aka “mipping” http://www.satisfice.com/blog/archives/97
3: 3 types of bugs http://cartoontester.blogspot.dk/2010/06/3-types-of-bugs.html
4: How to raise a bug http://cartoontester.blogspot.dk/2012/10/3-steps.html
5: Something that bugs someone whose opinion matters. http://www.satisfice.com/glossary.shtml#Bug


Older Entries Newer Entries


Get every new post delivered to your Inbox.

Join 1,044 other followers