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

Anecdote

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.

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

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.