Success & Grief

I know this isn’t related to testing or quality but I wanted to air it as it does affect my interactions with people and the community.

It has been a year since my wife passed away unexpectedly. Unsurprisingly it was a difficult year and I’ve really struggled. At the same time I’ve had what many might consider a successful year. So how do these conflicting matters combine?

Not great.

My lowest points (since those first few weeks) were coming back from successful conferences and I’ve felt similar after having a really great day with work.

When we succeed, as humans we want to share our achievements and what makes us excited. The natural person would be your closest friend or family member. Both of these were my wife. Consequently when I’ve succeeded, that natural want to share and celebrate has kicked in but I can’t do that with the one person who matters. They are gone. Forever. The high is met by an equal reality crash. It makes me want to run and hide after a good day. From a good day.

This leads to a dilemma. I want to succeed in work and I really enjoy being involved and attending conferences but ultimately they leave me in a darker place. How do I manage this? Other than holding back and not trying to succeed, I really don’t know.

Experience Reports Ramblings

2023 – A Reflection

It has been some year. I started in a dark place with lots of change underway. However it is, professionally speaking, been a bit of an immense year.


Building upon my first time speaking at a testing conference in 2022, I’ve been fairly active. From running a threat modelling workshop for a small set of people at an Edinburgh MoT meetup to tackling a new topic within security at TestBash UK with a range of activities, it has been really positive. I’ve started feeling like I’ve gotten my name out there and importantly, people seem to like what I’m sharing.

Whilst it can be an exciting (yet nerve wracking) experience to speak and of course having positive feedback and comments makes you feel great, I think the biggest buzz is when people take something away. Speaking always seemed way out my comfort zone but my passion for the topics drove me to give it a go. Consequently when it goes well and you think people are learning and will try out things themselves, it makes it all worthwhile.


Building upon my speaking, I took my Threat Agents game to a cyber security event for my work. We used it in the threat modelling workshop and I spoke a little and got involved in helping people. I even got a special award within my work for contributions to threat modelling!

Somehow, despite only working part time for a chunk of the year, I’ve managed to achieve a few awards from work, given by peers. This obviously means a lot. However I think a lot of it comes down to…

An Interesting Role

This year I’ve taken on a new role. Whilst I originally dubbed it as a “Free Range Tester”, in reality it has been a senior test engineer who doesn’t test. I have tried to both lead and support.

It was a difficult start and a frustrating one. Quite quickly I learnt why we were struggling to ship a release. I was also distracted with extended leave, reduced hours and helping run our intern program (I even wrote some code!).

But the role has gone well.

My crowning achievement has been my work on analysing our quality for the first major release in a long time. We analysed bugs, reflected on our challenges and took actions. I brought all this together into a presentation (not given, just shared).

For example, whilst a large portion of bugs were attributed to internal mistakes when working on stories, several issues we found, raised and fixed were actually legacy behaviour. We made the software better through these bugs. That is good to know.

It has been quite interesting having this roaming role and getting involved with different teams. As we no longer have a scrum master, I’ve helped fill a little of that void. I’ve had the opportunity to learn how different teams are working and help them with their challenges.

I’ve also been there to help teams out when they are stuck on testing. Who would have thought that getting rid of testers would impact a team’s ability to plan their testing?

I’ve also had the opportunity to get myself involved with the wider organisation. Whilst I’m a shy & timid person most of the time, ask me for my opinion and I’ll give it. And even when I wasn’t asked, I sometimes offered it. Having a culture where anyone, either senior leaders or that weird new tester guy across the ocean, can speak up is wonderful and I definitely appreciate it.

Whilst I haven’t succeeded in getting the organisation to test better, I have raised awareness. I have got allies. This won’t happen overnight but I am confident that in time we’ll get there and what is exciting is that I think I’ll be involved and part of this.

It is a real step forward.

A step back

Unfortunately not everything has been coming up amazing.

I fear that I’ve lost my appetite for actually doing testing. Given how much I love the profession (I’ll post about that separately later), whenever I have some free time to do testing, I’ve often found myself not bothering. I’ll admit that I’ve often found myself reaching over to my Xbox controller when I could, and should be testing. I’ve found excuses not to do actual testing myself. Some of that is semi legit (“managing my energy levels”) but also I know that a bit of the hunger is gone.

