Software testing principles

Seven Software Testing principles are,

• Testing shows presence of defects
• Exhaustive testing is impossible
• Early testing
• Defect Clustering
• Testing is context dependent
• Pesticide Paradox
• Absence-of -errors fallacy

Let’s see one by one in detail.

Testing shows presence of defects

• Testing is done to find as many defects as possible
• Testing is not done to prove that the software is bug-free
• Testing helps us to identify potential undiscovered defects in the software
• Even after testing is complete with no bugs found, we can’t say that the product is 100% defect free

Example: 

A software tester is testing an android mobile application. He should be working hard to identify potential defects rather than providing defect free product. This will help him to identify more bugs rather than achieving correctness.

Exhaustive Testing is impossible

• Testing all combinations of input data values and scenarios are impossible
• Testing all combinations would cost more time and money
• Smarter ways of testing should be adopted in order to complete the project timelines
• Prioritize important tests based on risk

Example:

Assume you are testing the email subscription feature of an application. There are 1000 users subscribed. Testing email subscription is working for 1000 users consumes a lot of time and cost. Instead, identify sample or prioritize the important test based on the requirement.

Early Testing

• Software testing starts from requirement gathering
• Testing should be done parallelly along with other product development phases.
• Finding defects early on will save a lot of money and rework time

Example:

Consider product requirement gathering is completed and developer started coding. Once the development is done, tester identifies a defect in the requirement gathering and found that the requirement should be changed. This costs lots of money and time loss for the company and also finally end up in rework. Instead, if it’s found early on that would have saved the company a lot of money and time.

Defect Clustering

• Defects are not necessarily spread even
• They may be clustered in one or few modules
• Place where one bug found, likely to find some more
• It’s more like 80-20 Pareto principle that is 20% of the defects cause 80% of the problem

Example

Assume a new programmer developed a complex module. So, it is very likely to find more defects in that particular module.

Testing is context dependent

• Testing is always context dependent
• Software should be tested based on the purpose of the product that has been built
• Different software are tested differently
• Banking site cannot be tested same as the E-commerce website
• Functionally both are different, so obviously they cannot be tested same

Example:

Banking site will have functionality features like transactions, interests, savings, etc., the E-Commerce site will have some features like shopping cart, order, payments, etc. So both are completely different in their functionality. Test scenarios and tests conducted on the software should also be different and depend on the context.

Pesticide Paradox

• Executing same test cases, again and again, will not help us to identify new defects
• To overcome this, it is really important to review test cases regularly and modify them if required
• Different and new test cases should be added to find more defects in the software

Example:

Executing the functional test cases, again and again, will not help to identify defects regarding the performance of the software or the defects regarding the security threat. Our test cases should be different to potentially identify new defects

Absence-of-errors fallacy

• Finding and fixing defects doesn’t help if the built software fail to meet user’s requirements
• Test designed should catch most defects and also should cover all client’s requirements and specifications before shipping the product

Example:

Software tester completely tested the product and the software is 100% defect free. Is that mean the product is ready to be shipped? No! Software tester should verify the test design covers the customer’s requirements and specifications. If the built software fails to meet requirements, then finding and fixing bugs doesn’t really help.

If you like it, Share it!

Here are some hand-picked articles that you should read next ?

• Agile Model
• Software Testing Methods
• Verification Vs Validation
• Software Development Life Cycle – SDLC

In my next post, will learn about fundamental test process.