Ep 56: And our survey says

An interview with Rosie Hamilton!

This year Rosie did a large survey of software testers and then did the number crunching to produce a snapshot of testers in 2016. All the data and the scripts she used are up on GitHub for transparency, and for others to do their own analysis if they wish.

Rosie has now made a web app for people to explore the data she found without having to run scripts or learn R. She has just published a blog post about how she did this, with a link to the app.

I’ve been interested in the make up of testers; where we come from, when and how we decide to become testers for a while now, and I knew when I saw the survey that I wanted to invite Rosie on to the show to chat about it.

We talk about the survey process, from inception to analysis; what the survey taught her about testers, and about surveys, where testers come from, and the plans for the next iteration of the survey.

Ep 55: FOMO

Or, fear of missing out.

Quick news:

  • I’m at Liverpool Tester Gathering on Thursday 5th August. Come say hi if you’re there!
  • Next week I’m interviewing Rosie Hamilton!
  • The google form for telling me your origin story will be closed on Monday 1st August, so get going if you’ve not filled it in already!

This was not the episode I planned to record today. I couldn’t get that episode to flow properly, so instead I’m talking about FOMO. Now, this text is not as close to a transcript as normal, as I recorded this mostly on the fly, so it’s a bit rambly and not actually written down, but I’ve got the main points below.

On Tuesday, a group of us took part in the first #TuesdayNightTesting, which was a remote lean coffee evening. It was a lot of fun, and one of the questions was about getting testers in a slump into the community. And it got me thinking about the community, FOMO, and people that don’t want to be in the community. It’s been something I’ve been thinking about, and I’ve basically got a list of things I try to do to limit, control, and maximise my testing community involvement.

  1. Have a to-do list
  2. Use bulletjournal, use trello, use whatever tool you want but write or type out a to-do list. Even if you remember everything you need to do, visualising it will help you see how much space you have for new things.

  3. Find a niche
  4. I am a magpie of testing, I’ve spoken about this before; that I can find it hard to focus because everything looks so cool that I want to do it all. I think its easier for me to choose a niche for contributing, because it depends so much on what I enjoy, as opposed to what works well for my context, the problem I have, etc. But pick a contribution (blogs, twitter, podcast, speaking, code/tool development), and roll with it.

  5. Have a plan
  6. I am formulating a plan for the podcast. It has taken me a year to realise I need one, but I’m going to write down what the podcast is, what I want it to be, and how I’m going to continue it, so I know what I want to do. It doesn’t have to be detailed, but I think if you’re serious about doing something in a big way, you need a plan.

  7. Say no/Defeat FOMO
  8. Say no. You’re going to have to at some point so get used to it with small things. Or say ‘let me check’ and go check fully before saying yes or know. If seeing other people do and tweet and blog about things you’re missing out on is going to bother you, pull back a bit.

  9. Take a break
  10. Related to the above. Take a break. Self care is important, and self care whilst doing stuff and being part of tech is something I’m really interested in.

Ep 54: Origin Stories

A series of unconnected things:

  • I’ll be at the Liverpool Tester Meetup on 4th August! Come say hi!
  • I’ve got more interviews coming up and that is my plan for August – start reaching out for interviews.
  • 30 days of testing! This is a thing that Ministry of Test is doing, and though I got off to a strong start, I’ve started to flag a bit. I need to get back on course!
  • I’ve started working with selenium! I’ve picked python as I assumed a language I knew would be less of a learning curve, but that may change as we figure out what works for us.
  • I’ve been listening to a lot of creepy podcasts – The Magnus Archives, Archive 81. Highly recommended if you like creepy fiction!

I want to talk about getting into testing.

My session at Testbash will touch on getting into testing in less than ideal circumstances and learning testing in those circumstances, but today I just want to discuss getting into testing.

So many testers say they just ‘fell’ into testing, that they either didn’t see testing as their career, or that they didn’t even realise testing was a career, and I’m intrigued by it. I am a tester that did the same, and I’m sure there are other careers where people also just fall into it, but as a tester, it’s testing I’m interested in.

