Tag Archives: software testing

The earlier the better…

Leave a reply

Story time…

A few months ago I went to talk to a company I’ve worked with previously, they had been asking for my time. I’d been busy but finally I’d got some free time to go in and chat. They’d hired someone new running development who was now responsible for all the hiring & firing. At the time I didn’t think it applied to me. I was an Independent Tester that had worked with them only a few months earlier, and would’ve been carrying on the work I had been doing.

I was told I would need to meet the new person and that they would need to interview me. It felt like a bit of a time waste, but hey I go along with it. So I start talking to this person and I quickly get the impression they didn’t understand (good) Software Testing. In amongst the various questions (many terribly vague) I was asked at what point in the lifecycle should a Tester be involved…Of course I answered from the start!

This person told me that they thought that approach was inefficient. At this point I was mentally done. The conversation ended not long after that and I left.

Now we Testers like to argue fiercely debate everything, and I maintain that is healthy. I know some of those interactions can go awry, but I still think it’s a good thing. We can just do better at making sure interactions don’t have to go that way.

There aren’t many things that we all seem to agree on. But to this day (and I’m sure someone will pop up as an exception after publishing this) I have not met a Software Tester that hasn’t agreed that the earlier we are on a project, the better it is. We understand that by facing issues earlier, and being there to talk things through will lead to poentential harm being reduced.

We all understand the above to be true when it comes to work. So why are there so few of us that approach our mental health in the same way?

This post is inspired by Gitte Klitgaard, in particular this talk.

During the talk, Gitte talks about feeling like she would die but still carried on without getting the help needed. There was a part that was painful to hear but pertinent to this post.

“I make things happen, it works but it’s horrible inside…Inside I’m dark.”

It’s hard for me to think of anyone feeling that pain, but obviously worse if that person is a friend. So please, if you’re in this place or anywhere near it then please talk to someone, if there isn’t someone then you are always welcome to message me.

We say to ourselves that we’ll get over it, even if we know we’re on a downward spiral we can tell ourselves it will pass. We encounter problems that are a direct knock-on effect of our state, and we still put off getting help. Yet, we’re in work recommending the exact opposite for our projects.

It seems we don’t think our brains deserve the same care. Let’s change that dynamic, let’s take at least as much care about ourselves as we do our work. I mean, I’d say let’s take more care of ourselves than work, but I know that might be a little hard for you some of you 😉

So let’s go with the baby steps. Think of your health in the same ways as you think of work. Do the things that will avoid problems down the road, when you encounter problems talk to someone who has skills with solving those problems. Don’t be afraid of specialist help, they are specialists for a reason. And if someone you know is struggling, or you feel they might be, then please take the time to listen to them with care and love.

I wish you all the best health for 2018.

Testing Room-scale VR

Leave a reply

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.

Questions for the new frontier

Leave a reply

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

1 Reply

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.

Immersion and presence – Why are they important?

Leave a reply

Testing is about gaining knowledge. To understand how to test VR effectively; we need to understand VR. In my last post I referenced a paper by Daniel R. Mestre; in this post I will go into what I’ve learnt from this.

So how do immersion and presence work together in the VR experience?

Presence is defined as the sensation of being in the virtual environment

We can think of presence as being a psychological quality. It is our perception of existing inside the virtual environment, it is subjective.

Immersion is capable of producing a sensation of presence

(Ijsselsteijn & Riva,2003)

Let’s think about this connection. Presence is the subjective feeling of being within a virtual environment, and immersion provides a vehicle for this feeling.

“The term immersion thus stands for what the technology delivers from an objective point of view”

(Mestre, 2005)

The connection should be clearer now. Presence is a subjective term; which covers how a user feels about the virtual environment; from a psychological point of view. Immersion covers what the technology can objectively deliver; to give the user a strong feeling of presence within a virtual environment.

Now who is best placed to “measure” immersion levels?

Well obviously I’m going to say testers. We’ve been doing something like this for years, but calling it user experience. Now I’m not saying testing VR is just UX testing, but it is about taking some of those principles and applying it to VR.

We cannot fully control how present a user is within virtual environments, but we can control how immersive a virtual environment can be. If we create an experience which allows complete immersion, then a user is more likely to feel present there.

 

References from the paper “Immersion and Presence” by Daniel R Mestre

Click to access Pres_2005.pdf

Presence vs. Immersion

Leave a reply

This article was bought to my attention. It talks about the concepts of presence vs. immersion, how they relate and cover different aspects of the VR experience.

I’m going to dive into this over the next few days and see how this knowledge can help improve my testing approach.

I’ll be back next week with an article covering what I learn.

Don’t worry, it’s only minor – Bug severity in Oculus Rift testing

Leave a reply

Bug severity always raises different opinions. We’ve all submitted a bug and seen it edited down to a lower severity. Severity ratings become a loose guide to the nature of a bug. They can be useful, but seeing the 1-5 rating does not relate enough information on its own.

x8cdw

There are bugs that are a lower priority to fix, but there are no minor bugs when testing in VR.

*ANY* bug can break immersion.

Our aim is to give users the most immersive and seamless experience possible.

A bug may be minor in nature, but its knock-on effects are never minor. A user may recover immersion quicker from a less critical bug but that does not make it minor.

Immersion is totally possible, but only if we make it the smooth experience it needs to be.

 

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!

First thoughts – Testing with Oculus Rift

1 Reply

When I put on the headset for the first time; the immediate brightness instantly triggered my ‘design alarm’. Bad contrast and overly bright interfaces are one of my bugbears. It became apparent that it was going to be even more of an issue inside the headset.

It may seem obvious that overly bright interfaces would be worse in VR, but if it’s that obvious, why does it still happen on websites?

I noticed that line weights were dramatically reduced when viewed in Oculus Rift, rather than a monitor. This issue does connect to contrast. If your copy is rendering much thinner in a headset; it’s going to be very difficult to contrast between the copy and the surround.

I’ve been known to fuss a lot about contrast issues, but that’s because I believe it’s very important.

I fully support these people.

There are huge numbers of people with sight problems; both diagnosed and undiagnosed. If you present content that requires concerted effort of the user to read it; then you are isolating a big percentage of your possible audience.

Now extend this idea to VR.

If you create a product that alienates a fair percentage of your audience; they don’t decide to use another VR system. You’re not running a website where you may lose them to a competitor.

Alienating someone means they will most likely be lost to the world of VR. When you’re trying to present ‘the next big thing’ you need each and every person to go ‘WOW’.

If you make one person ‘WOW’ then they tell others, obviously the converse is true. You don’t lose one person to VR if they have a bad experience, you potentially lose more.

Good testing isn’t simply about pointing out issues with a user’s experience. It’s easy to say something has bad contrast and could be hard to read. It’s harder to see the knock-on effects that issue can cause. That’s where good testing comes in. The ability to see the problem and *potential* problems created by it.

 

Software testing with Oculus Rift

1 Reply

So recently I’ve had the opportunity to work with a company developing a media player for VR; most notably Oculus Rift.

As a user; putting on the headset does throw you into another world. As a tester that world is even more different. Not only are you coming to grips with what you’re seeing, but at the same time you’re questioning it all. Breaking down what you’re seeing into its respective aspects.

Questioning what you need to think about; that you never have before?

How do you take all your experience and apply it to this situation?

One of the first questions that came to me:

What’s more comfortable; to look up towards content or to look down?

This may seem like a facile question, but it’s deceptively important. One of the main differences with using VR; is the user’s ability to look around the virtual environment. The virtual environment needs to be purposed so the user can do this in a comfortable way.

So you’re in the headset, you move your head up and down. You use different rates of motions and different ranges. Then you look down far enough that your chin hits your chest. Now that is not a nice feeling! The sudden contact with your own body does disturb the immersivity.

But it’s not as straightforward as looking up is nicer than down.

If the content as you look up; is also too close to you. It can give a claustrophobic experience. Now that might be perfect within a specific section of a game, but it’s the last experience you want a user to have; when selecting from a wall of video content, for example.

I am going to write more articles on various aspects of testing with Oculus Rift. I also welcome any other testers, or developers with an interest in testing to contact me. Let’s talk about our experiences and build new heuristics that can form a good foundation to help testing with VR develop.