UNIT-I

INTRODUCTION
1.Basics of software testing

2.Testing objectives

3.Principles of testing

4.Test life cycle

5.Types of testing

6.Software defect tracking

1
 Basics of Software Testing
Importance of Software testing:

 Defects can be identified early

 Improves the quality of software
 Increase customer satisfaction
 Helps with scalability
 Saves time and money
Software Testing is the process of evaluation. A software testing is used to detect differences
between given input and expected output. Testing assesses quality of the product. In other
words Software testing is a verification and validation process.

Verification: Verification is the process to make sure the product satisfies the conditions
imposed at the start of development phase.

Validation: Validation is the process to the make sure the product satisfies the conditions
imposed at the end of development phase.

Basics of Software Testing:

Testing is a process of exercising the software product in pre-defined ways to check if

behaviour is the same as expected behaviour.

“Testing traditionally means testing of program code.”

Need of Testing:

 To Know efficiency of software.

 To identify errors, bugs and defects.
 To determine software quality.
Examples:

When does Tests Fail:

 If it won’t give expected results
 If it won’t reveal bugs
Difference between Errors, Bugs and Defaults:
Errors: Error is a mistake, misconception or misunderstanding from the part of software
developer. It may be during compilation time or run time.
Bugs: A bug is the result of coding error. An error found in development environment before
product is delivered to the customer. Bug is terminology of Tester.
Defaults: An incorrect step, Process or data definition in a computer program which causes
the program to perform in an unintended and unanticipated manner.

2
 Testing Objectives

• The stakeholders in a test process are Programmers, the test engineers, the project
managers and the customer.
• Different Stakeholders view a test process from different perspectives mentioned below.
• Finding defects or bugs may get created by the programmer while developing the
software.
• Gaining confidence in and providing information about the level of quality
• To prevent defects in the final product
• To make sure the end result meets the business and user requirements.
• To ensure that it satisfies the BRS (Business Requirement Specifications) And SRS
(System Requirement Specifications).
• To gain the confidence of the customer by providing them a quality product.
• To provide customers with a quality product and increase their loyalty to the
organisation.

3
 Principles of Testing
There are seven principles in software testing:

1. Testing shows the presence of defects

2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is Context-Dependent
7. Absence of Errors fallacy

1. Testing shows presence of defects:

The goal of software testing is to make the software fail. Software testing reduces the presence
of defects. Software testing talks about the presence of defects and doesn’t talk about the absence
of defects. Software testing can ensure that defects are present but it cannot proof that software
is defect-free. Even multiple testings can never ensure that software is 100% bug-free. Testing
can reduce the number of defects but not removes all defects.

2. Exhaustive testing is not possible:

It is the process of testing the functionality of a software in all possible inputs (valid or invalid)
and pre-conditions is known as exhaustive testing. Exhaustive testing is impossible means the
software can never test at every test cases. It can test only some test cases and assume that
software is correct and it will produce the correct output in every test cases. If the software will
test every testcase, then it will take more cost, effort, etc. and which is impractical.
4
3. Early Testing:

To find the defect in the software, early test activity shall be started. The defect detected in
early phases of SDLC will be very less expensive. For better performance of software, software
testing will start at initial phase i.e. testing will perform at the requirement analysis phase.

4. Defect clustering:

In a project, a small number of the module can contain most of the defects. Pareto Principle to
software testing states that 80% of software defects comes from 20% of modules.

5. Pesticide paradox:

Repeating the same test cases again and again will not find new bugs. So it is necessary to
review the test cases and add or update test cases to find new bug

6. Testing is context dependent:

Testing approach depends on context of software developed. Different types of software need
to perform different types of testing. For example, The testing of the e-commerce site is different
from the testing of the Android application.

7. Absence of errors fallacy:

If a built software is 99% bug-free, but it does not follow the user requirement, then it is
unusable. It is not only necessary that software is 99% bug-free but it also mandatory to fulfil all
the customer requirements.

5
 Software Test Life Cycle
The software testing life cycle is the process of executing different activities during testing.

The main role of STLC is to find those mistakes and get them fixed. The main goal of conducting
an STLC is to maintain product quality.

SDLC is all about assuring the product’s quality. Every application has different attributes such
as reliability, functionality, and performance.

STLC aids in enhancing these attributes and facilitates the delivery of an ideal end-product.

Phases of STLC
The different phases of the software testing life cycle in detail.

1. Requirement Analysis

The software Testers have to view, study, and analyze the available specifications and
requirements. Certain requirements produce outcomes by feeding them with input data. These
requirements are testable requirements. Testers study both functional and non-functional
requirements. After that, they have to pick out testable requirements. …………………………
Activities in this phase include brainstorming for requirement analysis and identifying and
prioritizing test requirements. They also include picking out requirements for
both automated and manual testing.

2. Test Planning