Part of this is not having the domain knowledge of the past. Moving to a new, large area when outside a team has made on-boarding very hard. I’ve found it massively overwhelming to try and test a feature that I don’t know, which is part of a very complicated solution full of TLAs and systems named after random comic book characters… and my energy levels & brain capacity are both low.

Strongly held opinions that are easily changed

One other thing that I wanted to reflect upon my opinions and ideologies. I’ll write a separate post about it in due course, but I started the year feeling pretty certain about how things should work but have come to be more flexible over time this year. Maybe there is method in the madness?

Perhaps I was wrong to loathe test strategies so much. I wonder if those times when I was doing copy paste reports that no one really read or cared about tainted me too much?

Challenges ahead

Next year scares me a little. I feel like I’ve over achieved this year and despite knowing I’ve not worked and pushed as hard as I could have, there’s nothing left in the tank.

It has been a draining year.

Next year I think rather than trying to excel and push, I want to build stronger foundations. A wonderful new hire within my work means that I don’t need to push. Just be there to support and be involved.

I am hoping that I won’t need to push to get involved, to get the testing mindset involved, as before. I’ll be there by default. My challenge will be, how do I provide that coaching now that I’m present?

To achieve this I will need to learn how better to coach and help the teams develop their testing. Thankfully we now have 10% time at work so that will be my focus. Having a day each sprint that I can dedicate to the coaching side of things – either by getting time with devs to try new things or just researching & learning, it will help a lot.

However most importantly, I do want to test again. I love testing. I want to find that drive in me again to go try and find those hard to find bugs. To remind everyone what it means to be a tester.

Experience Reports

Running Workshops

A little while ago I was asked about my experience and learnings from running workshops and what advice I have. I thought I’d share my thoughts on here.

As a quick note up front, I am under no illusion that I’m not an expert and am still learning. I did also look into teaching as a career so some of this is influenced by what I picked up from that.

Expect to fail

Timing will be hard and when it comes to activities, people will be slower than you expect. For example when I first ran my threat modelling workshop it included an activity I assumed that an activity would be 2-3 minutes break from slides and brief re-enforcement of knowledge. Fill in this, bish bash bosh, done. I got Hannah, my wife who wasn’t from a software background, to try and it took much longer (5-7 mins). It turned out that the group needed that time and many people didn’t finish in the 5 minutes that I set aside or the 2 mins extra that I let it go on. I’d suggest finding a newbie and definitely make sure you have room to flex.

Exercises that don’t need a fixed end point (e.g. have a debate/discussion, write your reflection or practice writing these tests) can be handy when it comes to giving you that flexibility.

Not everyone will understand what you’ve just taught or appreciate the point. Don’t fret about that. Maybe have a resource that you can point them to, or get them working with someone. One of the key advantages of workshops is that you can support different learning styles so for those who struggled to understand your words, perhaps they will benefit from pairing and more collaborative learning.

Be wary about asking questions early. When I was teaching I learnt it was good to ask the group questions rather than just unloading information. However don’t expect a room full of shy geeks who don’t know each other to speak up before they’ve had a chance to interact with those around them. Nothing more awkward than the silence when no one raises their voice!

Finally some people will be visibly bored/disinterested (or even say something negative when they think you can’t hear). This isn’t a reflection of you, your delivery or the topic. The reality is that sometimes people get bored or dislike things they are doing. It happens. Just ignore that and avoid fixating on them.

If you’re not sure why everyone in the room isn’t amazingly enthusiastic and quick learners in your chosen area and style, put it down to being first thing / post coffee crash / craving lunch / tired after lunch / tired for end of day.


I am easily distracted when watching someone talk. A late comer arriving, someone on my periphery getting a drink out their bag or someone chatting and I might not get as much from a session. When I close my eyes and listen it can be transformational. However it was pointed out to me that a speaker thought I was dozing off, when I was just losing myself in the words!

The other week we had a visitor sharing some learnings and there were a couple of people who I was hoping would bring enthusiasm, only for them to have a pretty blank look on their face. Afterwards they told me how great it was.

My point with these anecdotes – don’t judge people by their faces.

Closing thoughts

