Test Execution: The Importance of Self-Accountability in the Development Journey

It is quite common nowadays to compare software with physical products in terms of quality and functionality. While this comparison may make some sense since they both involve consumption, it is unfounded when it comes to testing. This is because a physical product is tangible, whereas software is intangible. Of course, if the software operates in a security area, for example, it needs to receive more attention during its release to minimize flaws. But what is the difference between any software and a security software? It simply lies in the investment of time and resources in the testing or Q.A. (Quality Assurance) area, also known as quality assurance. Therefore, it is important to understand that there is no digital product created completely from scratch that is free of any flaws. In such cases, there are recalls or returns for repairs. Typically, much attention is given to vital areas of the product's functioning and less attention is given to non-vital areas. There are various levels of product testing, from basic to deep, both by the company that develops it and by the client. Yes, that's right, the client is the one who actually tests the product, so be prepared to test!

The difference is that the developer's testing levels focus more on functionality, such as whether data is going to the right place, if a field is in accordance with the requirements, among others. On the other hand, client testing focuses on aspects like layout, colors, visual elements, accepted character types in each field, data entry methods, usability, and user experience. The most important aspect is that client testing takes place in a real environment, not a simulated one. Therefore, be prepared to extensively test your product during its construction, even in modules that are not yet finalized as each stage is completed. Think of it as constructing a building and checking if it aligns with the project. The basic difference is that without the client's approval when receiving certain functionalities for testing, the work on the software cannot continue. The real testing happens in production, where we can truly measure the product's behavior with multiple connections, different possibilities of use, and diverse people who think and enter data in various ways. That's why it's important to have good support so that you feel confident when launching your product and can respond quickly to any flaws. Honestly, it is possible to greatly reduce the likelihood of software failures, but doing so would require so much time and financial resources that it would likely become economically unviable, with a high opportunity cost.

As an example, we can structure the tests into different levels as follows:

1. Level 1 tests: These are the most superficial tests, consuming 10% of the total time and costs of digital product construction. They focus on basic functionalities such as data input and storage, logins, calculations, and other functions.

2. Level 2 tests: Medium level tests. They consume about 50% of the total time and costs of digital product construction. In addition to the tests conducted in level 1, they also cover data input validations, such as CPF (taxpayer identification number), number of valid connections, and security aspects.

3. Level 3 tests: These are the deepest tests, consuming up to approximately 200% of the total time and costs of digital product construction. In addition to the previous tests, they include high levels of security, attacks, tests in production environments, simulations, among others.

Over time, the product will have enough corrective versions to minimize flaws to the maximum extent. However, it is a constant process, as can be seen with iOS, Android, Windows, and other software that release updates for bug fixes on a regular basis

Main Causes:

1. Not knowing that the product needs to be tested during its construction;\

2. Not being aware that there are different levels of testing for digital products, and that these can be acquired based on the required level of reliability for the product's purpose;

3. Believing that it is possible to test absolutely everything in a digital product before launching it;

4. Comparing the level of testing between a physical product and a digital product.Not conducting tests but relying on a partner to test and compromising the final outcome of the product;

Main Consequences:

1. Thinking that a digital product lacks quality because it has flaws that cannot be tested in test environments;

2. Feeling frustrated due to initial expectations of perfection and flawless operation;

Possible Solutions and Best Practices:

1. Lower your expectations regarding the perfect functioning of every aspect of your digital product and invest in a partner who provides quick and effective responses to recalls and necessary corrections;

2. Clearly define what is truly important during the discovery phase, so that tests can be focused on the critical areas;

3. Express your main concerns during the initial phase of product conception. Some people prefer to launch quickly, regardless of the product's state, while others prefer the product to be almost perfect before launching. Different people have different perspectives;

4. Determine the target audience for your product. If your product deals with money or people's security and requires deep testing levels, ensure that you have sufficient resources to apply thorough tests before launching;

5. Consider acquiring a Service Level Agreement (SLA) with reduced response time and/or have a team available at the time of product launch and for a period afterward to quickly address any significant flaws without jeopardizing your relationship with customers and users;

Plathanus is a reliable partner that works to deliver the best experience to its clients throughout the product development process, regardless of the product type, ensuring satisfactory results.