What are the mistakes in software test development? Can a software testing developer release software that cannot test all available scenarios? How can a situation that you cannot test after being released to the market be prevented from being discovered in the customer environment?
For the software test developer, these questions are the biggest fears in every test cycle, regardless of the quality of the work provided. What creates this fear on us is the mistakes that are thought to be true, that is, the test myths. Leaving aside test myths, the most important issue we should keep in mind before touching an application is the basic testing principles.
Unlike the known test myths, the test principles are realistic and correct. Below, the known mistakes in the test and test principles are mentioned.
- False Facts: A tested software must be bug-free.
Test Principle: No application is 100% error-free. Testing does not show that the software is free of bugs. The purpose of the test is to show that there are errors in the software; it is not to prove that there are no bugs in the software. This item is a very common myth that clients, project managers, and management teams believe.
- False Facts: If the product is not fully developed, the test cannot be started.
Test Principle: Tests depend on source code, but reviewing requirements and developing test cases are independent of the code developed. Testing must be done throughout the SDLC process. In traditional software development models such as Waterfall, testing is done only after certain stages of software development, and the test team is not included in the SDLC. This is not the right approach to produce good quality software. To performan effective test, the test team should be included in the process from the requirement stage to the application stage of the software. The test should be started as early as possible. This is very important to avoid imperfect designs.
- False Facts: It is possible to test the software completely.
Test Principle: It is impossible to test the software 100%. Testing the software with all input and output combinations is not possible due to the time and budget constraints of the project. The important thing is to identify risky areas in the software with risk analysis, prioritize them and test these areas more than usual.
- False Facts: The task of a test engineer is only to find errors.
Test Principle: It is the task of the test engineer to find errors in the software, but a test engineer is also an expert on the software he is working on. While software developers are only responsible for the specific component or domain assigned to them, test engineers know how the software works in general, what dependencies are, and what effects one module has on another. For this reason, the most important task in design and system improvement belongs to the test engineers.
- False Facts: Anyone can test any software application.
Test Principle: People outside the IT industry think and even believe that anyone can test the software and testing the software is not a creative job. However, we test engineers know very well that this is a myth. It is a creative task to consider alternative scenarios and discover possible errors by trying to crash the software.
- False Facts: It is very expensive to test the software.
Test Principle: The test cost during software development is much less than the maintenance or correction cost spent without testing. Early testing saves both time and money. However, lowering the cost without testing can result in the incorrect design of the software application, rendering the product useless.
- False Facts: Testing is time-consuming.
Test Principle: Testing during the SDLC process is never a time-consuming process. Going to the source of the error detected during the tests and fixing the error is a time-consuming but efficient activity.
- False Facts: Errors that cannot be detected as a result of the test are caused by the test team.
Test Principle: It is not the right approach to blame the test team for errors that remain in the application even after the test is performed. Time pressure, limited resources, requirements, and testing strategy can cause errors to be overlooked by the testing team.
- False Facts: Test teams should be responsible for the quality of a product.
Test Principle: The idea that only test engineers or test teams are responsible for product quality is a common mistake. As a software testing engineer, you cannot test everything and you are not alone in being responsible for the quality of the product. As test teams, you are responsible for quality control. Each team member involved in the SDLC process is responsible for the quality of the product. So you cannot guarantee the quality.
- False Facts: Test Automation should be used wherever the time spent on testing is reduced and its use is possible.
Test Principle: Yes, Test Automation indeed shortens the test time. However, it is not possible to start test automation at any time during software development. Test Automation should be launched when the software is manually tested and to some extent stable. Also, if requirements continue to change, test automation will never be available.
- False Facts: Allocate equal time to each segment when testing software.
Test Principle: Give priority to some parts of the software. If there are some critical partitions in the software, give those partitions top priority and make sure they are tested as early as possible. Errors are concentrated in certain areas of the software. If all parts (modules) of the software are considered, it will be seen that the majority of errors will be found in a small part of these parts. This situation is usually explained by Pareto analysis. Pareto analysis is a statistical technique used in decision-making. The vast majority of problems in improving quality (sample 80%) are produced by only a small fraction of the causes (sample 20%).
- Test Legend: Test the product in the developed environment.
Test Principle: Test the product in different environments. The product should be tested in all environments available to the user.
We all encountered this situation, especially in the mobile world. The software development process has been completed and no problems have been encountered in the tests performed on the simulator, unlike the tests performed on the simulator in different versions and model devices, it may produce different results. It can cause problems such as crashes and design errors.
- False Facts: Incorrect Development team should test.
Test Principle: The software development team should avoid testing the software. (Except unit testing.) Testing should always be performed by the testing team. Software development software should never test it. This is because, after spending a certain amount of hours creating the software, the unconscious sense of ownership can prevent you from seeing flaws and flaws in the system. The test engineer must take a destructive approach to the product. Software developers can perform unit testing and integration testing, but software testing must be done by the testing team. It is a really bad idea for any organization for software developers to test their code.