I’d be interested in collecting experiences of how people got into testing; not necessarily their background, but maybe the moment you realised this is what you wanted to do, or the moment you shifted to testing almost full time – whatever you want to think as the moment or series of moments you got into testing, I want to hear them.

I got into testing by saying yes. I was working as a customer support person in a digital agency. My co-worker, who was our only tester, had moved into release management but that meant there was less time for him to test (we were ostensibly a start up, so profit margins were slim). As the person who had bugs reported to them, and the person who had the most free time, relatively speaking, it seemed obvious that some of that work would come to me. I was still new to the job, and pitching in and helping out had never really gone wrong for me before so why not?

My testing was weak, relatively speaking. I mean, I have a science degree and can be pedantic about things, so you know, I wasn’t completely in the wild, but looking back I know I missed some things I would’ve caught now.

We were working off spreadsheets of test cases, which I actually found a useful starting off, because they gave me the foundations I needed to feel comfortable. There was nothing saying I couldn’t go off script, but we wanted to make sure we had everything down (incidentally, I think I only ever used the ones handed over to me, never ones I’d made myself. Seemed like a lot of faff for little reward).

I don’t remember the moment I became a tester, but I remember a moment I realised maybe I could do this.

I wasn’t happy with an implementation. It’s hard to describe without jumping into details but it was wrong. Firstly, I was proud of myself that I’d got enough knowledge of the system to know it was wrong. We pointed out the issue and got it fixed. However, the problem was twofold (maybe three). Firstly, we had offshore devs that had no real interaction or onboarding of the site. They were treated like code monkeys, and this led to a lack of investment and knowledge of the system. Two: the feature request had had no discussion, really. It came from the client, through the account manager, straight to said offshore dev, with no other input. So the feature hadn’t been technically planned, no real AC was on the ticket, nothing. Just ‘make this happen’.

That was the failure in my eyes – there was no guidance from the developer, and there wasn’t clear lines of communication on this stuff, so he didn’t ask for clarification. He was new to the system, so didn’t have the time or knowledge to really figure out what knock-on effects there were. So I started stepping in a little bit and trying to make sure we had a list of requirements and edge cases.

And I started to google. I wanted to see what other people did, how other companies handled this stuff (at this point our tester had left, leaving me as the go to tester person – did I mention the company was not so slowly going bankrupt?), and I found the testing community.

I think those two moments – realising I’d picked up a bug in the system and then finding the testing community (or the bits I inhabit anyway), were the moments I decided this is what I wanted to do.

And I think a lot of people get pulling into testing because ‘anyone can do it’, and for me it was realising that it goes deeper than that that brought me into the career properly.

I would absolutely love people to let me know how they got into testing. I can’t promise any fancy R scripts and graphs like Rosie Hamilton did, but I can promise at least a blog post on it!

Link to the form

Ep 53: You have no control who lives who dies who tells your story

Thiiings: I have 3 potential interviews coming up for the podcast and I am excited! More details when I get them. I am panicking about Testbash Manchester as I said I’d do a practice talk at the local Drupal User group in August and lols I’ve not even written the thing yet. Ministry of Test is doing a series of webinars, facilitated by Maaret Pyhäjärvi, which I’ve asked to take part in, so I need that topic as well.

Sooo, I want to talk about storytelling.

I’ve always been fascinated by stories. I was a reader as a child, I got lost in words more often than anything else. I read the fifth Harry Potter book the night before my Physics GCSE, staying up until the early hours because the alternative – not reading it – was unthinkable). I always thought it was some kind of magic, storytelling. Later, hearing stories became my obsession, through Ted talks, podcasts, and conference talks, and it’s still my obsession now.

Stories keep you engrossed, invite you on a journey. You’re not just telling someone something, you’re informing them, showing them, bringing them with you on something.

When I started hearing about testers as storytellers I sat up, and paid attention. I don’t have the imagination to write fiction – I’ve tried and I can’t hold a plot with two hands and a bucket, but writing has always brought me joy, and I am always trying to write and speak better, tell my own stories in a way that’s useful and engrossing.

And I realised, as I was reading about storytelling in testing and software development just how much space there is for storytelling in our work. I knew and had used personas before; and how this persona interacts with a product. What I hadn’t thought about is how writing bugs reports is storytelling.

