Why testing should be part of your business?

Consider the title of this article not as a question but, rather, as the consequence of successful business decisions. You will find a series of arguments that will make it easy for you to justify introducing testing into your product, as well as advantages that this type of practice exposes for your business.

So let’s start with the basic: What is testing?

I like to define it as an extra layer in the architecture of your product, with the purpose of validating and verifying that the software works correctly per the requirements of your product department. Indeed, that’s a fancy way of saying that the product will be error-free, yet that still is not entirely true.

Testing will depend on how it is written, if it has been developed according to business rules, and if all of those rules have been taken into account.

We generally develop this practice in terms of product, to verify if our results match what was intended. In technical terms, this practice is extremely useful to find errors early in development, which will lead to a more efficient start-up with the lowest possible error rate.

There are two ways to execute tests: automated and manual. But given this is the 21st century, do you really want to manually run validations? This involves people who can and will make mistakes—better leave it to the machines.

There are numerous technical advantages when it comes to testing, among them:

• Streamline the process

  • When we develop more and more features for our application, we will eventually have to change old designs and implementations, which translates into extra costs and risks. Do we really want to introduce an error into old features? Nope! But with a unit test, you can start refactoring without issues since your unit will tell you if it meets the requirements or not.

• Code quality

  • Testing improves the quality of code. If we use it at an early stage of the project, we will be able to develop all our rules (including edge cases) with greater clarity and precision.

• Find problems early

  • Our code will go through processes that can detect errors in the early stages of the project. This translates into less development time and greater confidence in our product as it reaches production. Plus, we avoid developer overtime for debugging.

• Scalable

  • Simplify integrations with other units or applications.

• Documentation

  • This is one of my favorite items! Testing during your product’s development will allow clear documentation about what it does, how it performs, and all the test cases it should cover. There is no better visualization of your product than some good documentation.

• Debug process

  • Simplify the debugging process—if our unit or module fails, the only possible cause is the most recent code change.

• Reduce costs

  • Unit testing finds errors early and helps reduce the cost of error corrections. Imagine the cost of an error found during the later stages of development, like during system tests or acceptance tests—errors detected later are usually the result of many changes, and you don’t really know which one caused the error.

Different Testing Layers

Unit Test: Test each individual piece of code. Think of each function, class, or method.

Integration: You test the integrations of many units together. You make sure your code works when put together, including all dependencies.

E2E: This type of test does its job of performing the complete flows expected by a user, simulating both successful and unsuccessful paths.

Regression: After integrating, we must run the unit tests again. This regression assures us that the new changes have not broken anything.

Acceptance: You must prove that the program meets the expectations of the user or client.

I like to think about testing in a practical way, like how many layers I have to mock to make it work.
In the unit test, I must mock any external dependencies of my unit code. In integrations, I should only mock the API calls to emulate the responses I need. In the case of E2E, you shouldn’t mock anything to check how all flows work.

In another article I will explain in more detail each type of testing.

Let’s do a simple exercise of synthesis optimization as if we are the project manager and we really want to have a product in the least amount of time and with the lowest costs.
Do we really want to spend hundreds of hours finding and fixing bugs for not having an extra layer from the get-go?

If our product starts producing patch after patch, what does that tell customers about our application? Do we really want to have a bad image for not implementing testing at an early stage and not keeping costs low?

Conclusion

Testing is a tool that I humbly consider absolutely necessary. I can’t swear that it is essential, as there is evidence of hundreds of products that are in production without having been put through the paces I’ve recommended above. However, they generally are not the most successful products. Most big companies have adopted testing and have integrated it as a natural part of the process, which adds enormous value to the product (and, indeed, to the company in terms of technical standards).

Are you convinced? Or are you satisfied in paying extra developer hours to patch your app?