Tag Archives: software

The long quiet followed by a Hard Shake

1 Reply

So I’ve been quiet for quite a while. The blog article ideas have been mounting up, and I’ve not been writing them. A lot of the time I don’t actually enjoy the writing process. I don’t know if you’re meant to enjoy it, but I find it hard to sit down and write out the ideas that are piling up. I have a bit more free time at the moment, so I should be able to force myself to write some out. If anyone has ideas on how I enjoy the process more then I’d love to hear them.

Now onto actual testing stuffs.

A lot of us have heard of the testing technique galumphing which was originated by James Bach.

It’s a technique I used before I knew I used it; as is the case for many of us. We don’t know we necessarily do this thing, but when someone can explicitly describe the action in a way we can understand; that’s when we get the “oh yeah” moment. We’ve often galumphed our way through a site without realising we’re doing it. This is the value in someone like James. Someone that can find a descriptive term for something that was previously tacit knowledge.

What happes when galumphing doesn’t just desribe how you might click around a site, but it actively describes how you might traverse a VR application?

Well the best techniques are the ones that are still relevant to situations beyond which they’re written for. Did James actively think about VR testing when he wrote about galumphing?

Probably not, but he didn’t need to. He understood the concept of how unintended movements (physical or control-system based) will apply to a variety of situations.

Introducing the Hard Shake

So during my VR Testing I have been (concisouly and unconciously) carrying out
lots of galumphing. This has happened to the extent that I feel certain movements within that approach deserve to be named.

So for the first one of these techniques, I name the Hard Shake.

The naming of this happened quite naturally. A tester that I’d recruited talked about an issue they’d found in the app, and demonstrated the movement required to trigger this issue. I then asked whether he could recreate the issue without a Hard Shake.

This wasn’t a term I’d used before, but it instantly felt lke correct. It described a movement I’d carried out numerous times before; often used as a way to transition between steps. It can be used at any point however. It is very useful for uncovering performance issues, and unintended effects from gaze being shook in that fashion. Remember that this is something that can be used at anytime within the headset. I mentioned transitions, but even at times when the user may only be receiving information; it is useful to carry out and see the results.

So here we go, the Hard Shake. It seems simple. I’ve talked to other testers that have done this naturally without thinking. However, when we can explicitly talk about and name techniques; it gives us a platform on which other knowledge can be built. This is harder when the knowledge stays inside our heads and is exercised in a tacit manner.

Part of this issue is connected with how instinctual testers work. This is something I’ll cover in a future post.

Doesn’t look like that on my computer – The Oculus Rift version

1 Reply

So we’ve all been there…By we I mean developers and testers. The tester finds a bug and the developer says it doesn’t behave like that on their computer. So then you puzzle out what is different between the two machines; well that’s how it should go…

Now take that situation and increase the variables by at least a factor of 10. That is what happens when you bring Oculus Rift into the equation.

So I’m retesting a bug based around the position of the content. I briefly touched on depth of field issues in a previous post, but let’s get into it more. Where you position content in relation to the user is critical. If content is too close to the user; they will feel claustrophobic. If it’s too far; then they won’t be able to experience it as intended. If it’s a little too close; then it makes accessing content below the user’s resting eye level very uncomfortable.

In today’s situation the dev came around to watch me using Oculus Rift as I retested this bug. Not only did we realise it was still a bug, but we also realised the difference in how we experienced the same content. Between the way the headset was calibrated and the positioning and angle of the motion tracker; we realised there was a big difference between our ‘at rest’ eye level.

Through this bug we discovered the need to implement; not only a calibration process for users, but crucially a calibrated setup in the office. We need to be sure that both devs and tester are experiencing the same thing. Seeing the same thing is not enough!

We need to know that a turn of the head will react the same at either dev or tester’s workstation. Now obviously it’s unlikely that the separate workstations can be setup *exactly* the same, but realising the issue is key here!

The realisation gives us the opportunity to learn more, and how to give the user the highest quality VR experience they can get!

Who said that?

Leave a reply

OR

Whisper and the supposed sources of knowledge.

First off let me apologise for the vast length between posts.

I’ve recently been using the app Whisper. I don’t want to talk about anything to do with it’s levels of anonymity. Instead, something much simpler.

Whisper is buggy as hell and has some of the worst UX traits I’ve seen.

Now that’s out the way we can proceed.

I seem to always bring work home with me and commonly have bug reports flying back and forth. Whisper is the same. I really like the concept of the app but it is executed poorly.

I’ve sent emails detailing the issues I’ve discovered. The first reply I received was a standard;

  • have you tried clearing data?
  • have you tried to reinstall the app?

This made it clear that my email had not been read. I’d detailed all my actions in making sure these were firm, repeatable issues. After more back and forth I informed Whisper that I was a software tester and suddenly my emails were escalated to the dev team.

This annoyed me!

The issues I’d found were being seen by all users. The users were using the app to bitch about the problems. This email could have come from any of them and been as valid.

People generally don’t report bugs.

In fact it’s the bane of the OSS community that more people don’t actively report bugs. A user that has taken the effort to email through a bug is worth listening to IMO.

There is the assumption; that those who are not trained appropriately can have no valid input. This seems to be less and less true but it is questionable whether it ever really was.

Within Sociology there have been occasions where the supposed ignorant have been capable of insight greater than the Sociologists involved. My favourite example of this is,

Learning to Labour by Paul Willis

This is a landmark study in Sociology for various reasons and I would highly recommend reading it.

In very brief summary; Paul Willis uses the participant observation technique to spend time with “troublesome” kids of a class in 1970s Britiain. The premise is to investigate the way in which there is little social mobility out of the working class.

There is an assumption that the kids are unaware of the processes at work which dictate their life-chances. Yet Willis discovers that the boys are all too aware of their own abilities and situation,

  • Eddie – The teachers think they’re high and mighty because they’re teachers, but they’re nobody really, they’re just ordinary people ain’t they?
  • (…)
  • PW – I mean you say they’re higher. Do you accept at all that they know better about things?
  • Joey – Yes, but that doesn’t rank them above us, just because they are slightly more intelligent.
  • Bill – They ought to treat us how they’d like us to treat them

There is even lamentation from the group when pondering their time in school,

  • Joey – ….something should have been done with us, I mean there was so much talent there that it was all fuckin’ wasted. I mean X, he was as thick as pigshit really, but if someone took him and tutored him…he’d got so much imagination.

Before this study; working class kids expressing these concepts seemed unlikely. Yet here they are, expressing how all are capable given the correct time and effort. This is evidence that those seen as stupid, clearly aren’t.

A user doing something stupid doesn’t equal a stupid user. Ignore your users at your own peril.