Part of a tester’s job is to advocate for bugs. We report the bugs and in our reports are the whys and hows of raising them, and why we think they should be fixed. Sometimes this is nothing major – this doesn’t work at all, or doesn’t work in this environment. Sometimes it’s a bit more nuanced, “I would expect this here” “I shouldn’t see this because of this reason” and getting the details across fully and in a compelling way is important, because it will get the bug across to people who are in charge of fixing or scheduling the fix.

Sometimes it’s not a bug as much as it’s something that’s not been thought of, or something has been missed, and you need to explain why we need to include the change you’re asking for. Stories can help advocate for things.

So how can we make our stories compelling? First it needs to have a structure: a beginning, a middle, and end. This person went to here and did this and this happened. This is what we thought was going to happen, this is what should happen, this is what we need to happen, and this is why we think this should happen.

Tell the report to someone. This is one reason I’m inclined to talk to developers first when it comes to an awkward bug, or a bug that’s not obvious. I can talk through things and get a feel for what details are needed. If I can’t, or it doesn’t make sense to, I’ll write the bug out in bullet points, with an introduction and end to structure the bug. I make the title relevant (no puns in ticket titles, no matter how tempting. I save all my puns for you, listeners <3), and I make sure I include a desired resolution. Never leave a story on a cliffhanger, people will hate you. A pox on bug reports that are literally ‘the menu doesn’t work’.

Choose your evidence – annotate and refer to the images, videos, numbers you include, don’t just include them without explaining (this is something I am guilty of a lot). Otherwise it’s just decoration and something making the ticket bigger.

Exposition is allowed, and is preferred to a light touch when it comes to details. At the same time, we’re not Charles Dickens and none of us are being paid by the word (this was not actually true, but I like the idea of it). Choose your details wisely.

Write first, then edit before sending it to a developer. Choose what details make sense when you review the entire report.

When the bug comes back to you, detail the resolution – say x was done, or on reflection, y was done because of reasons a, b, c. Finish the story, close the loop. Start again.

We should tell clients more stories. Instead of saying ‘this will do x and y, say, this will allow you/your customers to do x and y, but not a, or b.” or, “we chose to implement this because of these advantages.”

And we should listen and help clients form their own stories. Point out plot holes, and suggest how to tighten the plot up. Offer different opinions, viewpoints, and expertise (you’d send a novel to a copy editor before printing, right?). Help them guide their clients or users or stakeholders through the journey of the site or the app, and make that journey part of a story. When something becomes part of your story it becomes something you care about, and engage with, which is important when it comes to developing successful software. Speak in a common language, and make sure the goal is the same on all sides.

Your user story statement should in fact tell people the story of the feature. As this person, this character, I want to do this thing to reach this goal. Break with the format if needed, but make sure the story elements are there.

Practice. I really like internal sprint walkthroughs. These happen prior to the sprint demo to the client, and it means that the team as a whole gets to look at the work we’ve done. We take each feature ticket, and demo how we meet that criteria. It’s practice for one; the lead dev can find the most sensible way to demo the entire sprint (to tell the story of the sprint, maybe?). It gives the team a chance to review progress as a whole, and make sure everything fits together well.

Hell, storytelling could be a good way of substituting metrics for useful data. Metrics don’t tell you much of anything, but you can at least supplement them with words. X% of stories were rejected with bugs, this is because of x, y, and z, is much better than x% of stories were rejected. Even better would be ‘we had issues with a few stories because of these reasons’, and then move forward, but that doesn’t fit into a graph nicely.

There’s a million things I haven’t done – I’ve not spoken about what happens when the story is taken out of your hands, or talking to people you don’t work with (interviewers, other testers, people who aren’t techy), but I wanted to focus on the sprint cycle.

The whole agile process it an exercise in storytelling, and I think we need to get better at telling them, and about helping other people develop them. Stories are fundamental to human nature – humans are rooted in narrative; we form lives and memories around stories, There’s no reason we can’t continue this in software development, and bring a bit more of the human into the software.

Further reading