Running an effective workshop isn’t something you can quickly bodge together but you don’t need to be a rock star in your field or devote your life to it. If you’re given the opportunity, go for it. Check out your local MoT group, or other meet ups in the area, and offer a bit of your time.


I’m not an expert

This topic could touch on many areas. I rate myself as an excellent tester, but I’m no expert in the field (I’m not “book smart”). I used to have great domain knowledge, but lately I’ve struggled after moving project and finding myself not understanding a word of what people are talking about (not fun when people look to you for answers).

This post is on security testing. I am not an expert.

I find the field very interesting and also the more I learn, the more I know how important it is. This is why I’ve spoken about security testing at TestBash UK, along with talks, a blog post and created a card game all on threat modelling (something I enjoy, even if I’m not that great at it!).

But I’m not an expert.

I recently attended a work cyber security conference. There we had people who have years, even decades, of experience in various aspects of security. They live and breathe it. Pen testers are doing incredibly clever and technical things to get into systems that I just wouldn’t have a clue on. I am years away from their level and even with the best will in the world, I may never reach that.

But that is fine. I don’t have to be an expert.

What I have wanted to stress to people through my posts, activities and talks is that even if we’re not experts, we can find security issues. Whether this is through threat modelling, asking the right questions in planning or adding some injection test data into our usual set of inputs, if we can find these problems earlier, we can fix them earlier and ultimately build better and more secure software.

The other side of me wanting to reject the expert label is that it makes it seem like the level I’ve reached is somehow further to achieve for the average tester. That isn’t the case. I’ve just been fortunate enough to get a small amount of training, maybe a few hours a month, for a couple of years (and much of that wasn’t relevant to testing).

So I want to end by saying, please don’t view me as an expert. I’ve just dabbled a little more than most folk. Join me on this journey into becoming security newbie – it is great fun!

Experience Reports

Collaborative reflections

Earlier this year I wrote about my changing role and push to help improve working practices and support my teams in testing.

In terms of my role, it is certainly coming together. Over the past few weeks I’ve been getting involved more and more with teams and helping teams reflect on quality. My big win is that my email signature is updated to state “Senior Test Engineer” (although my mug says “QA Lead”, which confused me a little).

What I wanted to delve into in this post was that reflection.

One initiative that I’ve started driving is regular bug RCA sessions.

I’ve found these to be interesting sessions and generally I’ve been pleased at how people have been open and honest. This is an essential requirement for teams to learn, develop and improve. Whilst my nature says “oh its all the teams doing this”, I think I deserve a wee bit of credit for setting the tone.

Before we got started and at the start of the session I like to stress that it isn’t about blame. It is a collaborative effort to ship a bug. Similarly mistakes will happen, which is why we have processes and practices in place to help us catch and rectify things. If one person is truly to blame, we have bigger problems.

I’ve also been attending, and on occasion facilitating retrospectives.

In both my retros and RCAs one thing I’ve done is play on (and exaggerate) my inexperience in the team’s working practices and software. Being a “question asker” is a valuable quality of a tester and I’ve been experimenting with this. I quite like “tell it to me like I’m an idiot” or “assume I know nothing” (perhaps a Jon Snow costume could enhance this?). The goal here is to get people talking and explaining. It also means that I can ask “so do you all do X testing?” then “Ah okay, you mind me asking why not?” and finally “how can I help?”.

Basically if I have a suspicion, I’ll ask a bunch of questions “to help me get up to speed” and hopefully surface that without being direct (and potentially causing conflict). I’ll also repeat what people have said back to the group to reinforce and also help confirm that understanding. It’s especially useful to move a discussion forward.

I’ve been learning about coaching Vs teaching, especially through talks from the likes of Vernon Richards and Stu Day. I feel like this has helped me act not just as a facilitator but a bit of a coach in this role, but I realise that I still have a tendency to lead with some of my questions to get people talking on what I want, not necessarily where they might have headed naturally.

Finally the other thing I’ve been doing is remotely joining and listening in to meetings whilst I work. Teams can ask my opinion if they want, otherwise I’ll be learning how they work, picking up on things then trying to feed that back when relevant, whether that is between teams or within the team itself.


I Find Bugs

