Imagine the following situation: A new project will be developed, but because of some issues, a test team is not a priority. The project is started and after months, delivered to the client. After the delivery, the system starts to be used and some errors are pointed out. In this case, the development team goes back to work on the project, causing a lack of customer trust with the team, rework, and a waste of time and money that could be avoided if these problems had been found since the beginning of development.
This is a situation that happens and not to cause these inconveniences after the development phase, then how about implementing a testing process?
But after all, what is a testing process?
Software testing aims to ensure quality by minimizing uncertainties and systematizing acceptance criteria. It validates whether the software works well, if there are problems and if expectations are being met. However, simply running tests does not mean that the software meets all the quality criteria. Testing also needs a process, which is basically tracking the software from its conception to its maintenance. Consequently, when there is a defined and executed process, we guarantee even more quality.
How do we apply the testing process?
When a project is in its early stages, we usually know which technologies will be used. While we still don’t have the requirements (project specifications) to start thinking about test cases, we can start thinking about a test automation tool. For example, if the project will be developed in React, we have several tool options, including cypress and selenium.
With the requirements defined, we can start to create test cases, define which ones can be automated and together with the developers create a list of acceptance tests for the activity being developed. But what is it? It is the minimum of items that must be developed and must be working for that activity to be tested and considered finalized. I’ll talk about this later.
When this is over, probably something – even a small one – of development may already be ready, so we can go into the development environment and start an exploratory test and even start automating something. Anticipating tests, problems can be encountered before being sent to the release, saving development time and testing time.
When the activity is completely over, it is time to go through the acceptance tests list. Usually, we see more results when we go through acceptance with the developer in their own development environment. If all the items have been made and the minimum required works, we can consider this activity ready to generate the version. If an item was not made or a critical issue was found, the developer should go back to the activity and correct what was found, minimizing the risk of the version being generated with critical issues and ensuring much of the system quality in advance.
Another situation is when we already have a version with part of the system already stabilized and we have automation scripts created for them. These tests can be configured in Jenkins (or the tool used by the project) and with each push made by the developer automated test scripts will be executed, thus preventing modifications made to the new feature or bug fix from causing any damage. side effect in what previously worked, also preventing this problem from being encountered only when we have a generated version.
Defining and running a testing process adds a lot to the system, anticipates problems, saves test and development time and consequently lowers cost and increases system quality, efficiency and reliability.