Software Testing Principles: Exhaustive, Early Testing, Defect Clustering, Lecture notes of Software Engineering

Download Software Testing Principles: Exhaustive, Early Testing, Defect Clustering and more Lecture notes Software Engineering in PDF only on Docsity!

Chapter 3

Software Testing

Lecture 3

Principles of Testing

Background

• (^) It is important that you achieve an optimum test results while conducting software testing without deviating from the goal.
• (^) But how you determine that you are following right strategy for testing? For that, you need to stick to some basic testing principles.
• (^) Testing Principles will help you create an effective test strategy and draft error catching test cases.
• (^) Learning testing principles is just like learning to drive for the first time.

General Principles of Testing

General Principles of Testing Principle 1: Testing shows the presence of defects :

• (^) Testing can’t show that the product is defect free.
• (^) But it shows that the product fails because of defects
• (^) Testing always reduces the number of undiscovered defects remaining in the software. Therefore, it is important to design test cases which find as many defects as possible.

Principle 2:

Exhaustive Testing is Impossible:

• (^) Too much combinations of data testing is not possible Assume we have to test an input field which accepts age between 18 to 20 so we do test the field using 18,19,20. In case the same input field accepts the range between 18 to 100 then we have to test using inputs such as 18, 19, 20, 21, …., 99, 100.
• (^) If we keep on testing all possible test conditions then the software execution time and costs will rise.
• (^) Risk and priorities will be used to concentrate on most important aspect of test

Principle 3:

Early Testing:

• (^) Assume two scenarios, first one is you have identified an incorrect requirement in the requirement gathering phase and the second one is you have identified a bug in the fully developed functionality. It is cheaper to change the incorrect requirement compared to fixing the fully developed functionality which is not working as intended.

Testing Principles Principle 4: Defect Clustering :

• (^) Observations shows that most of the reported defects are related

to small number of modules within a system. But testers should

also concentrate on the other modules.

• (^) Defect Clustering is based on the Pareto principle, i.e 80-20 rule,

where it is stated that approximately 80% of the problems are

caused by 20% of the modules in product development.

• (^) If testers look at 100 defects, then it will not be clear if there is any

underlying meaning against those 100 defects. But if those 100

defects are categorized on some specific criteria, then it may

possible for the testers to understand that large numbers of

defects belong a very few specific modules only.

Principle 4:

Defect Clustering :

• (^) In a large application, it is often a small number of modules that

exhibit the majority of the problems. This can be for a variety of

reasons, some of which are:

• (^) System complexity.
• (^) Volatile code.
• (^) The effects of change upon change.
• (^) Development staff inexperience.
• (^) This can give a good indication that when a defect is found in one

area of the application, chances there are more defects in that

particular area, so it is worth investing more time to test that

particular area of the application to find as many defects as possible.

However, testers should not ignore to test the rest of application as

well as there may be other defects scattered around.

Testing Principles Principle 5: Pesticide Paradox:

• (^) During coding to one particular module where more defect

found, the developer may neglect the other modules to code

it properly or the changes made in that particular module

might have a negative impact on the other functionalities

• (^) If we keep running the same set of tests over and over again,

chances are no more new defects will be discovered by those

test cases.

• (^) “ Pesticide Paradox ” means that it is very important to review

the test cases regularly. New and different tests need to be

written to cover different parts of the software or system to

find more defects.

Pesticide Paradox Example:

• (^) lets consider if you are using a toothpaste for couple of months then your teeth will immune to it and you won't find good results after a certain period of time. In this case your doctor would recommend you to change your toothpaste regularly.
• (^) Similarly software gets immune if you repeatedly running same set of test cases again and again and hence probability of finding new bugs will be reduced. So to overcome this, testing strategy called Pesticide Paradox is used where team needs to add new test cases and update existing test cases.

Principle 6: Testing is Context Depending:

• (^) The same tests should not be applied across the board because different software products have varying requirements, functions and purposes.
• (^) For example, a software application in a medical device software needs more testing than a games software. Also, a medical device software requires to be compliant with medical industry regulators and possibly specific test design techniques_._
• (^) Another example, online banking application requires a different approach of testing compared to an e- commerce site.

Testing Principles Principle 7: Absence of Errors Fallacy:

• (^) If the system built is unusable and does not fulfill the user’s needs and expectations then finding and fixing defects will not help.
• (^) Absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is unusable and does not fulfill the user's needs & requirements or if the software is tested against the wrong requirements.
• (^) Early involvement of the users in the development process and the use of prototypes are preventive measures intended to avoid this problem.

ISTQB® Code of Tester’s Ethics (Ethics: What one’s should or shouldn’t do according to ISTQB I nternational S oftware T esting Q ualification B oard )

• (^) PUBLIC - Certified software testers shall act consistently with the public interest.
• (^) CLIENT AND EMPLOYER - Certified software testers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest.(Exhibit loyalty in all matters pertaining to the affairs of their organization)
• (^) PRODUCT - Certified software testers shall ensure that the deliverables they provide (on the products and systems they test) meet the highest professional standards possible.
• (^) JUDGMENT - Certified software testers shall maintain integrity and independence in their professional judgment.(Exercise honesty, objectivity, and diligence in the performance of their duties and responsibilities)

ISTQB® Code of Tester’s Ethics

• (^) MANAGEMENT - Certified software test managers and leaders shall subscribe to and promote an ethical approach to the management of software testing.
• (^) PROFESSION - Certified software testers shall advance the integrity and reputation of the profession consistent with the public interest (Not engage in acts or activities which are discreditable to the profession)
• (^) COLLEAGUES - Certified software testers shall be fair to and supportive of their colleagues, and promote cooperation with software developers. ( interchange of knowledge for mutual professional benefit)
• (^) SELF - Certified software testers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. .(Maintain and improve their professional competency through continuing education)