I’ve been working on my TestBash UK 2023 talk and one of the slides touches upon how I identify as a tester and the tag line on this site.

I find bugs.

This may be an interesting topic to explore because not only have I barely entered any bugs so far this year (largely because I’ve barely done any actual testing) but also I’ve seen a number of people trying to talk around how testing is more than finding bugs.

And it is.

In the previous few years I’ve been entering plenty bugs but also helping prevent many more by contributing to planning and refinement. As part of shift left we are helping to identify and resolve bugs before a line of code is written. Sure, there may be no stats or metrics for this but the work is important and I’m proud of my efforts there. Nowadays I focus the majority of my time here.

However we still need to test an implemented user story or feature. Exploratory testing and alike helps us identify the issues that we didn’t, or couldn’t, think of during planning. Those unknown unknowns. We also need to account for the minor niggles, extreme edge cases and also just good old fashioned mistakes.

I still love the puzzle solving and challenge of trying to find a bug or getting reproduction. That hunger for finding bugs is still strong within me and I’m simply spreading my net. I’m learning how to catch new types of bugs through my security testing and by asking questions & challenging requirements.

Finding bugs is part of who I am. Its in my soul and now it is in my skin!

Photo of my Flick and Ministry of Testing tattoos
Experience Reports Ramblings

Shifting the QA stuff left

Revenge of the Gatekeeper

For the past couple of months I’ve spent half my time, which is in itself reduced following complications, as a “QA Champion”. A title I dislike. In particular I dislike how QA tends to be associated with the testing best described as “checking” and “QA monkeys” running “test scripts”.

The organisation that I joined as “QA Champion” (I’ve died a little more inside when writing that) has had quality issues, especially since a re-org tried to move us into a LeSS structure with dev teams taking on quality and testing. This was first done by getting rid of testers (well not quite) and trying to shift the QA left to do QA earlier. Everyone needs to be doing some QA, not just the QA teams that still sort of exist. We plan to solve this by automating all the QA.

Ignoring the “automation solves everything” part and the fact that we are working on an old tech stack that lacks testability, I have real issues with our approach.

Let’s have a quick prequel first.

My understanding is that our old methods were that testing was thrown over the fence to teams who ran lots and lots of test cases then produced reports and would be the authority on whether we can release. In other words QA as the gatekeepers of quality. To me this is the dark side and rightfully needs defeating.

So why the ranting, rambling blog post? Surely I should be happy that we’re abandoning this? Well no. I’ve found that the QA Champion is sod all to do with championing quality and we’re the new gatekeepers of quality.

What have I become?

A New Hope

As bleak as it may seem, a shift in the balance may be happening. I’m hoping that I’ve awakened something within the QA Champion group so that we can become a force for good.

I’ve started something of a rebellion. Through a tech talk I shared what I think continuous testing, shift left and quality engineering, all that goodness, could look like for us. With passionate discussion (or constant whining), I’ve got discussions going where I think that there is a strong alliance to bring around change.

My goal is built on two pillars right now.

First is with the teams that I immediately work with, we are looking to use practices to help us test continuously and build quality into our day-to-day. This hasn’t been a hard sell because:

  • There’s a strong desire to improve quality where possible.
  • I’ve said that I’ll have their backs in rejecting the initiatives coming from above (i.e. the ways of the dark side).
  • Many of us have worked together. Some of them taught me what I’m now passing back.

Secondly I am continuing to raise the discussion on what I believe to be the right practice and challenging things like “let’s get teams producing reports detailing all their testing for an epic”. I hope to change the language and expectations from management so that they aren’t looking for the same sort of gatekeeping as before. If they want us to be potentially shippable, instead of going through the arduous and prolonged hardening and release processes seemingly non-stop, lets focus our energies on employing quality engineering.

A Force Awakened

So far I’ve had mixed feelings about my progress. There are moments of hope and feeling like there’s positivity and receptiveness to this, followed by a request for dev teams to run hundreds of manual test cases each in a hardening phase for an internal release.

However I’ve now shared our new approach in the latest sprint review. We’ve had lively and positive discussions about how we can actually get to this stage. Things may actually start coming together.

I will wrap up this post by saying that if the next month or so goes well, I hope to get my job title changed from Senior Test Engineer and get the QA Champion program re-branded.

