Why this ignored tweet is crucial to the future of Recruitment

Recently I saw this in a Job Description and it set my alarm bells off!

Does the inclusion of non-political in the Characteristics of success worry you?

To some people they may think this is a good thing. Political people can be annoying at work; going on about this thing or the other. The problem with this mode of thinking is politics covers everything. It’s easy to be apolitical when you don’t think politics affects you, and this position is often the luxury of privilege.

If you’ve never been discriminated against in the workplace for your gender, race or sexuality it’s easy to be apolitical. But for many of us; this isn’t a teneble position. We can’t be apolitical because our very existence is political.

So what happens when a company is able to reject candidates because they’re too political? Does your majority white male staff become even more white and male?

What seems weird about this situation is that 2 months ago Roku appointed Maxim Williams, a black man to the position of VP, Inclusion Strategy & Talent Development. Whilst this is worth commending; it doesn’t make much sense when put in context alongside the above job description.

So are Roku trying to be seen as caring about POC but then their recruitment team are using the concept of non-political to restrict exactly who can work for Roku?

Does Roku only care about a wide range of views as long as it fits in with their view?

This type of thinking is exactly the opposite of what you want in the workplace. You want people who are political and you want views that are diverse. These are the people who are going to actively improve your products and workplace.

Because now more than ever; we need diversity. We need every kind of diversity, we need POC, we need non-males, we need neurodivergent people and we need people who are political.

People who are political are the ones who will speak up when things aren’t right in your workplace and you need those people. Otherwise you join the long list of companies making headlines when abusive things happen at your company, or you create products that discriminate against POC or disabled people.

TL;DR – Stop using your job descriptions to discrminate against people.

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.

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.

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.