In this article, dear Medium readers, I would like to talk to you about seven test principles based on the ISTQB syllabus. In fact, it is necessary to speak of many more factors to describe the importance of the test. Generally, the seven principles gather the test rules under one roof.
Let’s get started.
1. Testing shows the presence of defects, not their absence: The purpose of software testing is to detect defects. Defects are detected by testing. If there were another way to do it, it would be done. Then can we say that the defects in a tested software are completely detected? It is not only impossible to say but also irrational.
Suppose that the software was subjected to a series of tests and retested after fixing was completed. In general, when this part is reached, a significant part of the defects are detected and corrected, or if it is a negligible error, it can be postponed to fix in the next version. Testing reveals defects, but not 100% accuracy. Even after the tests are done, it is necessary to be suspicious about the product. There may be unexpected defects, errors, and bugs.
2. Exhaustive testing is impossible: For example, let’s take the website of the second-hand buy-sell e-commerce site, called buybuyme.com, with ten thousand users. In what situations do you think a user can access this application? Not everyone can use Windows. Some users can use macOS or Linux. Different browsers, different network connections, different speeds, and qualities. So where do users access the website?
House, car, street maybe in the forest. Let’s assume that a user continues to access the site when he uses it in the house or elevator, but the connection failed and he goes out. In this case, can we guarantee that the requests such as the last message that the site is about to send, the offer button, page refresh, and filters will work properly? The user can use the product in different situations and conditions, so it is impossible to test everything.
3. Early testing saves time and money: Having completed the tests at the beginning of the development process, organized and integrated continuously, helps to detect and clean up the bigger problems that will reveal later and prevent long-run costs. Saving time and money are the two most valuable things for companies. A failure that exists in the lower-layer can affects the upper layer and fixing gets difficult increasingly. Fixing the underlying defects would be difficult, perhaps impossible, and could cause the entire investment to collapse.
Having executed tests before creating the components and having to execute tests that are necessary for each layer insurance the investment, prevents bigger defects, failures, and errors as well as applies efficiency in terms of both employees and company resources.
4. Defects cluster together: Twenty percent of software contains eighty percent of defects. Small modules have too many defects. The focus of tests on these areas makes it easy to find many defects quickly. Knowledge, experience, and different perspectives are helpful in finding such defects. This principle, known as the Pareto rule, works in many areas of life. Eighty percent of customers in a restaurant order twenty percent of the dishes on the menu. The remaining dishes are less preferable. He revealed that eighty percent of the land in Italy in the Pareto period (19th century) belonged to twenty percent of the population.
5. Beware of the pesticide paradox: Imagine owning a dairy and curing a sick cow by constantly giving her antibiotics. What do you think will happen? After a while, you will see that it does not heal and the medicine does not help. This is because the cow’s metabolism has become resistant to antibiotics. Antibiotics don’t work as you have to try different drugs. This principle tells us that performing the same tests will not yield different results.
By constantly performing the same tests, the software resists this and starts to fail. You too, thinking that you have error-free software, wait for the day when you will encounter errors that you did not foresee. Cases and steps should be reviewed, modified, and updated from time to time.
6. Testing is context-dependent: The same test is not applied for every project. Different products have different requirements. The purpose of the test is to obtain data that complies with the requirements of the software. Because a bank application and drone software need to be subjected to different tests.
While critical and customer-oriented tests such as security vulnerabilities, customer money transfers, and loan interest calculations are carried out in the bank; Issues such as the maneuvers of a drone from takeoff, the test of console keys, and its reactions in case of changes in the weather, its reflex against collisions are put to the test. Projects of all kinds need different tests.
7. Absence-of-errors is a fallacy: Defects that fail the software test are sent back to the developer team with detailed explanations. After the corrections are completed, a new test run is executed. If an error is not encountered in this part, this situation causes the team to think that there is no defect in the software and we can present it to the live environment.
Even if it is bug-free, all situations where users can get efficiency from the product should be calculated. Even if a button works correctly, its location or color can create problems for users, and these need to be fixed as well. bug-free software does not mean success. However, there are projects that can work on the developer’s own computer and cannot work in other environments. That’s why DevOps teams work to surpass these issues. Even if it all works correctly, problems can still occur in the live environment.
I hope the content will be useful for you.
Thank you for giving your time.
Source: ISTQB Foundation Level Syllabus