Hopefully this tale will end with the rise of the Senior Quality Engineer.


Experience Reports Ramblings

Why dev testing fails

During my time as a developer I generally produced a good quality of work. My knowledge of design patterns may not have been very good but I tested my stuff to ensure that it did what I expected it to and that is why there was generally a low bug count for my work… But there was a bug count.

Given that I am very confident in my testing skills (more than my dev skills!), how was it that I missed things in my dev testing? In this blog post I hope to explore that topic.

I believe there are four reasons why we may miss things in our dev testing and push code changes with bugs:

  • Blind Spots: Being human we will have cognitive biases or a tendency to miss certain edge cases. There are things that at first I would miss frequently and therefore got more attention in time. Mine was writing incomplete log messages where.
  • Laziness: Most developers want to be writing code so we can be tempted to get our code pushed as quickly as possible in order to move on to the next thing. Certain aspects of testing may be areas where we get slack or cut corners. I mostly got slack around install/upgrade. Yawn. (See also I get bored)
  • Iterative: My approach to development is very iterative. Sometimes I’ll use TDD and sometimes unit tests come a little later but I’ll always manually test my code as I’m working on it. In theory this is great but I’m not going to re-test everything on each iteration. Occasionally this meant that I missed finding out that I broke something.
  • Scope: I don’t believe dev testing should include things like system, load, soak or other more involving tests. If there’s a high time investment to test various scenarios, rather than having two people repeat the same testing, we will often cover the highest risk tests in dev testing and leave the rest for the test phase. There is some testing that is best done by the person testing a completed user story / feature. Consequently it is quite reasonable that developers can exclude certain testing from their dev testing.

(oh hey, BsLIS, or BLISS – lets say I meant that)

So there are some understandable reasons for us to end up blissfully pushing bugs. How do we solve it?

To some extent, I don’t think we need to do anything special.

This is the reason why we (should) have dedicated test phases of a user story’s life. Ideally by working within teams where testing is completed by the development team (possibly by a dedicated tester) then you can build up the relationships, understand each other and catch these things immediately.

As a tester I like to try and get to know my colleagues and how they work. I like to understand what mistakes they may make, as well as thinking about what mistakes I may make. If we can understand and appreciate how these bugs can slip through dev testing, we can catch them easier.

Obviously if you know your flaws then it is good to work on them. If testing exposes your blind spots, try to force yourself to be more aware of them. Using techniques like TDD allows us to ensure, at least at a unit test level, that our iterative changes aren’t breaking our previous work. Also lean on your colleagues and your testers. If bugs are raised against your software, ask yourself why you missed it. Mistakes happen. It’s fine – especially if we’ve caught it before shipping.

My one final note is that it is OK to knowingly not manually dev test an area of code, so long as we clearly communicate not only what we’ve tested and but also what we’ve knowingly not tested. Writing automated tests also lets you flex your scope on manual dev testing.

Dev testing doesn’t need to be perfect. Instead communicate, be clear and work together. The team can be way more than the sum of its parts.

Guide Ramblings

Developing software in a cyber secure way

The importance of developing secure software is (hopefully) understood but what about our working practices?

Many, if not most of us will be familiar with navigating IT restrictions. Firewalls, limits on what you can install or automatically deleting anything that isn’t digitally signed from an approved source. All these impediments to us working.

Perhaps, like myself, you’ve disabled some security measures in the past as a quick measure to get a short test running. Or you run things as admin rather than setting up nuances permissions. Perhaps you’ve used your personal device to read a file.

Let me introduce CD Projekt Red. On the back of a rather stormy launch to Cyberpunk 2077 they were hacked. From what I gather, all their source code was stolen, personal employee data stolen and machines were encrypted with ransomware.

But this can’t happen to you right? Well maybe it could.

A couple of years ago I was working from home using a mixture of my own computers and CCTV cameras and also work kit on loan. One of my personal devices was compromised and at the time I panicked a little, re-imaged it and moved on…  until I realised that the shared drives had been encrypted as well. By being slack on securing my personal devices, I’d potentially exposed a work machine (thankfully the shared files were installers for stuff like Wireshark). Potentially a more motivated attacker could have jumped machines, leveraged my VPN and got into my work network. In other words it could have been much worse.

One of the popular terms that I’ve learnt since becoming a Cyber Champion is “Zero Trust” and building a “Zero Trust Architecture”. This is about building solutions on the assumption that your outer layers of security should be compromised so you should secure all communications within your system. I could ramble on more about this but I want to stress that this applies not just to what we build, but to how we work.

If an attacker managed to get into one of my work machines they could steal our source code. This would have IP impacts but also would allow an attacker to understand our solutions and find any vulnerabilities. Simply encrypting all of our machines to stop them from working could be huge. Imagine if you have all engineers locked from doing work, or pushing changes to the repo. How much money does it cost to have developers sit in the kitchen having a coffee for a week whilst you try and restore things?

These types of attacks are very common in some sectors such as Government organisations, from “city hall” to police to health, but as software developers we’re viable targets as well.

So hopefully I’ve scared you a little. It is quite possible that you could expose your company and cause them massive damage.

However there are good things that we can be doing to protect ourselves.

My work uses security solutions that, as engineers, we usually deride for blocking us from working and sometimes look to work around. But they are important. If you can understand why they are there (see above), it is important to find how you can work alongside them, as opposed to against them.

Firewalls are an important start. All too often when we’re having communication issues with devices or services on our VMs we’ll ask “have you tried turning the firewall off?”. If you do this, only do it for a minute to prove whether firewall rules are an issue or not, then enable it again. It is important that machines on your network are only able to use the protocols and ports that you need them to use.

As tempting as it can be to download a tool to help with a job, for example I downloaded a tool to help me access the memory of an application to help with work, we need to consider the security implications. Could it be doing something malicious? Could an attacker use it to perform a malicious act? This could be a vulnerability in the application, or simply it would be a wonderful little tool for an attacker to use. Look at using software that has been approved by your organisation and uninstalling anything non-essential once it has served its purpose.

The other big area that so many of us fall down is on passwords. It is well known that a lot of people use things like Admin/Admin1234 or TestUser/Test1234 for their passwords in test environments. Similarly when there is a default login like admin/password, many people out there don’t change them.

I still remember being on a remote support session and without thinking I just entered the default credentials for an application and successfully logged in. Afterwards I was politely informed to always ask the customer to enter the credentials and it was also fed back to the customer to change their password.

p.s. don’t have default credentials in your application or at least force them to be changed after the first login.

It is important that we make sure that every account we create, especially admins, have a good & strong password that is unique. Don’t go replacing Admin1234 with My!W0rkN@m3 for everything on the network. Yes it is more secure but if someone got/guessed that password, they may have untold access to your work’s network.

So how do I remember them all? I do use wikis for some shared resources but it is better when we use a shared password manager that in itself has access permissions. I also have my own system for creating passwords, which for obvious reasons I won’t share, but that means I don’t need to remember what my passwords are, only what logic I used to come up with it.

The best solution however is to use domain accounts. This allows us to restrict access to machines and also use good, secure passwords. Obviously being part of a big corporation we don’t have permission to be adding short lived VMs to the company domain and making ourselves admins when we want, so what we’ve done is set up our own domain server that has no trust relationship with the main network.

There is another thing that we need to consider and that is access permissions. I doubt I’m alone in running most of my services as the Local Service admin account, using “Run as Administrator” or “sudo” commands when I want stuff to be working. A common example is when your service needs to write to Program Files. As a standard user it will fail but run as admin and it will work, right? This can be dangerous as there’s things like “Remote OS Command Injection” where an attacker could leverage a vulnerability to execute a command as an admin such as formatting a disk, or disabling security.

To prevent this it is best to have dedicated accounts for things that need to run with elevated privileges. For example, let’s say that you’ve downloaded a NTP service to keep your machines in sync. Rather than running as admin, the installer may help set up an account that is dedicated just to just what it needs to manage NTP – or you could set up your own account with a bit of Googling.

This is an area where mobile does seem better than desktops. For example if I downloaded an app that wanted to access my calls, I get a specific prompt asking for this permission. On Windows or Linux I’ll probably get an error when it tries and fails. After re-running as admin, it now works and exposes the application to way more than calls.