https://www.import.io/post/8-fantastic-examples-of-data-storytelling/
http://janetgregory.ca/im-right-im-wrong-all-the-time/
http://www.gmgauthier.com/advocacy-observation-and-the-future/
http://thetesteye.com/blog/2011/10/software-testing-storytelling/
http://firstround.com/review/Lessons-from-Pixar-Why-Software-Developers-should-be-Story-Tellers/

http://visible-quality.blogspot.co.uk/2016/06/resurrecting-signature-series-of.html

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

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 51: Leave No Trace

If you’ve been following the soccer/football news last month1, you’ll have seen that that last match of the season at Old Trafford was suspended due to a suspicious package found in a toilet. After a controlled explosion, it was discovered that the suspicious package was one that was left in the stadium after a training exercise. Now I can think of at least three points of failure here (the training people for not counting devices in and out of exercises, the people being trained not finding the device, and any of the other staff who missed it between the training session and that match day). And it happened on the last match day of the season.

It was a clusterfuck, and it was a clusterfuck that reminded me of the importance of tidying up after yourself.

We try to silo our test environments away from the client – we have an internal test environment, and a staging one that the client works on. The stage site is where UAT happens, and possibly content population prior to go live depending on set up. We also tell the client to play with the site we’re building on stage – this is their opportunity to get to grips with the site before they have to worry about it going live.

The dev site is essentially a bit of a playground – we know the client can’t see it, so we know we can try things out that may break that environment or the client might not ever see, but we want to see what it looks like.

But we still are careful with what content goes on there. Example content should be at the very least bog standard lorem ipsum. Occasionally we’ll put a copy of live content on the staging site, if available, or we’ll make some relevant example content. This is because, firstly, it is a lot easier to test the usability and look and feel of the site with live data, secondly, it gives context to the client, who may finding looking at a bare or unfinihsed site difficult. It’s so easy to get distracted with the bareness of the site that what’s there doesn’t get a proper look over. You’ll note I said content there, not data. And that’s for a reason:

You’ve got to be careful regarding test data. If you need to use live data, and the live data is customer details, then you’ve potentially got some legal issues to contend with. If you’re using credit card information, then the PCI DSS (Payment Card Industry Data Security Standard) will apply to your test environment, and that is a pain in the arse from my brief dealings with PCI compliance. The UK Data Protection Act states that you have to tell people upfront specifically why you want to collect their data and what you plan to do with it. So unless you tell people you’ll be using their data for testing? You can’t do that.

The law sees no difference between live and test environments when it comes to data protection and breaches, and according to one source I found, 70% of data breaches are inside jobs2.

So what do you do?

Sometimes you need live data in order to get the job done, whether that be finding a bug or load testing. You can mask or anonymise data, scrub the sensitive bits out. IF you’re not using credit card details that takes a lot of the data out of the way, but if you are you shouldn’t be able to access it anyway. So that leaves names, addresses, emails, etc. The issue with that method is that can remove any usefulness from the data.

You can generate data; and this can usually be automated. The issue there can be relevance or context of data. Generating data that makes sense within the specific context could be anything from really hard to impossible, and so this might make the data useless.

Or, you make sure your test environments are up to scratch, privacy wise, and see if you can add a clause into your Terms and Conditions to mention testing using data.

Or do what the majority of companies seem to do and just…use the data and hope for the best? No the best plan, I don’t think.

My motto is always don’t test with any content you wouldn’t want a client to see. So I use bugmagnet to fill things with lorem ipsum and email addresses etc. Most of the time it’s not needed but I’d rather not have something just confusing rather than anything problematic.

So I feel that, as testers, we should try to adhere to the Leave No Trace3 set of ethics where it makes sense to:

    1. Plan ahead and prepare

I assume we all do this anyway, but it doesn’t hurt to have a plan, even if its just in your head, of what content or inputs you need to use for this testing. Plan for what you need to do when you need live data or something close to live data.

    1. Travel and camp on durable surfaces

Check your environment and/or devices are ready for you to test. Nothing like starting to test then realising the developers weren’t finished deploying and you end up losing a load of work, or, as in my case more than once, freaking out because the site looks wrong then realising I’ve still got javascript turned off from testing my last story.

    1. Dispose of waste properly

