What is the real cost of not having tests (at all)

Hello friends,

🥳 Quick announcement before we start. You might have noticed I skipped last week’s newsletter. I was 100% focused on my new book:

React Testing Library Crash Course: Learn to Test React Components (Step-by-step guide with practical examples, Vitest, RTL queries, advanced techniques included) is now available worldwide for Kindle. I’m just excited to share this with you. 😊 If you can’t afford the book but want a free copy, reply to this email. If you’d like to support my work, buy the book here. 😄

Thank you for all your support and patience! 🙌

Now, let’s get back to this week’s story.

---

My friend Josh is a senior software engineer at a mid-size tech company.

Just a couple of years ago, Josh spent 40 hours a week without writing a single line of code, addressing customer needs, or building futures customers would pay for.

Josh was testing.

Testing so a new release could go out.

I can practically see your eyebrows hitting the ceiling—an engineer manually testing software? 😵‍💫 Oh, trust me, it gets worse!

I heard people do release parties.

I’m sure Josh wasn’t partying when he saw the testing document his team got. It had 100+ user flows like these:

Everyone got multiple user flows, each with a wiki page outlining the test steps. In the table, they saw how long it took to test the same flow last time.

Ignore the small detail that the QA team was let go last year because of budget reasons. Since then, not many tests have been produced because engineers have obviously been busy writing code.

Josh was frustrated for two reasons (besides not really doing software engineering).

Broken Instructions

My friend was new to the software and the company, and this didn’t help him.

He ran into a problem after five minutes.

The wiki page referred to a button he couldn’t find on the UI.

As a pragmatic engineer would do, he changed the task’s status to Failed and moved on to the next task. Soon, the team lead messaged him, asking about the status he set for the flow and why.

Lead: Oh, the user flow is outdated. We don’t have that button anymore. Please proceed.

Josh: Should I update the wiki? 🤔🤔🤔🤔🤔🤔

Lead: No, just go on with the testing.

For the rest of the week, Josh, in addition to testing these features manually, had to ping someone every time he ran into an error like this to verify if the feature was broken or the document was outdated.

Outdated Assumptions

In tests, we usually do something and then verify the results of our actions.

You click a button and see if a dialog pops up. Well, not in the user flow wiki pages! 😅

Because it wasn’t just the instructions that were broken but the results as well.

This cost Josh extra time, and now, besides pinging people for the right instructions, he also had to check if the results he got were actually right and were only outdated in the wiki.

What’s the Cost?

An unsatisfied Josh looking for a new job before the next release comes.

A client looking for an alternative because it takes ages to get a new release.

HR working on hiring new people.

Marketing working on finding new clients.

---

If you love a good horror story, imagine releasing software with a 15-person team, half of whom are still figuring out which way is up because they were hired just months ago.

Why people still think these testing flows are a good idea is a mystery to me.

Releases are important for the customer.

Automated tests enable you to release faster, so the time you spend writing those tests is justified.

People still see introducing tests as changing an application’s technology stack or rewriting it in a different language.

But tests can be added incrementally.

I like to refer to the testing pyramid at this point:

To be precise, my somewhat simplified version of it.

Here’s what you can do for each level:

1. Unit Tests (Base)

• Jest

• Vitest

• Mocha with Chai

• JUnit

2. Integration Tests (Middle)

• Postman

• REST Assured

• Pact

3. End-to-End Tests (Top)

• Cypress

• Playwright

• Selenium

You can set up these tools independently and add tests to one layer at a time.

Conclusion

As a rule of thumb, if you have no tests at all, add some End-to-End tests.

If you have those for your most crucial business case, continue with integration tests.

Finally, add unit tests.

📰 Weekly shoutout

1. 🔝 The easy road to become a TOP performer software engineer: Simplifying productivity by

   Fran Soto

2. Don’t Use Sync Communication For Every Case by

   Saurabh Dashora

3. What I wish somebody told me during my first year as a manager by

   Anton Zaides

📣 Share

There’s no easier way to help this newsletter grow than by sharing it with the world. If you liked it, found something helpful, or you know someone who knows someone to whom this could be helpful, share it:

🏆 Subscribe

Actually, there’s one easier thing you can do to grow and help grow: subscribe to this newsletter. I’ll keep putting in the work and distilling what I learn/learned as a software engineer/consultant. Simply sign up here: