Author Archives: sim

The earlier the better…

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.

Advertisements

It’s nearly always been done before and it doesn’t matter

I often see Testers talking about how they’d like to present and then there’s a BUT…

  • someone has talked about this subject before
  • no-one wants to hear me talk about it
  • what more can I add to it

It doesn’t matter if someone has talked about something before. That person wasn’t you, and they didn’t see the subject the exact same way that you do.

Maybe the way you explain a concept resonates with someone in particular. That someone may have been struggling to get the idea, but your explanation of it helped join the dots in their head. That someone might then go on to present something they discovered that was triggered by your talk.

We’re all different and have our own approaches. This doesn’t solely apply to content. The more logistical differences can matter too. Some people might enjoy an intense 3 day workshop, but that could put off some people. It might be seen as too much, and equally some of us may prefer to teach shorter sessions. Also some people work within companies that may not be willing to send someone on a workshop that long.

But maybe someone else offers a workshop that is ½ a day. That’s something that could be easier to convince a manager of. That someone goes to the workshop, comes back full of ideas that are fed back into the company. The company sees the value of this training, and then is more willing to send someone on a 3 day workshop.

We put ourselves into these positions and create the conditions for scenarios like these to occur. There can be no knock-on effect without the initial event to trigger them.

So the differences between us all aren’t only complimentary, but essential. For progress, it takes all of us together to make it happen.

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.

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.