If you need to enter data that’s invalid to test something, clear it out. If you’ve got live data on a test environment, scrub it and/or delete it after use. Unless:

    1. Leave what you find

If you find a bug, sometimes leaving the content or data that caused it (if you can) can be useful for the dev to review. Try not to delete anything you didn’t make in case someone else is testing something.

    1. Minimize campfire impacts

If you do need to stress test, or load test, or security test something, make sure that you don’t break everything? Or give people a heads up so they know what to expect.

    1. Respect wildlife

Yeah, I got nothing. I guess if you have to test on a production environment, don’t change anything that might fuck up the live environment or content?

    1. Be considerate of other visitors

I don’t often test at the same time as other testers or users, but when we have we’ve let each other know and collaborated to ensure we don’t trip over each other while testing things. I try to make it as obvious as possible that I’m making test data and who I am so people don’t get weirded out by random content or changes being made.

If I do have to do something on live, I try to either keep it as inconspicuous as possible (most of the sites we do have the ability to view content without actually publishing it), and I ensure the username and content all scream THIS IS A TEST. And we inform the client beforehand, so everyone knows what to expect. That is rare in my line of work though, so I can’t speak to techniques here.

It’s something I’ve never really considered before, not in this depth, so I thank the three levels of fuckery that inspired this episode, as it’s surprisingly interesting.

Footnotes

[1]http://www.bbc.co.uk/sport/football/36297390

[2]https://www.simple-talk.com/blogs/2011/06/10/using-live-data-in-database-development-work/

[3]https://en.wikipedia.org/wiki/Leave_No_Trace

Ep 50: Vocab or What *do* you do?

Podcast recommendations!

I’ve just started listening to The Bright Sessions, which is a fantastic podcast about therapy sessions for ‘unusual individuals’. Also, if you’ve not listened to The Black Tapes or Tanis yet, and you love your supernatural/paranormal/creepy mysteries, then you’re missing out!

We testers bloody love vocab don’t we? Some of the debates and comments I’ve seen on blogs and in slack are really high level – sometimes I feel I need a firmer background in philosophy and formal logic to even begin to join in. While that’s intimidating at times, it’s also incredibly interesting. I’ve mentioned before how much I love the passion of the testing community. We love what we do, and are constantly striving to be better. As a community, we’re also (unsurprisingly) specific in our wording. Which sometimes leads to debates about wording to the detriment of the actual discussion going on (I’m sure I’m not the only one whose seen a discussion on twitter shut down by someone replying with ‘you mean checking’ and then patting themselves on the back – so clever! That is another rant though. For the most part, we’re a friendly bunch).

One of the debates that is always going on is the subject of vocabulary. The testing, not checking debate. The controversy around certifications and what counts as ‘professional testing’ anyway? The one I want to talk about it one that I struggle with a lot, and that’s the subject of job titles.

When people ask me what I do, I say I’m a tester. My job title is QA tester. I do like the idea of testing the quality assurance that our company does, and in theory, I do do that.

When you’re testing, you’re not just testing the functionality in front of you. You’re testing assumptions, both your own and that of the developer who built the work. You’re testing how the feature fits in with what has come before it. One of the reasons I am so insistent on meeting the client as early as possible and being in workshops for requirements gathering is to get a feel for the client, their business, and what their priorities are. For example, we have a client that is really visual. Most of the time we need to wireframe features, or sketch them out as he finds it hard to fully visualise something using words alone, so we know to be more vigilant on the front end side of things. But it’s only through meeting the client and gauging their priorities that we know where to focus.

QA is the whole team’s responsibility for the most part, from the start of the project to the end (there are some contexts where one person being QA makes sense, but it tends to be more regulatory than testing). There are plenty of people who talk about this better than me, and I’ll link to them in the shownotes.

When I introduce myself, I say I am a tester, though that feels like I’m mis-selling myself. Hell, most of the podcast is less about the nitty gritty side of testing and is instead about requirements gathering, and building the right product. That’s where my priorities lie. I love testing, exploratory testing is seriously one of my favourite things, but I much prefer doing that on something I know (to the best of our abilities, and in the context of the project) fits the client’s needs.

