 Welcome everyone to the session, The Lazy Tester by Hannah Pretzwell. What do you, Hannah? Hey, hey everyone. Yeah, just want to say I'm really, I'm so excited to be here. It's really an honor to be like in this lineup and to be a part of this conference and this community. And I hope you've all had an absolutely fantastic day and seriously like well done to everyone who's spoken and who is going to be speaking like, yeah, you should all be very proud of yourselves. It's not easy. So well done. And yeah, welcome to my talk, The Lazy Tester. I'm Hannah. I'm a test engineer, technically not working at the moment actually I start a new job at a company called BGSS in a week's time. And it's my first new job in eight years. So I'm pretty nervous and excited so please wish me luck. I am the co-organizer for the Ministry of Testing branch here in Newcastle. I also help out with a North East based general tech meetup called any tech and a conference called the Geordie Tester Talier. I have way too many hobbies. I'm not going to go through them all though drawing is a big one which you will see as we go through the slides. And I dislike tiny things like spiders on the opposite spectrum, really giant things like church pipe organs. They just make me feel E and writing about me slides because I never know what to put on them. And I hate being bored. So you can probably guess that I can be pretty lazy sometimes because I find a lot of things boring, especially things like washing the dishes. So now quick disclaimer, I'm going to be taking you through a bit of a story in this talk and it is based on true events that did happen, but you know they have been edited and fictionalized slightly just to produce a more compelling story and also to just not bore you all with those details. Let's go. Once upon a time, there was a large financial institution who like to continuously push out new features in their applications to encourage new customers and to increase existing customer satisfaction. They had many, many different departments, all with many, many different projects, and within each of these projects were many, many teams, all with pretty standard team structure, and all those within a project were contributing to the same code base. On this particular project, around 20 teams were all interlaced in the spider web of dependencies and they had very strict deadlines to boot. One day, one of the testers came back from a wonderfully relaxing holiday, only to find that a production bug had been found and raised by a customer on Chromium on Linux. And it had already been agreed that browsers on Linux would be added to the list of browsers, operating systems and devices to be tested during feature, regression and sanity testing. She panicked. How is she ever going to find the time to test such a thing? The deadlines were strict, and especially with testers having to run already pretty painfully tedious regression suites every release. To her surprise, no one spoke up. It had been universally accepted that yes, somehow, time would be found to test on Linux. Well, she thought she could not be having that. I mean, for starters, there must have been a reason why Linux was not previously in scope for testing. And there was a reason. Multiple, in fact. One, pretty much no one used it. Two, everyone in the teams worked on Windows, so you'd need a VM or a remote machine to test. Three, they already tested supported browsers on Windows. And four, it had been agreed already within the browser support document that Linux users were responsible for their own support. She sprang to action and went on a journey to find out what has happened. She hunted down the testers, the architects and business people who would all agree to this and challenge them to an epic battle. It was really just a lot of tedious back and forth until there was an agreement that Linux would not need to be tested on. The whole experience was pretty frustrating. And it left me with quite a few questions. Why was it just assumed that testers would have time to take on the extra work alongside their already tightly packed schedules? And was there that little value placed on the work testers were doing that it's just assumed that they can easily take on more tasks without any question? And why did no one else speak up? Surely they aren't all happy to have this extra work fall on their plates. And to cap it off, after so many calls. It turned out that the Linux bug was actually reproducible in browsers across all operating systems. So, yay. And so, yes, weeks were lost arguing with people, even arguing with testers who were happy to be testing on Linux, which did baffle me. It's like, why do you want to do more work? And, yeah, all of that time spent just so that I wouldn't have to do an extra bit of work during my day to day life. The whole ordeal had me turning to my boyfriend exasperated and joking. I am so lazy that I will work hard to not have to do work. And the seed for this talk was planted. So what actually is laziness? Laziness is defined according to my intensive Google research as being unwilling to work or use energy. Now, I've spent my whole life being called lazy or calling myself lazy. And I'm sure quite a few of you can relate to this, you know, you keep putting off doing the dishes or you keep meaning to call the doctors or you just can't bring yourself to type that one email and you keep putting things off and off and off. And when things pile up and cause stress, you just think, why am I so lazy? And it just got me thinking about the word lazy. It's often used to describe like a perceived moral failing of someone like you, you haven't done this therefore you are lazy. Is it really all down to the individual? When I was on the project in the story, I noticed something interesting when it came to time to run the manual regression suites. Other people could just get on and do it. Sure, they'd complain and they'd moan and grumble, but they just get on with the work. And I'd watch an amazement. You know, when I sat down to run the test scripts, I'd be hit with an almost physical pain in my brain and in my body, this ungodly ache in my soul that made me squirm and wriggle and honestly sometimes cry. And it would, it wouldn't be until the last second that I would actually be able to get on and do the work. When I was finally driven by enough fear and anxiety and adrenaline to overcome that pain. And I could just never understand how everyone else was able to deal with the pain. It made me feel so weak and terrible and lazy. Funny story though, not everyone has to deal with that pain. I remember turning to my coworker and asking him how he deals with the boredom pain and he was like, what pain? So it turns out, yeah, I got a diagnosis in the last year that I have ADHD, which explains quite a bit. And one of the symptoms of ADHD is something called executive dysfunction. So executive dysfunction can affect a lot of things in life, but some of the main problems that it causes that I think are related to this perceived laziness are. A struggle to get started on tasks, even if you enjoy them, and it can be so much worse for tasks that you don't enjoy. There's a struggle to stay focused on tasks, you get distracted easily. And there's a struggle as well to follow instructions. And this is a really good reason actually to get computers to run complex, boring, or repetitive test scripts. That computers are so much better at following instructions than humans are, you know. And also it frees up humans to use the most valuable tool at our disposal, our brains. But if someone from the outside is observing these behaviors, they'd likely just brand that as lazy. Oh, they're procrastinating. Oh, they're on the phone again instead of working. Oh, they they skip that step in the instructions are obviously not paying attention. But we can see here that laziness isn't a cause. It's a symptom. It's often a mix of brain chemistry and environment. Try and get someone who struggles with executive dysfunction to do a boring task and you are going to have a bad time. And it's not just people with ADHD that can struggle with executive dysfunction. It can also crop up with other neurodevelopmental conditions like autism or mental health conditions like anxiety, depression and chronic stress. We should be striving to create not only a more inclusive workplace and not just for people who are neurodivergent, but a better workplace for everyone. I mean, who wants to do things that they don't want to do. So I think we're all familiar with the term burnout. It's been a firm part of our vocabulary for quite a while now. But for our, however, it's a relatively new new term. And it was first coined in 2007 by Peter Verde and Phillip Rothland. And I only came across this term when I was actually researching what I wanted to talk about in this talk. And by the definition that Peter Verde and Phillip Rothland give its clusters feeling boredom, feeling a lack of challenges, a lack of professional interest in the workplace. So according to their definition, boredom is as we understand it to be, you know, got nothing to do, or you've got dull, meaningless, repetitive tasks. A lack of challenges is when someone feels that the tasks that they are doing are below their abilities. And the lack of professional interest is seen when people experience a loss of interest in their job, their company, or even their career. And it's a cousin to burnout, potentially just as dangerous, but in its own sneaky ways. You can literally be bored to death. People who experience frequent boredom are more likely to suffer from heart problems and are more likely to take part in unhealthy behaviors such as lack of exercise or increased alcohol consumption. There's also a lot of shame, anxiety and depression and mental health issues that are associated with burnout. You know, it's generally culturally accepted that it's okay to be stressed out if you are busy and you're overworked. But if you complain about being bored, it's often met with a, oh, I wish I had that job. And this attitude can lead to a feeling of shame, you know, that you should be happy with a job like this. And it can lead to less motivation to ask for help. Anxiety can often come from worries about job security. If you're finding aspects of your job meaningless, surely that means someone will find out that your job is pointless and let you go, which, you know, it's not going to happen. But it does make it difficult to ask for help in those situations and it can spiral this feeling of being trapped and this feeling of helplessness. And suffering from bore out, just like with burnout, can have massive impacts on your mental health and your self-esteem. And it can even impact your career in general. You may end up not wanting to apply for new jobs because you've been worn down from hours of boredom and feeling like your role on you are not valuable or not good enough. And it's not just bad for you. Employers should take notice. As studies have shown that happier workers are more productive workers and unhappier employees does lead to higher turnover. I think it's good for everyone really, you know, try and take notice of the day-to-day tasks and routines that might be leading towards feelings of bore out and burnout. And I do have to say that I realized that I related to a lot of what I was reading about bore out, especially over the past few years. There was a lot of factors to this. And especially with one of the projects that I was really struggling with. Combined, you know, with basically working, living, sleeping, eating, all in one room, like I barely left that one room. And it really did start to take a toll. So now I'm trying to, you know, take steps to recognize where I'm starting to see, you know, these feelings of burnout and bore out in my personal life as well as my work life. So starting to identify places either currently or from past experience where I can see behaviors that I think have a high risk of bore out. I've all heard of the story, right? I think that this fable quite easily helps describe how I feel about the way that a lot of projects, teams and people do end up working. So just a quick recap, you know, got the tortoise and we've got the hare. They're having a race against each other, you know, everyone thinks that the, that the hare is going to win because obviously it's faster tortoises are quite slow. But actually, the hare ends up taking a nap somewhere. And the tortoise just plots along and its own steady pace and wins. And I think most of us would like to strive to be the tortoise. It's a steady, keeping up consistency. He plotted along and obviously winning. And you know, you just know that you've worked hard, but it's been, it's been nice and stable, rather than getting towards the end of something and having a panic and a rush to get something over the finish line. And I do think it's easier to apply the tortoise way of working to our private lives and our personal projects, when it's just you that you need to hold accountable. They're saying that I am pretty bad at slow and steady and very much leave it to the last second and then panic, but I'm trying and working on it. So a few of the things that I've observed over the years and I'm talking to people is that you tend to find that projects and teams fall into the same kinds of pitfalls. And they can be really hard to get out of once you're in. Often in the rush to get something out and customer facing things like testing, get left behind in the dust. And the project can suffer because of it. You're probably aware of, you know, instead of spending more time now for the long term benefit, we see things get pushed aside for short term gain. And this can often lead to higher expectations from team members, external stakeholders and even from yourself. And it can trap you in a cycle where if you ask them all resources or more time, there can be a lot of pushback because, well, you did it last time. The quality or any other standard is starting to drop. And some things that I have seen that I think are real red flags that what you're doing is headed down this path stuff like not fixing bugs. So often bugs deemed as low priority, especially if they are small, small UI issues can just get left in the backlog. It starts off as just a handful, fine, yeah, fine, whatever, but eventually they can build up and you end up with a much lower quality product. First impressions do matter after all. And the majority of the time, the first way a user interacts with the platform is via site. And then it has the added knock on effect of becoming harder and harder to track what's already been raised. And you can end up with a big mess of duplicates and people wasting time raising bugs that are already known and logged or wasting time having to search through everything to see if see, you know, that bug has already been written up. Or you end up with people not logging bugs because they just assume it's already been caught. Another one is not automating repetitive tasks. So I'm not suggesting that we automate everything. I am a big fan of finding balance with these things. I also don't just mean automating just sweets and just front end UI and things like that. I mean like automate any boring tasks that that you can. And to give an example of this. I was once set the task of testing installing upgrades for a desktop application. It had to be done for every new production build of the software and it had to be done on windows and on Mac. So we have some repetition there. And yeah, that to be done a couple of times a month. And it was it was tedious. Lots of uninstalling reinstalling updating uninstall reinstall all these and checking versions as well. And just doing this over and over again for different scenarios. And I ended up like reaching out to a developer just been like please help me please help me because this, you know, it feels like hell on earth having to go through these. And he helped me write some bash scripts to automate the majority of the process. I still had to go in manually and check that the that the versions were correct. But most of the stuff leading up to that point, I managed to use these scripts to just run for me. It did take some time and effort upfront, but it saved time and my sanity every single time that I had to do this task. Another one, and this is a big bug bear of mine actually is is not prioritizing fixing or creating things like test tools. And the main one that I see has a big impact is neglecting test environments. I've seen this on so many projects where test environments are slow, or they're flaky, or they have incorrect or missing data and you can end up spending more time battling with environments than actually testing. Like how many of you have spent ages trying to hunt down a bug, just to realize it was the environment. I've even seen bugs get on to production, because the environment had issues. And there was an error that would appear in a certain scenario every single time it happened the years and, you know, every time you brought it up with the others, that's the environment, which is true. Until it wasn't. And by being more like the tortoise and taking time to do stuff now, rather than constantly pushing it back to later and provide many, many benefits. It allows us to slow down and it gives us time. You get time to think and time to really analyze everything that you're doing. I had a really good question posed at me recently, which was how much testing is too much. And I was like, hmm, this is a question that comes up quite a lot, you know, we discuss a lot that conferences at meetups and Technically, you know, you are never done with testing since you're never going to find all the bugs, especially in some of the insane complex software that we tend to be working on. So how do we decide what to focus our testing efforts on. I think the important thing here is that you need to have the time to really critically analyze what is in front of you. We often do risk analysis when deciding when to spend where to spend the most time testing. So, you know, we focus on areas that have, say critical business logic, or, or the areas that are used the most or using past knowledge of spots for bugs can really help narrow down how much, you know, how much you need to do where you need to where you need to test and just where you need to get to to be able to say, okay, enough is enough. And the problem is, when you don't have that time when you are rushing through life, that sort of stepping back and thinking and analyzing can get thrown out of the window. And what you end up with is almost mindlessly testing just a bit of everything. And you end up not taking the time to make improvements that can help with process, either by speeding things up or reducing mental load. And I've been in situations like this in the past and I'd be surprised if anyone hadn't and my quality of work and my view of myself suffered. So I think it's really critical to be given the time to get a clear head and to question why, why are we doing something. And this all ties back into the story that I told before. So we take a look at it the, the environment, the environment that we saw was very, very complex team, very complex project structures and a complex platform. And because of this complexity, it was so easy to change something in one place and break something in a completely different unexpected area. And there were also very tight deadlines. No, it was very much like a go, go, go, go tight place and it never felt like you could just stop and breathe. We got told plenty of times, you know, you can take, take time, you know, step back, push back if there's too much work, but it never felt like you could. I think that that really contributed to that situation of, oh no, oh no, bug, bug scene on Linux and proud. We don't test on Linux. We have to test on Linux. And once that train started going, it was so hard, you know, not an impossible to slam on the brakes and go like, whoa, whoa, stop. Are you sure? Are you sure that's what you want to be doing? And I do have to admit here that when I launched into my no testing on Linux fight, I was not thinking, oh, we, okay, we need to slow down and we need to consider this. My thought process was just as panicky and just as frantic. I was just filled with such utter dread at the thought of doing this extra work, whilst knowing that there wasn't that, like, there wasn't any value in spending the time, the extra time testing on Linux, since we already tested Chrome on Windows. But looking back, you know, if I was thinking about it properly, I would or should have approached it using some of the ideas that I mentioned on the last slide. I was questioning the severity of the bug. Why it wasn't found earlier. And whether instead of testing on Linux, maybe we should be looking at that area of the application and wondering figuring out if it gets enough care. But that's how we learn if we have time to reflect. And this is why making the time for things like retrospectives is so important. I feel like I couldn't really have a talk about slowing down and creating more time and without mentioning retrospectives. And this could be retrospectives as a team. You know, going over the last sprint and thinking, okay, how, how did we feel? Did we achieve what we wanted? What would we change? And also having the safety to be able to say, my work is too boring, I'm not challenged enough to repetitive and figuring out as a team how this can be rectified. But I know that safety is difficult to achieve. But the more that we can talk about it, the more that we can change and don't even have to do retrospectives on a team level, we could do them as individuals as well. I was talking to a friend of mine recently who was saying that they take half an hour each week to just reflect on the past week and think about what they achieved, what they didn't achieve, what went well, what went wrong, how they felt, and what circumstances might have contributed to all of that. And then, you know, considering the future, considering the next week, what could they change? What did they want to remove? What did they want to improve on? And I think this is a really, really good idea. And I'm hoping to implement it when I move on to my next role. I'm very excited. But we can only really do that if we have time to do it. And that's what this all really boils down to. It's time. It's about minimizing the amount of boring tasks and the tasks that we perceive as lower value or repetitive. And taking back that time and using it to focus on the areas of our day-to-day roles that we really value, the bits that we really enjoy, and the bits that we think improve ourselves, our teams, and our work. So, my final message is, be more lazy. Recognize when you are starting to feel lazy, you know, when you are putting off tasks that are there, when you are putting off tasks that are boring and dull. And analyze whether these tasks can be automated or removed and really look into what value they bring to your day-to-day life and to your project, to your team, and to you. I'm trying to minimize the boring stuff so that I have more time, you know, not just for drinking tea or boring pictures. It gives me more time to focus on the parts of my job that I really enjoy, you know, the fun problem-solving challenges and getting into that creative mindset and learning new things. It's being able to really get my brain engaged that keeps me thriving and excited for whatever is coming in the future. And yes, we do all have aspects of our day-to-day that are boring and monotonous. You know, I'm one of those people that terrible at filling in time sheets. I always put it off or I forget it and, you know, we can't avoid all of it. There's always going to be something that we need to do that we don't want to do. But the more of it that we can minimize, just like buying a dishwasher to help with the dishes, the more that we can spend on the stuff that really, really counts. So, be more lazy. Take the lazy way and do more of what you love. Thank you, everyone, for the listening. Is there any questions? Thank you. There are some questions in the Q&A. Sorry, I think I don't know if my sound's gone down, but you're quite quiet for me. Please repeat that. So there are some questions coming in the Q&A section. Ah, great. Fantastic. Ah, here it is. Let me have a look. Okay, let's have a read. So Noresh asked, when we are busy doing busy work, it is a slippery slope. I understand that we need to take time to create time. What clues can we use to stop us before it is too late? Oh, that is a difficult one. I guess it depends on what you mean by busy work. If you mean the kind of work that you don't think has much value, but you're doing it just to keep busy, then I think that that is a clue that you are already on that kind of slippery slope. It is really, really looking at what you think is valuable and whether it's worth you spending your time on that thing. And if you mean just you've got a lot of stuff going on and you feel like you don't have time to actually step back. I think for me, and this is, again, this is all pretty difficult to do. You need to have a good team, a team that you can trust, and I think a team that is very invested in all aspects of development. You know, you want a team that is invested in testing as well. And I think it's being able to go to them and say, you know, I do not have time to step back and kind of take a bigger picture of you of what we're doing. So, you know, I need help to do that, you know, if someone can come in and help me, or we need to push back a little bit on a deadline, or we need to, you know, stop putting in so many features and just kind of take a little take a little pause, take a little step back. I hope that helps. I've got another question here, which is from. Kira Bakaran. Sorry, I feel like I just pictured that, but so good evening. How to manage when our plan doesn't work. Sometimes our plan might not work. So is that okay, not to keep planning. Not quite sure what you sort of mean by that. I guess if a plan kind of doesn't go to plan. That's kind of what respect retrospectives are for, you know, you, you do it sort of little little iterations, you go okay, this is our plan for the next two weeks, you know, as our sprint as our goals. When you come to the retrospective, you, you say, you know, we either have or we haven't hit what we wanted. So we need to review kind of what we're doing. I hope that answers the next one from Guarov. Love the presentation in the graphics. Thank you very much. Any thoughts on how you create this psychologically safe space for your team to be to be lazy. So this is, yeah, this is a question that I don't know if I can really answer. I relatively recently, I say relatively recently, I think it was like two years ago. I wrote a book called the five dysfunctions of a team. And one of the dysfunctions is not being able to, to, like, not feeling safe and not being able to bring up issues. And really, it's a team effort. And I think that that should be sort of championed from like a scrum master or someone, because, you know, they are, they are the people who are almost responsible for the team kind of working together well. But in terms of creating a psychologically safe space, I think it is just having, you know, from like from yourself, it's having the confidence to bring up something to say when you're not happy. And then waiting to see what the reaction is if people react in a bad way that makes you feel unsafe, then maybe this actually isn't a good team for you. But if they react in a way that makes you feel safe and they respond positively. Then, you know, that's good and you can kind of, you can go forwards with that. And I think a lot of it is being able to bring up constructive criticism as well. And I very much recommend the book, five dysfunctions of a team. It's fantastic. So I think next, next question from Charlie, I think if there is any ask for automating test cases which are not used by anyone, what will be your call on that. I mean, sort of test cases is in that area of the software is not used by customers, then I feel like testing that area would be redundant as we'll be working on that area as well. It feels like maybe it should just be kind of scrapped. If the test cases are not run by anyone like manually run by anyone, then I guess question why, you know, I guess if they're not being ran them must not be value or perceived value in those cases. And so automating them is probably just wasting your time if they don't have value already. Thank you. And thank you for all your really nice comments. And thank you for watching. I really enjoyed that. Thanks for sharing your experience with us today.