doubt

Ep 52: And I say, Zangief you are bad guy, but this does not mean you are *bad* guy

~ letstalktests ~ Leave a comment

Okay, I want to talk about something that rips me up when my mental health is being particularly hard, and when deadlines are looming.

I want to talk about being the bad guy. This was mentioned in Nicola Sedwick’s fantastic TestBash talk on testers being human; a talk that is well worth the watch if you can – it’s on the Dojo1.

It’s hard to be a tester and go with the flow, be under the radar. You’ve got to speak up because that’s the job – you have to point things out, and sometimes get people to explain their assumptions or decision making. I mean, you have to do that to yourself as well, but no one sees that. They see a contrarian person who wants to know why and how and when and everything else.

You’ve got to speak up and say that something’s wrong, or you think something might not be right, or that there’s a scenario that people haven’t thought of or what about on mobile etc. Most of the developers I work with see me asking the same question of clients as well, so I think that helps. I’m a dick to everyone!

Sometimes being that person, that dick, genuinely feels difficult.

Don’t get me wrong, if there’s a bug blocking the story, then it’s blocking the story, simple as. But that doesn’t mean it isn’t disheartening to reject someone’s work, especially if there are deadlines looming, or you know it’s been a tough piece of work to get through. Or this isn’t the first time you’ve sent a piece of work back to them. Or if you know everyone is stressed enough as it is. Or if you’re going to have to defend the bug – which is fine most of the time, I would much rather get called on shit and then come to a greater understanding or get other people to understand my thinking than not but there are times when that is a difficult conversation. And sometimes you want the smooth conversation.

This is the job we’ve signed up for, but it’s not always enjoyable.

I’ve finally got out of the ‘no bugs raised = bad testing’ mindset, but there is some satisfaction in finding and pinning down a nasty, weird, or just plain juicy bug.

When my mental health is bad, or I’m stressed, or I’ve got multiple deadlines or anything, I want to put my head down and get on with work. If I find a bug, chances are I can’t do that. The majority of small bugs I’ll file without talking to a developer, but a big bug warrants a conversation. I want to double check that the bug actually exists and isn’t an environmental issue or a user issue, and I want to do that before I file the bug if possible so I can keep admin down. Or I want to show the developer, make sure they understand my notes and repro steps; I find it’s useful to get that information on a ticket before sending it over.

Then there are scrums where I have to give updates on my testing. I want to make my testing visible2, and I need to give the team a heads up if something is blocking me or potentially blocking the sprint. I have to take the good with the bad.

And making my bugs known is an important part of the development process. Flagging up that I’ve had to send a story back to a developer is important information for everyone to have at the start of the day, as 1) they may not have seen it, and 2) they might need to rearrange their work plan. I just go for matter of fact, just like I’d mention any other fact.

Okay, so strategies!

I do try to keep my head down when I can. Headphones, moving away from my desk to work somewhere else, generally means that I can focus and keep my head down a bit, get back to where I need to be head-wise.

Find the lesson. I’ve had a week of fuckups recently, and so I’ve took a day where I wasn’t in work, where I was away from the project to evaluate and figure out what I could’ve done. This also can be done in retrospectives. For me, I need to balance time and thoroughness. A series of deadlines meant that I was too focused on quick and not on thoroughness. I’m forcing that time by hand writing some notes for each story I test instead of typing them. I find handwriting forces me to think more and I’m more likely to remember things if I’ve written them down. I can then review these notes when I type them up in my testing session, which means I can think about these again to ensure I’m covering the bases I can.

Mindfulness. I’m out of practise, if fact I’m pretty sure my last session was in 2015. So I’ve started doing 10 minutes sessions before I go to bed. I don’t think it’s a coincidence I managed to finish this episode the night after I did a session of mindfulness: It’s been hanging around for about a month and a half while I try to find the words to describe what I find hard.

Find the good. I’ve focused on fuckups but sharing praise can also be a good way to minimise feeling like a bad guy. It also encourages other people to share praise, which I think is such an important part of team building.

Honestly, most of the time I love my work, I do. There are just times it highlights the cracks in my mental health, so I need to update my coping strategies to make sure I can still do the best job I can.

Footnotes

[1] https://dojo.ministryoftesting.com/lessons/do-testers-need-a-thick-skin-or-should-we-admit-we-re-simply-human-nicola-sedgwick
[2] http://katrinatester.blogspot.co.uk/2016/03/use-your-stand-up-to-make-testing.html

Further reading

Dr. StrangeCareer or: How I Learned to Stop Worrying and Love the Software Testing Industry

Ep 49: Leading the Witness

~ letstalktests ~ Leave a comment

Firstly, an announcement: LTATB is moving to fortnightly episodes. I need to level up my content game, and I can’t do that in weekly slots, so there will be an episode every two weeks. The next episode will be on 19th May.

People are really bad at telling you what they want. Really bad. They think they know, but I guarantee you they don’t. And it’s not because they’re stupid, if anything, it’s because they know their business and processes really well. Or, they know their business and processes as they stand really well. Translating that to a new system can be difficult to do.

How well do you know your commute to work? Or how to cook your favourite meal? Or the layout of your phone screen or desktop. The things you use all the time, you know what you’re doing well enough that you may not even think about every little step. You may not even realise if you’re doing something slightly (or not so slightly) inefficiently. Or, you may realise, but there’s a reason for it (I occasionally walk a longer way to/from work because it’s prettier and there’s more chance of seeing dogs being walked, for example).

Or, another way, changing computers. You get a new or different computer, and you start transferring/re-downloading files and programs. How many times after that initial set up do you realise you’re missing a program? I’ve had a week go by easily before realising there is something missing.

These little things are going to be the things that actually turn out to be really integral to a system. The stuff that isn’t the main points (browser of choice, or the pasta in a lasagna) but the stuff that just makes everything smoother (setting up key shortcuts, or adding basil or oregano). Technically you can get away without them, but it makes things just a little harder, or less great, and the people using the system will miss it and be less willing to engage with what you’ve built. So, how do you figure these things out? Ideally, you watch people interact with the system as it stands, and have a play yourself. I spoke last week about inheriting legacy systems, and some of those techniques apply here.

Another way of doing this is going through user journeys with the product owner and team.

People are really good at telling you what they don’t want. There’s gets a point in a discussion about a system where you can kind of tell that the client isn’t sure what part you’re not getting, so I’ll go through my assumption of the user journey. Suddenly, when I get to the bit I’m pretty sure I’m wrong on, they’ll re-engage and point out where my assumptions are wrong. Its easier to go ‘no, not like that’ then it is go to ‘this and this, and then this, except, shit, I missed a step here’.

However, this assumes that you’re wording things in the right way. Leading the witness is when a lawyer asks a leading question; or a question that puts words into the witness’ mouth. In this line of work, it could be as simple as assuming something and phrasing it as ‘and then you do x’ as opposed to ‘and after that, what happens? X? Or something else?’. The idea is you prompt them, but not fill in the gaps for them. In a situation where maybe people are feeling tired after a long meeting, or a bit nervous, or overwhelmed by techspeak, something like that could be just agreed to, and so you want to balance between making it go smoothly and easily and telling clients what they are going to get. We’ve implemented some things that on the surface of them make no sense, but for the context we’re working with, make perfect sense. You wouldn’t ever do it for a public facing site, but for the internal processes of the client, it made sense). And we’ve worked on a few government/public funded or charity sites, and their processes are larger than anything we can do or effect change, so we have to make them fit the system we build, not try to get them to change their processes for the new system.

The best and smoothest projects I’ve ever worked on are where the whole team has that understanding; we’re the experts in the tech side, but the PO knows their team and users better than we do, and so they say ‘we have this need, maybe we can have this?’ and we go either ‘sure’ or’ yes, maybe, but how about this?’ and then it works amazingly well.

Further Reading

https://softwaretestingnotesblog.wordpress.com/2016/04/10/ignorance-as-a-tool-to-frame-better-questions

Ep 46: Reasonable Doubt

~ letstalktests ~ Leave a comment

A couple of things:

TESTBASH MANCHESTER OMGGGG. Come to Manchester! Its awesome, I swear. Who needs a beach when you have the angry Beetham tower?

ANYWAY, I will be there and I am doing a thing on Saturday! As well as a session, that Richard Bradshaw kindly invited me to do I really want to do something podcasty, either a recording session, or a lean coffee style thing for podcasting/youtubing/blogging? I’ll build the idea more over the months, but get in touch if you want in!

Do you want to talk to me? Do you want to be on the ‘cast but only have a short message, or are in another part of the world? I now have a skype! I also have voice messaging switched on so you can leave me a message even if I’m not online, and I can put that into an episode. The username is letstalkabouttests, because brand synergy is important, so yeah. Let’s actually talk about tests!

I’ve been doubting myself a lot recently – both professionally and personally. Nothing like being told someone thinks you’re good enough to do a thing to make you insist you’re the opposite.

So let’s talk about doubt. Doubt can have many forms and many causes:

• Imposter syndrome

• Being a newbie/feeling like your skills aren’t extensive

• Not having contextual knowledge


Doubt is risky, no matter what the cause. Causes can be split into two broad categories:

‘Reasonable’ doubt in that you know you don’t have the resources you need to do your work to your best ability, be that time, tools, knowledge, etc.

This doubt is sortable – the testing community is huge and chock full of information, blog posts, podcasts, slack channels, meetups, conferences, everything. You may not know where to start, but chances are you’ll either find a post somewhere that does it, or find someone who’s willing to point you in the right direction.

The doubt can also apply situationally. If you inherit a site with a complex piece of functionality, you need to feel, as a team, that you understand it all. Sometimes that means you start testing without any test data or plan, just to see what you find.

This is where you need to manage your testing in a session, with a set time. You may not have a goal other than ‘find out more’ which is nebulous but also pretty easy to hit as goals go. You can even structure the session up to help mind map it out (incidentally, mindmaps, I cannot use them, I just find them really hard to do, compared to writing a list? I am clearly a weirdo, but if anyone can point me in the direction of other note taking/brainstorming style formations, that would be useful).

But sometimes you still can’t find all the information you need – you feel like you don’t know enough, which for me usually means I don’t know why this functionality was built, who uses it, and why. You may be able to get this from documentation, or the client/stakeholders. I guess if all this fails you could pick up bits and pieces from what the stakeholder report as issues or request as new features, and build up a picture of what they need from there.

Another kind of doubt is doubt in you, and of your work. People who are knew to exploratory testing, or who want test cases and test plans may not feel that you can ‘prove’ your testing when using exploratory, or session based testing. That requires education, and maybe presenting your testing notes to people, so you can show your testing (all of ours are saved on the session, which is associated with the ticket).

This type of doubt is sortable though, even if it is hard. Next week I want to talk about unreasonable doubt.