However, I’m also aware that without the term tester? I wouldn’t be here, doing this. I wouldn’t be in slack, I wouldn’t have gone to Brighton. The community we’ve built under this ridiculously broad umbrella is wonderful, and without it, would this community exist? Yes, a rose by any other name etc, but would the community find another umbrella term.

I don’t think I’ve come to any great conclusions here – I still have no idea to describe my job function. I love the idea of testing QA, and then UAT can be the client testing our QA process as well, but other than that? I have no idea. I’m grateful we all identify broadly as testers, regardless of how ill-fitting that term is, because I love talking, reading, listening, and meeting you all!

More reading

http://visible-quality.blogspot.co.uk/2016/05/boxing-tester.html
I’m QA. It’s in QA. It’s being QA’ed. You sure about that?<

Ep 49: Leading the Witness

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 48 – (Tron) Legacy

Gotta have a Wanz reference in there, though he may hate that it’s a reference to the new Tron…

We inherit a few legacy systems in our line of work. We have to get to grips with them across the board – PMs, QA, devs. We all need to know what the system does, how, and most importantly, why.

How do we do that?

Firstly, we do an audit of a site we’re inheriting, before it comes over to us. This will help the developers and system admins get to grips with any quirks of the code, or hosting needs. We can also do a security audit, make sure modules are upto date, if it’s magento make sure we know of any module licenses that need sorting out, etc.

Then we start on the actual functionality:

At this point we’ve had interaction with the client, so we’ve got a sense of what the site is for, who it’s for, what the business area is. We can get an idea of what they business needs are and how the site meets them (or doesn’t). But sometimes the client doesn’t have the in depth knowledge of the site, functionality, or code that’s needed to support the site.

Documentation is always useful, even if you can only see a user guide or other internal documentation, because that gives you insight to what bits of the system are used most often and what features or information is needed by stakeholders.

If documentation isn’t present or is old, then the code is another form of documentation. You can talk to the devs about what they’ve found, or even sit with them while they figure it out.

Finally, there’s the galumphing and seeing what you can find option. Paired with either of the previous techniques, it’s a good way to get to grips with the system, and start to test it; even without anything to test against, you can test your assumptions.

If you need to do it by itself, it that’s how you need to find out about a system, then it’s not going to be as comprehensive, but still useful. While you may not have any requirements, you can still get a basic structure for your test session, so you can time box and manage it properly.

So a basic structure may be something like:

Figure out inputs (valid, invalid, multiple, etc). Even if you know nothing about what you’re testing, if there’s a UI you’ll have cues or types of input that is accepted, then you may be able to make guesses on valid/invalid inputs from there
Outputs (with all the inputs above)
These can take the form of reports, data, messages, all sorts of outputs based on what you put in
Dependencies and interactions. From the above, can you see the flow of information. Can you see what happens if something fails along the way? Is it possible for the system to fail in that way?
Hypothesize on what you’ve learned, what inputs and outputs connections you’ve found, any other information that’s pertinent.
Repeat the above until you’ve narrowed down the expected results

Take notes. This can be the start of your documentation if needed. You can write up your findings and then talk to the team (and I include stakeholders in the team here), see where the gaps in your knowledge are.

You may be able to start writing tests from there for regression, if there are no tests present, or not enough tests. All new functionality should have tests, and if there are obvious tests that can be added, add them when you can. Each sprint should have a section for updating tests as needed.

Worst case it the code isn’t up to the standards of your agency/developers, or it could be under maintained. You may or may not be able to refactor it to be to your standards or liking, either way you can add tests asap to build the quality in and start to improve as needed.

Legacy systems may be awkward, and I’ve focused on the most awkward here, but it can be interesting, and you can learn a lot from picking up an old system and seeing where you can run with it.

Ep 47 – Beyond Unreasonable Doubt

As I said last week, I’m going to talk about unreasonable doubt.

‘Unreasonable’ doubt (for these purposes) is when you doubt your own abilities wrongly – imposter syndrome, or under estimating your own abilities, maybe due to inexperience.

Sometimes this can be a good thing; doubt about a skillset you have can be a motivator to learn more and become better, but it can be detrimental; holding you back when you have no need to doubt your abilities.

