The Beautiful World of Automated Testing

Are you new to testing? Read my Introduction to Testing article first.

It used to be that the only kind of testing on a product was human testing. Software companies hired Quality Assurance (QA) people to be a part of every product team, and it was their job to act like a user of the product and make sure that nothing was broken from release to release. This worked ok when releases happened once or twice a year, but it doesn’t work today.

If you’re releasing your product regularly (a process called continuous deployment that we’ll cover soon), which is how good products work these days, human testing is too slow and, generally, not as reliable.

Enter automated testing.

Every modern language has the ability for developers to write tests as they are writing code, and then execute those tests before they commit their work to make sure they haven’t broken anything. It might seem odd, but yes, developers write code that tests the actual application code. It’s a beautiful thing!

There’s so much to talk about here, but this is about your business, not a bunch of technical blather. Why should you care about automated testing?

Testing Equals Freedom

Automated testing gives your business the freedom to:

  • Try new ideas and not be scared you broke something unintentionally
  • Onboard new team members and have them be immediately productive
  • Use people for what they’re best at, which isn’t doing the repetitive work of testing code changes

Do you want to spend your time worrying every time you release something new? No. Of course you don’t.

Do you want that new developer you just hired to be working on the roadmap and crushing it in week 1? Yes. Of course you do.

Here’s a quote from a must-read article about Intercom (link at bottom):

When a new engineer joins Intercom we set them two initial goals in their first week: They should ship some code to production on their first day and ship a feature in their first week. This lets them feel like a productive member of the team right away.

Without automated testing and deployment, this kind of goal would simply be impossible.

But… but…

Inevitably you’ll run into developers who think writing tests is a waste of time. Either it takes too much extra time, or they’re actually the first developer to never make a mistake, so tests aren’t necessary.

Poppycock!

Writing and maintaining automated tests adds somewhere between 10-20% to your project, depending on who you ask. It’s definitely worth the extra overhead.

As for your developers not making mistakes or not needing tests, well, yeah. It’s as absurd as it sounds.

Lastly, it’s hellish to go back and write tests later after you figure out that your releases fix two things and break five. Go a little slower now so that you go much, much faster later.

Just Remember

  • Automated testing is one of the key building blocks in a fast-moving product development team
  • Save human testing for the parts of your app that only a human can detect, such as layout issues
  • A project that’s covered well by tests will have 90-95% test coverage minimum

Your Assignment

 

  1. Meet with your developers today
  2. Assess the current state of testing on your project
  3. Take action. No tests? Don’t panic, but get started today.  100% test coverage? Pat yourself on the back. Somewhere in between? Rome wasn’t built in a day. Make time in every dev cycle to improve coverage.

By staying on top of testing, your team will be able to move quickly and reliably to meet your customer’s wants and needs.

Additional Resources

Link to Intercom article

Here’s an example of a code coverage report from one of the most popular testing frameworks, Istanbul.

=============================== Coverage summary ===============================
Statements   : 93.12% ( 379/407 )
Branches     : 81.99% ( 132/161 )
Functions    : 91.07% ( 102/112 )
Lines        : 93.12% ( 379/407 )
================================================================================

What does all of this mean? We’ll get to that down the road. For purposes of this article, we’re focused on the percentages I’ve highlighted for you. This gives you a conversation starter with your team about why, in our example, we’re only covering 82% of the branching logic in the application.