And finally – if any of this seems like too much effort to maintain then there is an alternate approach (depending on your setup). Create an isolated network for your testing where there’s no internet access and you need to physically connect to it.

It may seem like a pain but honestly, it is important that we consider the security implications of how we work just as much as the security of our products. After all, you don’t want to be the one that brings your company to a grinding halt.

Disclaimer: I have no idea on what caused the CD Projekt Red hack. It may have been something that I’ve discussed, it may not. I did not intend to speculate or criticise. I picked them as the example because I loved Cyberpunk 2077 (completed it 6 or 7 times). Please don’t sue me guys!



I am writing this from a dark place. That isn’t my solution to rising energy prices, but instead from the loss of my wife. I mention this as I think it is relevant to the changes that my career has taken and what I want to talk about today.

Change can be hard. It is even harder when it isn’t something that you’d planned for or really wanted.

The first company that I joined was using practices most accurately described as waterfall. After many years of development hell, the product was finally released and a shift to more agile working was on the cards, but it was too late and we went bust. It was interesting seeing the impact of how we worked and the challenges in the introduction of “agile” within our teams.

When I started at this company I was fresh out of Uni and whilst a shy, timid, geek, I did live rather carefree and lacked purpose beyond my work. My days would involve working, watching trash TV and playing games or going out drinking and this was the case until right at the end when I met a wonderful person, Hannah.

After this I started a new role in a new sector, testing surveillance systems. The company had been stuck in a bit of development hell but were finally nearing release. As that completed, the company moved to use (some form of) agile working. I think lean, or scrum of scrums (I get confused over terms at times). This was an interesting period and people responded well. Over the next year or two the company really seemed to improve its ways of working. I was seeing some of the advantages of agile working and whilst I was still technically in a separate test team, I got to work closely with the developers and really liked that.

That said, I wasn’t enjoying work. Testing practices were far too dependant on writing lots of documents, executing what is written in the documents then writing more documents on what was done. My frustrating for this and over time my interest in C# (from hobby game dev) led to me moving to development.

During this period of my life I found that it seemed to all come together. I was happy with my partner, evolving into a better person, enjoying my hobby game dev and happy at work. Whilst there were ups and downs, it always felt like I was moving forward in life. I ended up getting married and life was pretty darn good. During this time my work had also evolved with using a Kanban workflow and teams with embedded testers. That worked really well and I did really life being in the team, even on those days when the project sucked.

Strangely I started feeling down. Missing a “purpose”. I’d been encouraged to push more to learn and develop my skills as a software dev, but I didn’t care about it. At retrospectives I cared more about testing practices. In fact half the time it was testing that was the better part of my job, as opposed to code reviews or writing documentation.

I made some bold decisions by moving back to test and also sought mental health support. 2019 was the year when I took control. This was followed by the year of chaos with the pandemic, a takeover at work, change of teams and with that a move to scrum (with myself taking on the scrum master role as well as QA). It was hard and whilst I hated how changes just happened with no clear plan, once I managed to adapt it was a great time. I began to feel more at home with my teams, my wife and also my career. The Ministry of Testing became a big part of my life over the next few years – in particular the fact that I could downloads LOADS of great talks and watch them whenever. It felt like everything was closer, together and much better… even when the world had us all apart. Life was at its best.

Then the past 3 months happened. Hannah died during the xmas period. We don’t know why. My life was turned upside down and on top of that this month I’ve moved to a new (to me) project in a sort of different organisation. The project that I’m joining has been in development hell for years. There’s major issues (in my view) with the testing practices. I now find myself sitting at home, by myself, watching trash TV and playing games knowing that the next day I’m working in a scenario that I thought I’d avoided twice already.

Change is hard and it can be daunting. However, like it or not, we must go on. (I think)

Whilst I can never fix the loss of Hannah, I’m trying to refocus on my work and testing. I am looking to use whatever little energy I have to try and guide this new organisation. Rather than trying to adapt to the changes, can I make a difference and be a positive force for change? 

Providing I don’t get myself in trouble for writing about this, over the next year I hope to share how this goes. If I am able to say that I’ve managed to make something of the changes going on, well that’s something.

P.s. apologies if this is a bit too Dear Diary. It is good to say these things.