The next step is test planning, and the QA team creates this plan after analyzing all the
necessary testing requirements. They outline the scope and objectives after understanding the
product domain. The team then analyzes the risks involved and defines time schedules and
testing environments to create a strategy. After that, management finalizes the tools and assigns
roles and responsibilities to individuals. An approximate timeline is also defined by which the
testing of each module should be completed.

6
To sum it up, the two primary outcomes of this phase include test plan documentation and an
estimation of time and efforts.

3. Test Case Designing and Development:

After development and planning, it’s time to let the creative juices flow! Based on the test plan,
testers design and develop test cases. Next comes the verification and validation of specified
requirements in the documentation stage. Also, the reviewing, updating, and approval of
automation scripts and test cases are essential processes of this stage. This phase also includes
defining different test conditions with input data and expected outcomes.

4. Test Environment Setup:

Testing activities need certain environmental factors—such as servers, frameworks, hardware,

and software—for executing developed test cases. Software and hardware configuration, along
with test data setup, are the main components of this phase. And it’s mandatory to smoke test
and to equip your testers with bug reporting tools.

It’s the job of the QA manager supervising the team to take care of setting up the test
environment.

5. Test Execution:

An application is ready for testing once the team is done with all the previous phases.
According to the test plan, the testers test cases. They also identify, detect, and log the defects,
thus reporting the bugs. The team is also responsible for comparing expected results with the
real outcome.

Once the development team removes a bug, regression testing begins. Regression testing is to
ensure that the software or application works even after deploying a change.

6. Test Closure:

The last stage of the STLC: Test closure.

The end of test execution and delivery of the end product marks the onset of the test closure
phase. The QA team checks the test results and discusses them with other team members. Some
other factors they consider are product quality, test coverage, and project cost.

Apart from that, the team also considers test metrics, the fulfilment of goals, and their
adherence to deadlines. Once they have a total grasp on what happened, they can evaluate the
entire testing strategy and process.

The Entry and Exit Criteria for Testing:

All six phases of a software testing life cycle have entry or exit criteria associated with them.
Testers need to finish executing the test cases within a fixed time. Also, they need to maintain
the quality, functionality, and efficiency of the end product. Therefore, defining entry and exit
criteria is a must.
7
Entry Criteria

Entry criteria state which requirements the team has to take care of before starting the testing
procedure. Before testing begins, it’s mandatory to cross off all requirements.

There are some ongoing activities and conditions that have to be present before testing begins.
First, you need input from the development team. You’ll also want to examine the test plan, test
cases and data, the testing environment, and your code.

Exit Criteria

Exit criteria state the requirements and actions to complete before the testing ends. In other
words, they include items to cross off the task list and processes to complete before testing comes
to a halt.

Exit criteria will include the identification of high-priority defects. You’ll need to get those fixed
right away. Testers have to pass different test cases and ensure full functional coverage.

Conclusion

Simply identifying errors in the last stage of an SDLC is not an efficient practice anymore.
There are various other daily activities a firm has to focus on. Devoting too much of your
precious time to testing and fixing bugs can hamper efficiency.

To ease the testing process, it’s important to make efficient use of time and resources.
Following a systematic STLC not only results in quick bug fixing but it also enhances the product
quality. By increasing customer satisfaction, The software Firm enjoy an increased ROI and
improved brand presence.

8
 Types of Testing
As testers are aware of the different types of Software Testing.

Different Types of Software Testing

❖ Unit Testing
❖ Integration Testing
❖ Functional Testing
❖ System Testing
❖ Stress Testing
❖ Performance Testing
❖ Usability Testing
❖ Acceptance Testing
❖ Regression Testing
❖ Beta Testing

Unit Testing:

Unit tests are very low level, close to the source of your application. They consist in testing
individual methods and functions of the classes, components or modules used by your software.
Unit tests are in general quite cheap to automate and can be run very quickly by a continuous
integration server.

Integration Testing:

Integration tests verify that different modules or services used by your application work well
together. For example, it can be testing the interaction with the database or making sure that
microservices work together as expected. These types of tests are more expensive to run as they
require multiple parts of the application to be up and running.

Functional Testing:

functional Testing is to ensure that the specifies functionality required in the system
requirements works. It falls under class of Black box testing.

System Testing:

System Testing is to ensure that by putting software in different environments .(Ex. Operating
systems)it still works. System Testing is done with full system implementation and
environment.

Stress Testing:

Stress Testing is the testing how System behaves in unfavorable conditions. Testing is
conducted beyond limits of specifications. . It falls under class of Black box testing.

9
Performance testing:

Performance tests check the behaviors of the system when it is under significant load. These
tests are non-functional and can have the various form to understand the reliability, stability,
and availability of the platform. For instance, it can be observing response times when executing
a high number of requests, or seeing how the system behaves with a significant of data.

Performance tests are by their nature quite costly to implement and run, but they can help you
understand if new changes are going to degrade your system.

Regression Testing:

Every time new module is added leads to changes in program. This type of testing make sure
that whole component works properly even after adding components to the complete program.

Acceptance Testing:

