Skip to main content

Provenance & Profiling

Is your car German or Japanese? Are your chocolates from Belgium? And your wine, which country might that be from? There's a good chance you know the answer to some of those questions. Our culture places value on provenance. That is, we care where our possessions originate. It's something we tend to notice.

Warning label?

Furthermore, we ascribe, often without our notice, characteristics to things because of their provenance. For example, that's a Japanese radio - its reliable but not cheap, etc. I often do this un-empirically, without measurement or examination. (that's a flaw)

For software testing, our automatic identification of provenance can be both a useful tool and a distraction. 

Noticing where or from whom a feature originated can be enlightening. You may learn over time that a particular team or person tends to implement certain things well, and others things not so well.

This has a tendency to help me to find some bugs relatively easily with individual teams. The first time it may have been time-consuming to see an issue. On subsequent releases, annoyingly easy.

That emotion is useful. Its an indication that you have, maybe subconsciously,  profiled the team. You can direct your response to that feeling, in constructive ways. For example, searching for a route cause or suggesting the addition of some unit tests.

It can be useful to think and deliberate over how you may have profiled the teams or people. Again, this is valuable 'intelligence,' the profile can help with planning your time and focusing test automation efforts. Though, the pattern also embodies a form of bias. You should be aware that you are subject to this bias, and routinely double check your assumptions.

It would be easy to concentrate too long on easy to find - known unknowns that were easy to spot thanks to your biased view. To increase our opportunities for discovering new types of issues, set aside time for investigating the app in other ways. 

Comments

Popular posts from this blog

Why you might need testers

I remember teaching my son to ride his bike. No, Strike that, Helping him to learn to ride his bike. It’s that way round – if we are honest – he was changing his brain so it could adapt to the mechanism and behaviour of the bike. I was just holding the bike, pushing and showering him with praise and tips.


If he fell, I didn’t and couldn’t change the way he was riding the bike. I suggested things, rubbed his sore knee and pointed out that he had just cycled more in that last attempt – than he had ever managed before - Son this is working, you’re getting it.

I had help of course, Gravity being one. When he lost balance, it hurt. Not a lot, but enough for his brain to get the feedback it needed to rewire a few neurons. If the mistakes were subtler, advice might help – try going faster – that will make the bike less wobbly. The excitement of going faster and better helped rewire a few more neurons.

When we have this sort of immediate feedback we learn quicker, we improve our game. When the f…

Thank you for finding the bug I missed.

Thank you to the colleague/customer/product owner, who found the bug I missed. That oversight, was (at least in part) my mistake. I've been thinking about what happened and what that means to me and my team.


I'm happy you told me about the issue you found, because you...

1) Opened my eyes to a situation I'd never have thought to investigate.

2) Gave me another item for my checklist of things to check in future.

3) Made me remember, that we are never done testing.

4) Are never sure if the application 'works' well enough.

5) Reminded me to explore more and build less.

6) To request that we may wish to assign more time to finding these issues.

7) Let me experience the hindsight bias, so that the edge-case now seems obvious!

Shutter Sync, when failure provides enlightenment

Shutter sync is an interesting artefact generated when we video moving objects. Take a look at this video of a Helicopter taking off:
Notice how the boats are moving as normal, but the rotors appear to be barely moving at all. This isn’t a ‘Photoshop’. It’s an effect of video camera’s frame rate matching the speed/position of the rotors. Each time the camera takes a picture or ‘frame’ the rotors happen to be in approximately the same relative position.

The regular and deterministic behaviour of both machines enables the helicopter to appear to be both broken and flying. The rotors don’t appear to be working, while other evidence suggests its rotors are providing all the lift required.

What's so exciting is that this tells us something useful, as well as apparently being a flaw or fail. We could both assume the rotors move with a constant rotation, and estimate a series of possible values for the speed of the rotors, given this video.

Your automated checks/tests can be exhibit this to…