Seven Principles of Testing

Setting up and planning a new web development project has many challenges: estimating time accurately, requirements analysis, designing, testing, etc. In my opinion Quality Assurance testing is one of the most critical topics in the Systems Development Life Cycle, because testing can ensure the success or failure of the project. For this reason, it's important to have a clear understanding of the basic principles in the ISTQB Foundation Level.

Testing shows the presence of defects, not the absence.

The tester’s job is assuring the Quality of the product. The goal is to make the software fail and minimize the errors in the final product – but it will never be 100% free of defects. In 2016 Samsung discontinued the Galaxy Note 7, due to battery failures experienced by consumers after the product was released. This situation illustrates that every product, even those created by huge companies, can have issues that were not apparent until the product was released into the wild.

Exhaustive testing is impossible.

In software development projects, there are a multitude of inputs and preconditions. Testing every combination can mean testing an overwhelming number of possibilities. For example, assume we have to test 5 input fields which accepts 5 results. That will result in the tester needing to create 3,125 test cases, which can be quite expensive. For this reason, it's important to do an early analysis and set priorities for which tests to focus on.

Early testing.

Issues should be identified earlier in the Development Cycle. Dynamic and static tests should be done before the project advances to the next stage. An IBM study found that issues discovered later are 30% more expensive to solve than issues found early. It's important that the project don't cost more than the first estimate.

Defect clustering.

There are modules in every project that are more complex than others. And these modules are likely to contain most of the defects. The Pareto principle can be applied here; 80% of the issues are found in 20% of the modules. It's important to focus on the critical issues, but don't forget to test the rest; just determine a ratio of testing for each module. This concept should be used as input for the analysis of risk in the first stage of the project.

Pesticide paradox.

The more a tester runs the same tests in a project, the less effective they become over time just as insects eventually become resistant to pesticide. In software development it's important to refresh or create new test cases to find more subtle bugs not caught by the original tests and bugs introduced by fixing the original bugs.

Testing is context dependent.

All projects are different. They don't all have the same functionality or the same objective. We could be developing a simple, informative web page or an automated surgery system. The risk level will impact how much effort and investment we put into software testing.

Absence of errors fallacy.

It's a mistake to believe that fixing all the errors found during testing means that the software will be successful. It may have other errors that weren't tested for – or it doesn't meet the business objectives or the needs of the end-user. Early testing can help mitigate this problem.