Acceptance tests are formal tests executed to verify if a system satisfies its business
requirements. They require the entire application to be up and running and focus on replicating
user behaviours. But they can also go further and measure the performance of the system and
reject changes if certain goals are not met.

Usability Testing:

Usability Testing is performed to the perspective of the client, to evaluate how the GUI is user
friendly.

Beta Testing:

Beta Testing is done by end users, a team outside development or publicly releasing full pre-
versions of the product which is known beta version. The aim of beta testing is to cover
unexpected errors.

10
 Software Defect Tracking
Defect tracking / Bug tracking, is the systematic process of identifying, recording, monitoring,
and managing defects or issues in a product or system throughout its development lifecycle.
These defects can encompass various aspects, including software bugs, hardware malfunctions,
design flaws, or other imperfections that may hinder the product’s functionality, performance,
or quality.

A defect tracker is like a digital journal that records all the problems or errors in a product or
project. It’s like having a list of everything that’s not working correctly.

Importance of Software defect Tracking and how it works:

a. Preventing Errors from Being Missed

b. Saving time
c. Working on the right problems

Objectives

a. Keeping Track of All Defects: This is important because missing a defect could cause
problems later when people use the software.
b. Finding the Best Solutions and Preventing More Defects
c. Saving Time and Doing Better Work - Defect tracking ensures you don’t waste time looking
at the same problems repeatedly.

Key features
Effective communication: Defect tracking is a team effort, so it is essential to have effective
communication between all stakeholders. This includes the developers, testers, and managers.

Proper documentation: All defects should be properly documented, including the steps to
reproduce the defect, the severity of the defect, and the impact of the defect. This
documentation will help the developers to fix the defects quickly and efficiently.

Regular reporting: Defect tracking should be a continuous process. Regularly reporting

defects’ status will help identify any trends or patterns. This information can be used to
improve the defect tracking process and to prevent defects from occurring in the future.

Prioritization: Not all defects are created equal. Some defects are more critical than others. It
is essential to prioritize defects so that the most critical defects are fixed first.

Tracking of defects: It is important to track the progress of defects. This includes tracking the
status of the defect, the assigned engineer, and the estimated time to fix the defect. This
tracking information will help to ensure that defects are fixed on time.

Resolution of defects: The goal of is to resolve defects. This means that the defect should be
fixed, and the fix should be verified.

11
Continuous improvement: Defect tracking is an ongoing process. It is essential to improve the
defect-tracking process continuously. This can be done by identifying and addressing gaps or
weaknesses in the process.

Defect tracking Parameters

Defect tracking parameters are the attributes that are used to track defects. These parameters
can be used to identify, prioritize, and manage defects.

❖ ID: A unique identifier for each defect.

❖ Title: A brief description of the defect.
❖ Description: A precise description of the defect, including the steps to reproduce the
defect.
❖ Severity: The severity of the defect, such as critical, major, or minor.
❖ Priority: The priority of the defect, such as high, medium, or low.
❖ Status: The status of the defect, such as open, closed, or deferred.
❖ Assigned to: The engineer who is assigned to fix the defect.
❖ Due date: The date by which the defect should be fixed.
❖ Comments: Any comments about the defect.

How to Design a Defect Tracking System/Process?

Here are the steps on how to design a defect-tracking system/process:

1. Define the goals of the defect tracking system. What do you want to achieve with the
defect-tracking system? Do you want to track, prioritize, manage, or generate reports on
defects?
2. Identify the stakeholders. Who will be using the defect tracking system? Will it be used
by developers, testers, managers, or other stakeholders?
3. Define the parameters. What information will be tracked about each defect? This could
include the defect ID, title, description, severity, priority, status, assigned to, due date, and
comments.
4. Select a defect tracking tool. There are many defect-tracking tools available. Pick a tool
that meets the needs of your project and team.
5. Configure the defect tracking tool. Once you have selected a defect-tracking tool, you
need to configure it to meet the needs of your project. This includes setting up the defect
tracking parameters and defining the workflows for defect submission, prioritization, and
management.
6. Train the users. Once the defect tracking system is in place, you must train the users to
use it. This includes how to submit defects, prioritize defects, manage defects, and generate
reports.
7. Monitor and improve the defect tracking system. Once the system is used, you must
monitor it to ensure it meets your project’s needs. This includes identifying gaps or
weaknesses in the system and making necessary improvements.

12
Salient features

1. It is done by inspecting, testing or recording feedback from customers. And making new
versions that fix the defects.
2. Software defect tracking is the process of managing the defect lifecycle.
3. When defect is found, it is reported the developer.
4. The reporter sees the bug details and fixes it.
5. The developer re informs to the quality assurance person to verify the fix
6. If the bug is fixed, tester closes the bug.
7. Here the defect is not only reported but needs to be visited several times by different
people before it can be closed down.
8. Software Detecting process is facilitated by use of defect tracking tools.
9. When the number of defects gets quite large and defects need to be tracked over extended
period of time.
10. The use defect tracking process makes the management task easier.

13