- STLC Tutorial
- STLC - Home
- STLC - Overview
- COMPARISON - STLC and SDLC
- Testing Fundamental Principles
- STLC - Requirement Analysis
- STLC - Entry and Exit Criteria
- STLC - Acceptance Criteria
- STLC - Test Planning
- STLC - Test Case Development
- STLC - Test Environment Setup
- STLC - Test Execution
- STLC - Defect Life Cycle
- STLC - Defect Classification
- STLC - Test Cycle Closure
- STLC Useful Resources
- STLC - Quick Guide
- STLC - Resources
- STLC - Discussion
STLC - Testing Fundamental Principles
The common objective of testing is finding bugs as early as possible. And, once the bugs are fixed, make sure it is working as expected and not breaking any other functionality.
To achieve these goals, seven basic principles are given for software testing −
What Testing shows?
Testing can show that defects are present but there is no way to prove that there is no defect in the product. Testing phases make sure that the application under test is working based on the given requirement and it helps to reduce the probability of undiscovered defects in the application. But, even if no defects are found, it does not mean that it is absolutely correct. We can assume that AUT is matching with our exit criteria and maintaining the requirements according to SRD.
Is Exhaustive Testing possible?
100% coverage or testing of all combinations of inputs and possible combinations are not possible except of trivial cases. Instead of exhaustive testing, risk analysis and priorities are used to define the scope of testing. Here, most of the real time scenarios can consider including most probable negative scenario as well. This will help us track the failure.
Early Testing
Testing activities should start as soon as possible and be focused on defined objectives in Test Strategy and expected results. Early stage of testing helps to identify Requirement Defect or design level discrepancies. If these types of bugs are captured in initial stage, it helps us save time and is cost-effective too. The answer to why testing should start at an early stage is very simple – as soon as the SRD is received, the testers can analyze the requirement from the testing perspective and can notice a requirement discrepancy.
Defect Clustering
Based on previous product defect analysis, it can be said that most of the defects are identified from small set of modules which are critical for application. These modules can be identified based on complexity, different system interaction or dependency on different other modules. If testers can identify these crucial modules, they can focus more on these modules to identify all possible bugs. In a study, it is found that 8 out of 10 defects are identified from 20% functionality of AUT.
Pesticide Paradox
What is pesticide paradox – if pesticides are frequently used on crops, there comes when the insects develop a certain kind of resistance and gradually the pesticides thus sprayed seem to be ineffective on the insects.
The same concept is applicable on testing also. Here, insects are bugs while pesticides are test cases that are used to run again and again. If the same sets of test cases are executed again and again, these test cases become ineffective after certain timeframe and the testers will not be able to identify any new defect.
To overcome these conditions, test cases should be revised and reviewed time to time and new and different test cases can be added. This will help in identifying new defects.
Testing is Context Dependent
This principle states that two different type of application can’t be tested using same approach until both applications are of same nature. For example, if a tester uses the same approach for Web Based Application and Mobile Application, that is completely wrong and there is high risk of poor quality of product release. Testers should use different approaches, methodologies, techniques and coverage for different types and nature of applications.
Absence of Error – Fallacy
This principle states finding defects and fixing them until the application or system is stable, is time consuming and also eats up on the resources. Even after fixing 99% of the defects, there is a high risk of unstable application. The first essential thing is to verify the stability of the application and the prerequisites of the environment. If these two conditions fulfill, only then we can start with the detailed testing.