Software Testing Principles can be called as Software Testing Rules as well. We can not do Software Testing randomly. We must follow some rules, so that the Software Testing Process should be effective and We can test our application in an efficient way by putting less efforts. We can do maximum coverage with minimum efforts if we use Software Testing Principles.
Software testing principles refer to a set of guidelines and concepts that must be followed while performing software testing, so that the testing process is effective, efficient, and delivers reliable results
There are 7 Different Software Testing Principles.
Exhaustive Testing or Complete Testing is not possible, that means if we start testing a particular feature of a Software for all the input values, then it will take a lot’s of time, but we always have a limited amount of time, when we do software testing, so we need to find the optimum way to do testing, so that our efforts and time should be reduced but we can do maximum coverage.
In Order to understand this principle, Let’s take an example, where we have to test a field on a Website
This means that the field can accept any number between 0 to 9999 but any number less than 0 and greater than 9999 is not allowed.
So if suppose, we will try to test this field by entering all the numbers between 0 to 9999, then it is not possible to test this functionality in 10 minutes by entering all the numbers.
If we try to enter all the numbers less than 0 in the field and all the numbers greater than 9999, then the testing will never end and Testing will never be completed.
Why are we saying that we should test it in 10 minutes, because it refers to a timeline and every time there will be a timeline given to Software Testers to complete their Testing, and that’s why we have assigned some timeline to this testing as well.
So, We can clearly see with this example, that Exhaustive (Complete) Testing is not possible.
So, We need to complete this testing using some other alternative approach and those approaches are a part of Software Testing Technique, which we will study later.
When we do testing, then it is for sure, we will find defect. It is impossible that an application is free of defect. Testing always talks about presence of defects not absence of defects.
Let’s understand this with the previous example where we were testing a field
So, this means, that we can enter numbers from 0 to 9999 and no other number is allowed, but if suppose, we type a number (-1) (negative number) or 10000 (number with more than 4 digits) then this filed should not allow this but if it allows this, then it is a defect.
And there is a high chance for this type of defect to occur. This type of Testing is called Negative Testing.
Sometime what happens is that the testers will perform Positive testing and will say that the Product is defect free. So that’s why we should be doing Negative Testing, because there is a high chance to get a defect during Negative Testing.
So, We have seen, when we do more and more testing, we tend to find more and more defects and that’s why this principle says that “Testing shows presence of defects”.
fallacy means a false belief. So When we have a false belief that there is no defect in our application, and we say that the application is defect free and the application is launched into production environment so that end users should use but If the end user says that the application is not at all useful as it is not working as expected, which means the Application is not usable by the end user. This is called Absence of errors fallacy.
So, If there is a Software Application, which is tested properly and there is no defect in the Application but still the end user is not able to use it or it is not giving the required output. This is called Absence of error fallacy.
We can understand this with the previous example where the field is accepting only numbers between 0 to 9999 and if it is tested only for positive test cases but not for negative test cases, and we say that the application is working fine. then we will have a false believe that the application is working fine and there is no defect because we didn’t test it for negative test cases and end user might get a defect while doing negative testing. So, This is one example of Absence of Error Fallacy.
Now, Let’s see one more example.
Absence of Error Fallacy might also occur if the Requirement was something else but the developer developed the Application for some other requirement, and tester tested as per the instructions from developer.
So, Testing is not just about testing the test cases, finding defects and fixing those defects, Testing is all about Building the right product which can be used by the end user.
So, a Tester should know about functional requirement and business requirement very well, So even if the developed application is developed for wrong requirement, then the tester should be able to find it and should be able to get it fixed and make it usable for the end user.
Early testing is a software testing principle that emphasizes the importance of starting the testing process as early as possible in the software development life cycle.
Early testing involves testing the software at every stage of the development process, from requirements gathering to design, coding, and integration. This can include unit testing, integration testing, system testing, and acceptance testing, among others.
Let’s take an example of a situation, where we have to test an application within 4 weeks of time, but because of Delayed Deployment from Developers, the Application was not available to test in the first week of time and Testers were left with only 3 weeks of testing.
In the 2nd Week, There were some major issues in the Application, and the developers couldn’t resolve the issue for the entire week and Testers were left with only 2 weeks of testing.
In 3rd week, Testers could start full fledge testing and they started logging defects for the issues they faced and Passed few test cases where the functionality worked fine. Developers worked on the defects fixed them and the testers could test them in the 4th week.
In 4th Week,
So, Now the Problem is, there are still some defects which need to be fixed but the timeline is over and this is a big problem.
In order to avoid this Situation, We must start testing early, which is the Principle, Early Testing.
| Week | Application Availability | Testing efforts |
|---|---|---|
| First Week | Application is not available for Testing | Testing is not done due to unavailability of Application and Week is wested |
| Second Week | Application is having blocker issues | Testing is not done properly due to blocker issues in Application and Week is wested |
| Third Week | Blocker issues of Application is Resolved | Testing started testing. Passed few functionality. Failed few and logged defects |
| Fourth Week | Defects from third weeks have been fixed | Testers tested remaining functionality. Retested the defects. |
Defect clustering is a phenomenon in software testing where a small number of modules or components in a software application contain a high proportion of defects.
Defect clustering is also called Defect Grouping. In this, defects are grouped to their respective functionality.
There is a very famous rule or principle, Pareto Principle. It says that in most of the cases, “roughly 80% of consequences come from 20% of causes“. This is also called 80/20 principle.
So when we apply Pareto Principle to Software Testing, then we can say that “mostly 80% defects come from 20% of the functionalities“.
Let’s understand this with an example of Internet Banking Software Application.
What are the functionality in Internet Banking.
So, we can see, How many functionality are there in Net Banking.
Now, Let’s assume that we found some defects while doing testing these functionalities. If we apply the concept of Defect Clustering, then we will understand that how many defects are related to which functionality.
Let’s assume that the total no of defects are 10.
| Functionality | No of Defects |
|---|---|
| Launching Net Banking Application | 0 |
| Login to Net Banking | 0 |
| Payment Transfer NEFT | 2 |
| Payment Transfer IMPS | 4 |
| Payment Transfer UPI | 2 |
| Check Bank Statements Online | 1 |
| Logout from Net Banking | 1 |
Let’s see the Percentage division of Defects.
| Functionality | Functionality Percentage | No of Defects | Defects Percentage |
|---|---|---|---|
| Launching Net Banking Application Login to Net Banking Check Bank Statements Online Logout from Net Banking | 80% | 2 | 20% |
| Payment Transfer NEFT Payment Transfer IMPS Payment Transfer UPI | 20% | 8 | 80% |
The Data is not exactly correct but this is just to show you that most of the times, few functionality generates a large no of defects.
Farmers use pesticide in their farms while farming, So that insects will eradicate. When this process is repeated over a long period of time, then these insects develop resistance to the pesticide and these pesticides become ineffective on the insects. This effect is called Pesticide Paradox.
The same applies to Software Testing as well.
The pesticide paradox in software testing is a phenomenon that refers to the idea that the repeated execution of the same test cases over and over again can reduce the effectiveness of testing.
The pesticide paradox occurs because, the software is tested repeatedly using the same test cases, it becomes less likely to find new defects. It looks like that the Software is working fine because the defects are not coming, but actually the software will have defects and we are not testing those.
Let’s understand this with an example of Net Banking Application. Let’s assume, we are testing below functionality in our Net Banking Application Testing.
When we test these functionality for the first time, We find some defects in all the functionality almost.
Once Developer fixes these defects, the Testers test these functionality again, We find that the number of defects are reduced now.
then in the next iteration, when the remaining defects are fixed by developers, again the number of defects gets reduced and this cycle goes on.
At some point of time, We find that the number of defects become 0 if we test those functionalities using the same test cases. So that means our test cases are not able to find new defects. This effect in Software Testing is called Pesticide Paradox. This is one of the very important Software Testing Principles.
Iterations
| Functionality | No of Test Cases | No of Defects in Iteration 1 | No of Defects in Iteration 2 | No of Defects in Iteration 3 | No of Defects in Iteration 4 |
|---|---|---|---|---|---|
| Launching Net Banking Application | 5 | 2 | 1 | 0 | 0 |
| Launching Net Banking Application | 5 | 3 | 2 | 1 | 0 |
| Payment Transfer NEFT | 10 | 6 | 4 | 2 | 0 |
| Payment Transfer IMPS | 10 | 6 | 4 | 3 | 1 |
| Payment Transfer UPI | 10 | 6 | 5 | 3 | 2 |
| Check Bank Statements Online | 2 | 0 | 0 | 0 | 0 |
| Logout from Net Banking | 1 | 1 | 1 | 0 | 0 |
So, We can see the number of defects are getting iteration by iteration, and thus it makes no sense to test the functionality with same test cases where we are not getting any defects.
Now, If we want to overcome the problem of Pesticide paradox, then we should write test cases for each functionality thoroughly and we should update the test cases in each iteration so that the test cases remain relevant and effective. This way, we will be able to find new defects and test our software properly and will be able to deliver a quality product to our customer.
Testing is context dependent. Now the question comes what does it mean by context dependent. So, Context dependent is made up of 2 words.
Context + dependent. We have to understand the meaning of Context. The meaning of Context is
So, when we say that Testing is Context dependent means what type of application is being tested, What is the domain of the Software Application, and many other factors, So If the Software Application is different then the Testing Approach will be different as well and it will be depend on the nature of the Software Application.
eCommerce Website has its own needs, features, and functionality, where as Net Banking Application has its own needs, features, and functionality. So, As the need, features and functionality changes, then the Testing Approach also changes.
Security is going to be the most important feature for a Net Banking Application, as the bank is responsible to keep customer’s money safe and secure.
Performance is going to be the most most important feature for an eCommerce Application, as the eCommerce Website shouldn’t go down if many users are trying to do shopping during Sale and Offers Season.
Appearance and User experience is also an important feature for an eCommerce Website, So the Customer should be attracted towards eCommerce Website.
| Software Application | Testing Approach |
|---|---|
| eCommerce Website | Approach 1 |
| Net Banking Application | Approach 2 |
| POS at Merchant | Approach 3 |
| ATM Machine | Approach 4 |
Software Testing Principles are very important so that we can do testing with full coverage with minimum efforts.
We have covered below topics in this session.
Objects, Classes and Constructor in Javascript Classes and Objects A class in any programming language…
We will start from object oriented programming basics like What are different concepts in Object…
Why we can not over ride a Constructor This is a very important question, that,…
What is Arrow Function In the last session, We had discussed about Anonymous Function. Anonymous…
What is Anonymous Function Anonymous Function is a type of function which has no name…
What is Map, Reduce and Filter Map Filter and Reduce are higher order methods for…