Today, we will talk about different ways of testing code and business logic. It is a trendy topic, and many programmers speak about it, yet it is also vast and complex. Thus, I would like to start from the very beginning and introduce the philosophy behind code examination. I will focus on testing web applications, but I believe that most of the ideas are universal enough and may apply to various technologies.
We will walk through the different aspects of a system that are eligible for testing and answer the following questions. Who should consider testing? Why should one consider testing?
That will give you a clear overview and hopefully assist you with your own decisions regarding the issue. Software testing is almost a boundless subject, and there are many ideas on how to do it right, or sometimes how to skip it effectively. To test or not to test is a challenging decision to make. There are so many variables involved that you are probably the best person to determine it for your project.
Let’s start by describing various kinds of testing. We can arrange testing ideas in three main categories. I like to think about them as responsibilities as different groups involved in the project should be interested in implementing them.
Product tests
From the business perspective, it may be essential to test crucial elements of a business logic. For instance, when we consider a selling website, critical activities may be searching products or sending inquiries concerning specific assets. Those elements are in the best interest of a product manager, marketing team, and business in general.
The end product should support the best usability and performance for users. That’s why a constant validation of the user interface, its clarity, and intuitiveness is valuable whenever we design a new feature or expand the existing one. Creating proper A/B tests and changing the layout accordingly may be vital here.
Verifying user experience regarding comfort usage and complete customer flow is another aspect. Monitoring maximal loading time and interface response time may play an indispensable role in customers’ satisfaction. Furthermore, it is relevant to ensure a coherent client behavior path, so that nobody feels lost in the system.
Creating those kinds of tests and routines is quite demanding. They require specific examination cases, comprehensive documentation, and people to maintain and perform them on a regular basis. There are times when automatization is complicated and sometimes impossible due to the nature of the tests. Business testing usually involves UX and graphic designers as well as more technical teams, including quality assurance.
Technical tests
Programmers’ responsibilities circle around the implementation of given requirements. In this case, the best tests we can create are the automated ones. They are usually divided into three levels of granularity.
Low-level tests are unit tests that verify specific functions, components, or modules. Those are the simplest ones due to the easy environment setup. Thanks to their separation from the rest of the system, they help programmers design interfaces and state correctly. As a result, the code is not only easier to test but also easier to reason about.
Mid-level tests are integration tests that confirm the good cooperation between separate elements. We may check the integration of functions, components, or modules. The key distinction is that we shouldn’t dive into their internal logic but instead focus on the interaction in between. These tests require more setup and should be used only when low-level tests are not powerful enough.
The most potent yet expensive types of examinations are high-level system tests, sometimes called end-to-end tests. They tend to prove that specific functionality works in the final application. The high-level strategy results in drilling through different system layers, so the holistic analysis validates many things, but it does not quickly pinpoint the problem if it comes to that. This makes it the last resort, usually helpful only when lower-level testing is not capable enough.
Infrastructure tests
The last group of responsibilities falls on teams responsible for the availability and security of our application. It is not directly related to common customer experience, as our product inspections are. It is also distant from explicit verification of functionality and code, as our technical inquiries are. On the contrary, it is closer to ensuring the safety of the infrastructure and monitoring it.
Stress and performance tests allow finding out limits, defining suitable alerts, and preparing precise on-time reactions. When something wrong and unexpected happens, it is great to have detailed knowledge about the infrastructure capabilities and limitations.
Another kind of valuable check is conducting security tests. It is rarely a job for an insider because the main idea is to break the thing we are working on and find vulnerabilities. Be aware of the potential conflict of interests.
Last but definitely not least are all the tools monitoring our infrastructure and application. These are key to quickly ensuring that everything works as desired or which part of the system is not operating correctly. All health checks, error reports, and logging utilities play a vital role in testing the availability of our applications.
These kinds of testing require a unique approach and a lot of experience. They are usually performed by third-party entities or have dedicated teams of professionals inside the association.
Conclusion
What can we learn from this? Well, the abundance of different testing approaches comes as no surprise, but deciding between them is a difficult choice to make. Realizing that other people and different teams are responsible for the final product is key. This distinction is not an arbitrary assignment but rather the result of a general division of work and the desire to improve the part specifically assigned to our team.
Of course, it usually requires cooperation between teams. For instance, most checks of customer workflows may be automatized using IT’s toys like end-to-end frameworks. Still, as for the customer use-cases, it is better if the script is designed by the business end.
It is evident that we need to communicate and decide together, but realizing who has the responsibility and thus initiative may be constructive and lead to better quality. Cheers!