I think you can tell the difference between the two – imposter syndrome is a lot more anxiety inducing than being inexperienced is. If I don’t feel confidence in a specific area, it feels like a weakness (even if I’m not actually deficient in that area), but a specific weakness. Imposter syndrome is a much more overwhelming anxiety, one that is much more diffuse; its not an area or two that can be pinpointed, its everything you are and do in your professional world.

I want to talk about a few different strategies for tackling these kind of doubts.

I’m going to start with being new, or inexperienced.

I read a brilliant blog post this week about being ‘a dumb girl in computer science’. It’s really good – it’s about just saying loudly ‘I don’t understand’ and people coming together to help each other out.

Asking questions is really important! And yeah, sometimes it does feel like showing weakness, but everyone’s been where you are, and a lot of us still are – the world of testing is huge (and I think this applies to all spheres of professional life), and you can’t know everything and all things.

So question things. You may get corrected, in fact, through your career you probably will get corrected. Firstly, try to step back when someone corrects you. Assuming they’re not being a cockwomble about it, they’re helping you out. Also, don’t be afraid to question their corrections. They might be wrong? Both of you could be wrong? Start a discussion, go somewhere with it.

You could try focusing. This is something I’m having issues settling on. I’m very much like a magpie in that I’ll go ‘ooh, shiny’ and go over there for a bit, then get bored and never actually sit down and focus on anything (like this podcast!). You may find, if you focus on one or two areas that interest you, and settle on those, becoming more knowledgeable, keeping upto date, you can carve a place for yourself, and feel a bit more grounded and ‘deserving’ of your place in your professional world.

While some of these may help to lessen your imposter syndrome, there are some steps you can take help tackle imposter syndrome specifically.

Talking about it is a key step (yes, it does feel like you’re fishing for compliments, but sharing experience is important). This is a thing that a lot of people suffer from, and so you’ll get a sense of solidarity and knowledge that it’s not just you. It will help.

Studying is sometimes recommended, and while professional and personal development is important, if the motivation is to combat imposter syndrome, you’re gonna get worse, because there is always a lot of stuff you don’t know, but that doesn’t make you a fraud, it just makes you human. However, if you’re aware of a deficiency in a part of your skillset, or something you want to get better at, it’s good to build on these, and it might make your foundation solid and help you find your place.

Share. Tweet, blog, vlog, podcast. Sharing has so many pros – it’s good for you, and good for others. Talking to others will help you structure your information, and will let you realise how much you do know about a thing. Share what you know, and, what you’ve discovered, what you succeeded and failed at. People will listen, and interact, and bring you into the community. Don’t want to maintain your own blog etc? Comment on other people’s’! Retweet, become a curator of awesome, because you’ll be reading this stuff anyway, you may as well share.

Comparisons will kill you slowly, they will. You have no idea what people are choosing to trade off when they do all these extra-curricular things, you just see them fly about doing talks and running events and holding down a job and they’re probably an awesome friend who sends you random texts once a week to see how you are, and has the neatest house in the world but maybe that person leaves toast sweat on their kitchen counter. They drink milk straight out of the carton. And they have a secret love for Sex in the City 2. You see the point I am making here, yes? Most importantly, they probably feel the same way as you when they think about themselves.

Therapy and drugs. I’ve spoken before about my clinical anxiety, and it may be that you need some professional help. Imposter Syndrome could be a symptom of some larger issues. Get help, reach out, if you need to. People will help you, and needing help is not something to be ashamed of. A therapist is a great impartial ear, and nothing deflates your jerk brain like having to justify it out loud. Practice kindness to yourself and others.

This isn’t a comprehensive guide to overcoming doubt. This shit is hard, and it’s hard to maintain, and some of it won’t work. I’ve taken a fairly lighthearted approach to this, but don’t mistake that for me making light of this. I know it’s hard, and I deal with it on a regular basis. If you need to talk, reach out, whether it’s to me, or to the community, or a loved one, or a professional. (Incidentally, would people find an episode on how to respond if people reach out to you useful?)

Further Reading:
https://mental-health-support.herokuapp.com/
testersio.slack.com
ministryoftesting.slack.com
http://geekfeminism.wikia.com/wiki/Impostor_syndrome