1- Defect clustering: A small number of modules contains most of the defects discovered during pre-release testing or shows the most operational failures.
Defect Clustering in Software Testing is based on the Pareto principle, also known as the 80-20 rule, where it is stated that approximately 80% of the problems are caused by 20% of the modules.
2- Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really very important to review the test cases regularly and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
What is Bug Leakage, Bug Release, Bug Age
Bug (defect) Leakage:
When a Bug (defect) if found by customer / end user missed by the testing team to detect, while testing the software.
Bug (defect) Release:
Bug Release- Release of the software with the known bugs is called bug release. when software or an application is handed over to the testing team knowing that the defect is present in a release.
During this the priority and severity of bug is low.
Bug (defect) Age:
Bug (defect) Age is the difference in time between the date a defect is detected (confirmed and assigned) and the defect was fixed (verified and closed).
Bug (defect) Age = Bug Fix Date – Bug Detection Date
Functional testing is primarily is used to verify software is providing the same output as required by the end-user or business. Typically, functional testing involves evaluating and comparing each software function with the business requirements. Software is tested by providing it with some related input so that the output can be evaluated to see how it conforms.
Functional Testing Process:
- The identification of functions that the software is expected to perform
- The creation of input data based on the function’s specifications
- The determination of output based on the function’s specifications
- The execution of the test case
- The comparison of actual and expected outputs
- To check whether the application works as per the customer need
|Functional Testing||Non-Functional Testing|
|Functional testing is performed using the functional specification provided by the client and verifies the system against the functional requirements.||Non-Functional testing checks the Performance, reliability,
scalability and other non-functional aspects of the software system.
|Functional testing is executed first||Non functional testing should be performed after functional testing|
|Manual testing or automation tools can be used for functional testing||Using tools will be effective for this testing|
|Business requirements are the inputs to functional testing||Performance parameters like speed , scalability are inputs to non-functional testing.|
|Functional testing describes what the product does||Nonfunctional testing describes how good the product works|
|Easy to do manual testing||Tough to do manual testing|
|Types of Functional testing are
|Types of Non functional testing are
What are software test stubs?
– Software test stubs are programs which simulate the behaviors of software components (or modules) that are the dependent modules of a under test module. Stubs are the dummy routines which are introduced that simulate a module. It is used in the top-down approach of the testing in which testing is done from the top of hierarchy. Stubs simulate the low level modules.
What are software test drivers?
– Software test drivers are programs which simulate the behaviors of software components (or modules) that are the control modules of a under test module. Drivers are the dummy routines which are introduced that invoke a module. It is used in the bottom-up approach of the testing in which testing is done from the bottom of hierarchy. Drivers simulate the high level modules.
Integration testing in a variety of ways:
- The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.
- The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.
For example (STUB):
We have Modules A,B,C. A module is ready and Need to Test it , But it calls functions from B and C (Which is not ready). To test at a particular module we write a Small Dummy piece of code which Simulates B and C which will return values for A, These piece of Dummy code is Called Stubs in a Top Down Integration.
For example (DRIVER):
We have Modules A,B,C. B and C modules ready Need to Test it, but A module is not ready (Which return values from A) So to get the values from A We write a Small Piece of Dummy code for A which returns values for B and C, So these piece of code is called Drivers in Bottom Up Integration.
Test Scenarios provides and overview of what needs to be tested in which conditions.
Test Cases outline how that condition will be tested with positive and negative outcome by changing the pre-conditions and required variables.
Test Cases are most important part of SDLC and without this, it’s tough to track, understand, follow and reason out something, but in Agile Test Cases are being replaced fast with Test Scenarios.
Example: Login Page with username, password, login and cancel buttons
If asked to write Test Cases for the same, we will end up writing more than 50 Test Cases by combining different options and details, but if Test Scenarios to be written, it will be a matter of 10 lines as below:
1. To check Application is Launching
2. To check text contents on login page
3. To check Username field
4. To check Password field
5. To check Login Button and cancel button functionality
Agile testing is a software testing practice that follows the rules of the agile manifesto, treating software development as the customer of testing.
Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing.
Agile methods were developed as a response to the issues that the traditional V-Model and waterfall methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed
QA is a set of activities for ensuring quality in the processes by which products are developed.
QC is a set of activities for ensuring quality in products. The activities focus on identifying defects in the actual products produced.
Focus on –
QA aims to prevent defects with a focus on the process used to make the product. It is a proactive quality process.
QC aims to identify (and correct) defects in the finished product. Quality control, therefore, is a reactive process.
The goal of QA is to improve development and test processes so that defects do not arise when the product is being developed.
The goal of QC is to identify defects after a product is developed and before it’s released.
Prevention of quality problems through planned and systematic activities including documentation.
The activities or techniques used to achieve and maintain the product quality, process and service.
Two other terms used to describe how software is tested are Static Testing and Dynamic Testing Techniques
Static Testing: refers to testing something that’s not running—examining and reviewing it. During static testing, software work products are examined manually, or with a set of tools, but not executed.
Dynamic Testing: is what you would normally think of as testing—running and using the software.
Software Development Life Cycle methodologies are available for executing software development projects. Although each methodology is designed for a specific purpose and has its own advantages and disadvantages, most methodologies divide the life cycle into phases and share tasks across these phases. Few commonly used methodologies in actual testing:
Waterfall model: is one of the earliest structured models for software development. It consists of the following sequential phases through which the development life cycle progresses:
- Requirement Gathering
- Analysis phase,
- Software Design,
- Implementation and Testing
V model: is an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. (Its is also know as Verification and Validation model).
Agile model: Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing.
Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In agile the tasks are divided to time boxes (small time frames) to deliver specific features for a release.
Image Posted on Updated on
A software bug is an Defect, Error, Flaw, Failure, or Fault in a computer program or system that causes it to produce an incorrect or unexpected result. Most bugs arise from mistakes and errors made by people in either a program’s source code or its design, or in frameworks and operating systems used by such programs, and a few are caused by compilers producing incorrect code.