Category: Ramblings

Categories
Ramblings

2024: Glad That’s Over

It has been a trying year, both personally and professionally. However before I flesh that out, I thought I’d try and articulate everything that has happened for me within the world of testing & quality:

  • I got a new benefit at work: 10% time! This led to me taking time to learn more during working hours.
  • My teams started work on a web browser based product, having been pretty much only working on a thick client talking to devices for years and years.
  • Got to do my first 5Ws & 1H.
  • I created and abandoned a heuristics based app called Test Addict. We used it a couple of times at work.
  • I started a new role as a Quality Coach (which in truth is similar to what I was doing previously, but I cunningly added extra pressure and expectations on myself).
  • We did our first Risk Storming.
  • I attended TestBash UK – this was great!
  • Started creating something cool (but not available yet).
  • Was a guest on my first podcast (but not available yet).
  • Experimented with different ways of doing test strategies, retros & RCAs to get teams engaged.

Big Fat Failure

In my annual review I was quite scathing of myself.

I failed the teams

We started a new project that whilst not greenfield, was full of opportunity. However we’ve struggled with quality with the teams quite damning in their own assessment. Our automated tests are flakey, we don’t have confidence in how we test and the bug count is beyond anything I’ve worked on before (and that is without me doing the testing!). This is without even touching on technical challenges.

Whilst quality is a shared responsibility and there’s plenty mitigating factors (excuses or reasons?), as the Quality Coach you can hardly walk away feeling like you’ve done a good job when it feels like everything is on fire.

Defeated

Throughout the year I’ve tried bringing new ideas and approaches to the teams but I’m not sure how much has really stuck. The second I stopped being the one to run RCAs or write a test strategy, they largely stop. I did get the teams testing for one quality attribute (I won’t name) for the first time, but we were told to side line it. After resisting taking on the state of our lab & kit, I succumbed, did a load of work and 2 months later its a mess again. Our flakey tests are addressed by “oh just run it again”. We did exercises like using heuristics, risk storming and 5Ws & 1H and the feedback was “that was really useful”… but they won’t get repeated. Finally I had a goal around teaching teams exploratory testing and to date I don’t think anyone has written an Explore, With, To Discover charter.

This isn’t me griping. It is a failing on me. I’m meant to be helping the teams have good habits but they aren’t there.

As for why I called this section defeated, well in Q1 & the start of Q2 I was introducing new ideas for planning testing, thinking about testing and testing techniques. Then over the week or so following my late wife’s birthday I got a wave of requests to “back off” and not take up so much of the team’s time on testing/quality stuff. And I did. I gave up.

Broken

As I’d worried a little in last year’s reflection, I’ve been feeling burnt out and haven’t been able to “over achieve” my capacity as I perhaps did in 2023. With the exception of the odd podcast when gardening, I’ve stopped exploring testing & quality in my spare time. I think the fact that I’ve only written two posts during 2024, one about grief and one written one evening during a conference, is quite telling.

Hope

I’ve been pretty bad at acknowledging my successes this year but there have been a few:

  • Teams might not do exploratory testing as Elizabeth Hendrickson describes in “Explore It!” but they are going beyond the ACs and checklists.
  • Teams are engaged when I organise activities like collaborative test strategies, round tables & RCAs (in the past that has felt like a struggle).
    • In fact in Q1 2025 I’m switching teams that I support and the teams expressed disappointment (and concern!) that I wouldn’t be there to lead on quality discussions.
  • Testing is always a topic that we consider throughout the SDLC.
  • I pushed for us to adopt analytics and we did!
  • I’ve gotten better at being a coach as opposed to a teacher.
  • Whilst deprioritized (for now), I did get us looking at new types of testing in our day-to-day.

Generally speaking, I’ve felt like over the past few months I’ve been collaborating with the teams in a positive way. We’re working to solve challenges and started making in roads on the many challenges we’ve faced. When I was previously feeling “unwanted”, I’m now feeling like a valuable resource. Our group of Quality Coaches, spread across the world, are collaborating more too.

I may have felt like everything had fallen to pieces but I’ve been enjoying the collaboration on how we build back.

Perhaps most importantly, I will definitely get myself the counselling I need. I will recover from the neurological effects of spousal grief and hopefully my energy levels too. With that, perhaps we’ll see a Rich resembling something like what existed 740 days ago…

Categories
Experience Reports Ramblings

Sketchnoting Adventures

Several A4 pages are scattered on a table. They all contain notes taken from a talk in a sketchnoting format

I’ve been meaning to write this for a while but after a really interesting conversation at TestBash, I decided to finally get something written down!

In June 2023 I attended Testing Atelier X and it included a workshop by Marianne Duijst on sketchnoting. I’ve seen some very attractive looking sketchnotes from many people, including the wonderful Louise Gibbs, however I didn’t get how people could take their notes, make them pretty and informative. I also didn’t entirely get the point. However I quite enjoyed the exercise and have since gone on to use this approach a lot when watching talks in my spare or personal development time.

The value that they bring is that you can provide a structure to your notes that makes them way more readable when you look back at them later. I rarely found my notes from talks to be worth looking back on in the past but since I’ve started sketchnoting, I’ve found myself picking them back up to remind me of the topics and key points. Importantly they are something that I could share whilst my previous scribbles in a notepad would be hidden (I used to intentionally write in such an illegible manner that only I could decipher the text).

I am no where near sharp enough to do them live but I’ve learnt some techniques:

  • For live talks, consider post it notes or just quickly writing things in a jotter. Then revisit them later.
    • Post it notes are great as you can reorganise them!
  • If you’re able to pause, try and avoid stopping too often. Listen, absorb then rewind to take the notes.
  • Avoid too much bloat to make it easy to parse.
  • Focus on the speaker’s words rather than “oh I could go do this”.
  • Don’t fret about being messy.
Several A4 pages are scattered on a table. They all contain notes taken from a talk in a sketchnoting format.

See more examples of people’s sketchnotes on the Ministry of Testing Club

Categories
Ramblings

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.

Categories
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.

Speaking

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.

Awards

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.

Categories
Ramblings

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!

Categories
Ramblings

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
Categories
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.

(sorry)

Categories
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.

Categories
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!

Categories
Ramblings

Change

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.