Why continuous testing should be a cornerstone of your projects?

It is always a tricky discussion when it comes to who should be doing what and when. Especially in times of Agile and DevOps cross functional teams and more dynamic and hollistic approach to project delivery. I get it, people tend to get defensive when they’re pushed out of their comfort zone because they are afraid that they’ll fail in their new assignments, because they might loose their jobs, because they don’t feel they should change anything because they are used to doing things the way they always did. And it is completely normal and human to be afraid of the changes. The question that really matter is:

how will you respond to these new opportunities / challenges? Whether you accept them or will you fight them.

Gaining new skills and making progress in your personal development is not always easy, painless and happens overnight. However — if you understand the reason for a change and you embrace the opportunity you can grow more than you might’ve thought. (Wow, that really sounded like a personal coach speak LOL).

Responding to a change

Anyways, this post is not about personal coaching — it is about responding to a dynamic and continuously changing requirements from the Business and IT.

Your business department / your clients want to get new, shiny, top-notch features fast. And the most important — they want to get features that works! How can you make sure that your application / service is working as they’ve requested?

Yes, you got it right! You have to test it first.

Continuous Integration to the rescue?

Continuous integration has been described first in 1991 by Grady Booch. The approach itself is almost 30 years old, yet we still see questions how to properly do CI approach for different types of applications / services.

In my previous post I mentioned the evolution process of CI — making it more reusable, scalable, observable, parallelized etc. We want to get results faster and in more convenient way.

In typical CI approach — you’ve probably included:

• unit tests that developers write to test whether their code does what is should
• some functional / smoke tests
• some integration tests ? (probably on mockups)

Issue cost

You know the issue cost rule of thumb?

Finding an issue on each stage costs 10 times more than finding it on the previous one. These numbers may differ but the rule exists. It’s based on the:

• business impact
• time to understand the issue
• time to fix the issue
• time to deploy
• number of people assigned to verify it and fix it
• etc

Types of testing needed

In order to improve cost effectiveness of your SDLC and eliminate issues as soon as you can — you should consider the “everything as code” aproach.

This is why it’s really important to include your testing experts at the very first stage of your project — business analysis and requirements gathering. I’m not trying to force you to treat use cases and requirements as a code — but it would be really cool to have your requirements testable at each build isn’t it?

There are many tools on the market that might help you achieve that — cucumber is one of them — and it gives you plenty of integrations available to be used right away.

The shift left approach focuses on introducing as many things as possible as soon as possible in the SDLC. That means that you should prepare and automate:

• requirements testing
• unit testing
• database testing (data consistency / validation)
• functional testing (not only smoke tests or basic paths)
• end-to-end testing
• serious integration testing
• load / stress testing
• recovery and rollback testing
• and last but not least — security and penetration testing as well (but shift left on security is a material for another story)

Investment cost

But what about costs of these investments?

But my developers are so great that they won’t do silly mistakes.

When I’ll get ROI from this?

I am more than sure that you can add at least 5 another buts to these three — and you are right. These buts should be considered when designing your project. They should be also complementary with your project idea — meaning that they shouldn’t be overkill investment for you. If you’re developing a public API service that will store and process any sensitive data about your clients — you must be sure that their data is safe, your infrastructure can handle the estimated load and there are appropriate recovery protocols in place, etc.

Be the change

We live in fantastic times! Currently, in most cases — it’s not the technology that limits us. And if we know how to design and verify our ideas properly we might be able to create solutions that are bulletproof and fit for a purpose.

I hope that you understand that if you want to change something — you have to be the change — help others understand that in order to produce value continuously to your customers you have to check it each time the code is built.

CI/CD platforms are great place to integrate all of these testing activities in one assembly line that connected with smart infrastructure management (or container management) can give you hollistic solution for your product/service. It can also help your developers to produce faster, more reliable features that serves your clients.

Originally published at http://blog.mylocaldevstack.pl on May 7, 2019.