Author Archives: sim

ATD decompression and the synergy of presence

Going to my first Agile Testing Days event was possibly the best career-based experience I’ve had. I met a wonderful array of people, and found it incredibly welcoming. I can be socially awkward, especially in crowded situations like that, but the atmosphere and warmth from everyone there made it easy for me. Big love to the 4am people, you know who you are 😉

There have been no lack of ideas that have come from the conversations taking place, the questions I was asked during my talk, and realisations I’ve had since I’ve been back home.

There was a curious idea that I realised after being back home. At an event like Agile Testing Days you are present with many other testers, you’ve read their blogs and watched their talks. You know their ideas, but because you’re sharing a social space with them; it feels like their ideas are more present in your thoughts. But this is something I only realised in retrospect. It came to me when I was thinking about a question I was asked about paired testing in VR.

I immediately answered that paired testing was a great model to use for VR Testing, then I went on to mention mobbing, and how that could work well too. Now I know about Maaret Pyhäjärvi‘s work on mobbing. I’ve also thought about it in passing as a good model to try for VR Testing. In that moment when I answered the question, the fact I had seen Maaret around the conference and said hi, meant that the idea was more present in my head. Then during Maaret’s talk I was inspired to start formalising those ideas into a workable model.

I love the organic way things like this happen. It all stems from those simple interactions and just being in the same place as so many inspirational people.

Advertisements

Bucharest and why Q&A is the best

I recently gave a keynote for the IM World conference in Bucharest. Firstly, I want to say thanks to the organisers. It was a wonderfully organised event. Anyone organising a conference needs to take note from how they treat their speakers. They have organised a diverse event with a great range of speakers and subjects.

I had been looking forward to the talk before the event, a great opportunity to connect with an audience and chat about my experiences over the last few years. Although there was one part of that I was looking forward to the most, the Q&A session.

Now I know some speakers dread that part of their talk. I know of some speakers that purposefully make their talk longer so there isn’t any time left for Q&A. To those speakers, I say I understand but you are missing a trick.

The Q&A section is understandably daunting from one POV. You’re on stage and are at the mercy of your audience. They can ask you absolutely anything, things that you know could reveal areas of ignorance. You’re scared that you won’t be able to maintain this image of being all-knowing about your chosen subject. I completely understand this mindset, but I am going to tell you why you’re wrong.

First off, you’re not all-knowing!

I don’t care who you are, absolutely none of us are all-knowing.

Accept it and revel in the fact!

Not being all-knowing is a good thing. It means it’s fine to not know something, it means you can answer a question by saying I don’t know. It means you can answer a question by saying,

‘I hadn’t thought about that, but thank you, that’s a great question for me to investigate.’

I knew before my Q&A session that I would be asked questions about things I had never thought about. But I also knew that anyone who asked me questions would be aiding me. When you can think of your audience’s questions as an aid rather than an hindrance, that’s when you can level-up!

Instead of fearing the questions, you realise that they give you material. From the questions I was asked after my last talk, I’ve gained 3 topics for blog articles. I made no effort to get that material, I was already doing my talk so that’s a bonus to me.

The above can also be tied into classic Sociology, where researchers realised that using a qualitative approach to research bears answers to questions that the researcher would never have thought to ask.

Being open to what people say instead of fearing it will benefit you in ways you haven’t even thought of yet. It will even get you steps closer to being all-knowing, not that you’ll ever get there but it’s worth a go right 😉

The long quiet followed by a Hard Shake

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.

Testing Room-scale VR

I tested the HTC Vive headset recently which opens up a whole new realm of possibilities. This obviously means more ways in which issues can manifest.

The HTC Vive is geared towards a Room-scale VR experience. The user will be generally stood up during use. This means more things need to be taken into account by the teams developing and testing these applications, which are mostly games at this point.

Now although Oculus Rift have stated that their headset is capable of Room-scale VR it is geared towards a sat-down experience. Understanding these distinct experiences is necessary before we can start to think about how we are to test them.

Sat down experiences take out the issue of a user bumping into their environment. It would still be possible in some particularly confined setups, but these are edge cases IMO (still not to be fully dismissed). Sat down experiences also take out the worry of becoming entangled in the headset cable and take out the possibility of a user tripping over.

Whilst all the above is true, sat down experiences also lose an element of immersion. Putting the HTC Vive headset on and experiencing the environment for the first time is an incredible feeling. Something as simple as kneeling down to pick an object up feels special. The controllers for the Vive also add to the experience, but they also provide another area for things to go wrong.

Applications being developed and tested for Room-scale VR have to take into account the variety of spaces people will have. Some developers have stated that you don’t need a huge amount of room to experience Room-scale VR. It is said you need enough room to stand up and stretch out in all directions. This video from the makers of Hover Junkers explains:

Whilst the makers of Hover Junkers have been very attentive to room size issues and the range of rooms users will have; we cannot assume everyone else will. We have to be aware that room size issues will come into play. Using boxes/crates to quickly change the test space you have is going to be necessary. It’s all well and good having the great test space you’ve setup in the office but how will that translate to the student dorm room?

Thinking about testing Room-scale VR leads me to think that we need a new heuristic to aid this testing.

An interesting discussion and more on simulator sickness

I’ve just watched this very interesting discussion on VR gaming here. I highly recommend watching it. There are a number of concepts discussed, one of which I want to raise here.

So according to Oculus Rift; Simulator Sickness is cumulative. Let that sink in for a minute…

This has a number of connotations that both developers and testers will need to be aware of. It means very slight triggers will build up over the course of the game and could overwhelm the user. The general advice to users is that if you feel any type of sickness, then you should take off the headset and have a break. Now I know that bit of advice and would generally always follow it, but let’s paint a scenario.

User is playing a game in VR and there are some minor ways in which Simulator Sickness is being triggered. Maybe it’s to do with the way doors have to be opened, but a lot of users generally won’t react to a minor feeling of Simulator Sickness, especially if they’re engrossed in the action. If this is allowed to build up, then it could overwhelm the user and make them feel much sicker than if they’d encountered one thing that triggered Simulator Sickness very quickly.

I encountered my worst experience of Simulator Sickness when I allowed it to build up. I ignored it because I was having too much fun, silly I know but these are the things users do! If you’re immersed in an incredible experience then many people will delay pausing that experience to take a break. This is why it’s falls on the developers and testers to make experiences which minimise the potential.

Simulator Sickness is one aspect of the VR experience that we have to be aware of and account for, amongst many others that I will continue to talk about.

Questions for the new frontier

There are many exciting things about working on VR projects at the moment. The infancy of the technology coupled with the potential of applications is staggering to me. I love the conversations that get bounced around the office. Any conversation can yield questions that no-one on the planet knows definitive answers to (yet).

That is something which completely excites me.

So after checking out some different games in Oculus Rift recently; I gave myself a case of simulator sickness. Now if you’ve never experienced this; it’s similar to travel sickness but can come on suddenly without warning. It can also pass just as quickly for those of you who might be worried.

I was taking a walk around the office and a dev mentioned simulator sickness would be less of an issue; once I had built up a tolerance. Now I’m not sure building a tolerance as a tester is beneficial. It is easier to gauge the reaction of someone with a tolerance to VR systems, but not as easy to gauge the reaction of a new user if you already have a tolerance.

Then the magic conversation. We start thinking about how this tolerance works. Is this a tolerance which is fluid? Given enough time your tolerance could reduce to a lower level maybe? Or is this a situation where once you’ve walked through a gate; there is no turning back and returning to the way you previously were.

There are so many disciplines colliding here, and so many things to think about. I am hyped to see this all unfold as we find out more!

The language we use

A recent debate on Twitter bought an interesting idea to light. The idea that the language used by testers can be separated from ‘testing’. The argument goes,

I don’t want to get hung up on language, I just want to concentrate on testing.

Taken at face value; it’s a reasonable view. Let’s cut the talking, it’s all about the testing.

I don’t think this is feasible. The language we use as testers; is central to what we do and shapes the testing itself.

As is usual in my posts; lets take an example from classic Sociology to illustrate this point.

Becker discusses Labelling theory in his book, Outsiders: Studies in the Sociology of Deviance. Becker says that at one time or another most of us break the law, but only some of us are ever labelled as criminals. Becker says that once labelled as criminals; this not only changes the way that society treats these people, but also how these people see and treat themselves.

So let’s apply some of this to a common issue within our field. Use of testing tools. Now already you can see I’ve started the conversation by calling them testing tools. The language used informs you as to my view of the matter.

These tools are commonly referred to as automated testing. Now many of us have interacted with manager-type people who may say something like,

Can’t we just automate all our testing

In the head of the manager there is a picture that looks like this.

robo23

Labelling the use of testing tools as ‘automated testing’ has knock-on effects.

Those within testing understand that use of automated testing tools isn’t a magic bullet. The language used gives the impression that an automated procedure is an easy procedure. It’s an understandable reaction. There are many fields in which automating procedures have made things very easy. However, the same thing isn’t true within our industry.

Using automation tools doesn’t make things easier, it’s just a different kind of difficult.

Now let’s think about what would happen if the term ‘automated testing’ was never used. The manager wouldn’t have in mind the magic automation robot finding every bug. The picture in mind would be similar to any craftsperson using their tools.

The language we use has repercussions in many ways and for a species which uses language as our primary means of communication; it isn’t something we can easily separate from anything else we do. It is inherent.

The way we talk about testing is part of our testing.