Mod1

What is Software Testing?

Software testing is an important process in the software development lifecycle . It
involves verifying and validating that a software application is free of bugs, meets the
technical requirements set by its design and development , and satisfies user requirements
efficiently and effectively.
The Evolution of Software Testing
In early days of software development, software testing was considered only a debugging
process for removing errors after the development of software.
We can divide the evolution of software testing into the following phases;
 Debugging oriented phase
 Demonstration oriented phase
 Destruction oriented phase
 Evaluation oriented phase
 Prevention oriented phase
 Process oriented phase
Debugging oriented phase:-
This stage represents the initial testing phase. The fundamentals weren’t recognised back
then. Programmers wrote programmes and then tested them until they were certain that all
flaws were fixed. Checkout, a word for testing that concentrated on getting the system to
function, was used.
Demonstration oriented phase:-
In this stage, debugging kept going. It is understood in 1957 that the goal of checkout is not
only to execute the software but also to show that it complies with the stated criteria. As a
result, the range of the programme check-up expanded from programme runs to
programme accuracy.
Destruction oriented phase:-
Here, the definition of testing was altered to “testing is to detect more and more errors”
rather than “testing is to prove the absence of errors.” In this stage, the value of early testing
was also recognised.
Evaluation oriented phase:-
In this stage, emphasis is placed on software product quality so that it can be assessed at
every level of development.
When compared to issues discovered during the implementation or post-implementation
phases, it was less expensive to troubleshoot problems that were discovered early in the
development process.
Prevention oriented phase:-
The evaluation model stressed on concept of bug prevention as compared to earlier concept
of bug-detection.
With the idea of early detection of bugs in earlier phases, we can prevent the bugs in
implementation.
Process oriented phase:-
In this stage of the software development life cycle, testing was developed as a full
procedure rather than a single stage (executed after coding)
The testing procedure begins as soon as a project’s requirements are established and
proceeds concurrently with the SDLC (Software Development Life Cycle

Myths about Software Testing

software testing is a critical phase in software development. However, several myths and
misconceptions surround it, often leading to poor testing practices or undervaluing its
importance. Let’s debunk these myths to improve understanding and software quality:

1. Testing Expenditure is Unnecessary

Myth: Testing is an expensive and avoidable process.
Reality: Proper testing reduces long-term costs by minimizing maintenance and bug fixes
post-release. A one-time investment in testing prevents expensive future errors.

2. Testing Takes a Lot of Time

Myth: Testing prolongs the development process.
Reality: Testing itself is efficient. However, debugging (fixing identified bugs) can take more
time due to complexity. Testing saves time by catching issues early.

3. Perfect Testing is Possible

Myth: A thoroughly tested application is flawless.
Reality: No software can be 100% error-free. Testing identifies and minimizes risks, but some
vulnerabilities might surface post-deployment due to unforeseen scenarios.

4. Only Completely Developed Products Are Tested

Myth: Testing happens only after development is finished.
Reality: Testing is a continuous process conducted at every development stage, such as unit,
integration, and system testing. Delaying testing until full development can lead to chaos and
higher costs.

5. Tested Software is Defect-Free

Myth: Testing guarantees zero bugs.
Reality: While testing reduces defects significantly, achieving a completely defect-free
product is impractical. Unknown bugs may still exist.

6. Automation Testing Consumes Less Time

Myth: Automation always speeds up testing.
Reality: Automation testing is efficient but not applicable to all stages of development. It
complements manual testing but does not replace it entirely. Some tests, especially
exploratory or usability tests, require manual efforts.

7. Software Testing is a Cakewalk

Myth: Testing can be done by anyone with minimal knowledge.
Reality: Effective testing demands expertise, experience, and a solid understanding of testing
methodologies, tools, and software behavior.

8. Testing is All About Finding Bugs

Myth: The sole purpose of testing is to detect bugs.
Reality: Testing evaluates software's functionality, performance, usability, and security. Bug
identification is a key aspect but not the only objective.
Goals of Software Testing
The main goal of software testing is to find bugs as early as possible and fix bugs and make
sure that the software is bug-free.
The goals of software testing may be classified into three major categories as follows:
1. Immediate Goals
2. Long-term Goals
3. Post-Implementation Goals
1. Immediate Goals: These objectives are the direct outcomes of testing. These objectives
may be set at any time during the SDLC process. Some of these are covered in detail below:
 Bug Discovery: This is the immediate goal of software testing to find errors at any
stage of software development. The number of bugs is discovered in the early stage
of testing.
 Bug Prevention: This is the immediate action of bug discovery,
that occurs as a result of bug discovery. Everyone in the software
development team learns how to code from the behavior and
analysis of issues detected, ensuring that bugs are not duplicated
in subsequent phases or future projects.
Long-Term Goals: These objectives have an impact on product quality
in the long run after one cycle of the SDLC is completed. Some of these
are covered in detail below:
 Quality: This goal enhances the quality of the software product.
Because software is also a product, the user’s priority is its quality.
 Customer Satisfaction: This goal verifies the customer’s
satisfaction with a developed software product.
 Reliability: reliability means gaining the confidence of the
customers by providing them with a quality product.
 Risk Management: Risk is the probability of occurrence of
uncertain events in the organization and the potential loss that
could result in negative consequences. Risk management must be
done to reduce the failure of the product and to manage risk in
different situations.
3. Post-Implemented Goals: After the product is released, these
objectives become critical. Some of these are covered in detail below:
 Reduce Maintenance Cost: Post-released errors are costlier to
fix and difficult to identify. Because effective software does not
wear out, the maintenance cost of any software product is not the
same as the physical cost.
 Improved Software Testing Process: These goals improve the
testing process for future use or software projects. These goals are
known as post-implementation goals
The Psychology Of Testing
Software testing is a technical task that requires engagement of
numerous software testers and developers, who combine individual
efforts to create a software with impeccable features and superior
quality. However, this technical task also requires some important
considerations of psychology to ensure smooth development and testing
of the software product. Therefore, to elaborate more on this topic, here
is a discussion on the psychology of testing and its impact on testing.
1. Mindset of Developers and Testers
The mindset of team members significantly impacts the software
development lifecycle. Developers and testers often have contrasting
roles:
 Developers focus on building functional systems.
 Testers are responsible for identifying flaws to ensure quality.
This difference in focus requires a balanced approach. Testing and
analyzing software demand a different skill set than development,
making diverse perspectives crucial for success. Modern techniques and
methodologies further emphasize the need for these complementary
mindsets to achieve a high-quality product.

2. Communication in a Constructive Manner

Effective communication is vital for collaboration:
 Constructive Feedback: Testers should report bugs in an
objective, polite, and courteous manner to avoid conflicts or
discouragement.
 Avoiding Misunderstandings: Clear, empathetic communication
ensures team members understand issues without damaging
relationships.
 Building Trust: Reporting defects respectfully strengthens the
team’s bond and helps everyone focus on achieving shared goals.
Since finding and reporting defects can sometimes feel negative to
developers, testers should aim to make the process feel collaborative
rather than critical.

3. Test Independence
Independent testing is often more effective than self-testing or group
testing. Here's why:
 Avoids Bias: Independent testers are impartial and can provide
objective feedback.
 Fresh Perspective: Individuals from outside the project, or even
different organizations, can detect issues that internal team
members might overlook.
 Accurate Results: Independent testing delivers unbiased, reliable
results, aiding in creating a superior product.
This approach ensures thorough and effective testing, resulting in
innovative and robust software.
Model for Testing in software testing methodologies

 A typical software system goes through with following three test

Unit/Component Testing
Integration Testing
System Testing
Unit/Component Testing

 A unit is the smallest testable piece of software that can be

compiled, assembled, linked, loaded etc
 A unit is usually the work of one programmer and consists of
several hundred or fewer lines of code
 Unit Testing is the testing we do to show that the unit does not
satisfy its functional specification, or that its implementation
structure does not match the intended design structure
 A component is an integrated aggregate of one or more units
 Component Testing is the testing we do to show that the
component does not satisfy its functional specification or that its
implementation structure does not match the intended design
structure
Integration testing

 Integration is the process by which components are aggregated to

created larger components
 Integration testing is testing done to show that even through the
components were individually satisfactory (after passing componet
testing)
 It checks if the combination of components are incorrect or
inconsistent
 It verifying software quality by testing two or more depedent
software modules as a group

System Testing
  A system is a big component
 System Testing is aimed at revealing bugs that cannot be
attributed to components
 It includes testing for performance, security, accountability,
configuration sensitivity, startup and recovery
 System testing enables us to test, verify and validate both the
business requirements as well as the applications architecture

Sr.N
Exhaustive Testing Effective Testing
o.

It involves verification of all

It involves the verification of the
1 possible input data, and
effectiveness of a software.
scenarios.

It is practically not possible to It is practically possible to

2
perform. perform.

It is an elaborate, and time- It does not take much time to

3
consuming process. complete.

It is a practical testing approach,

It is a theoretical testing
4 and verifies the effectiveness of
approach.
the software.

It is an expensive testing It is an economic testing

5
methodology. methodology.

It involves entire testing,

6 covering all possible scenarios, It prioritizes the test scenarios.
and use cases.

What is Software Testing Life Cycle (STLC)?

Software Testing Life Cycle (STLC) is a sequence of specific activities
conducted during the testing process to ensure software quality goals
are met. STLC involves both verification and validation activities.
 STLC is an integral part of Software Development Life Cycle (SDLC). But, STLC deals
only with the testing phases.
 STLC starts as soon as requirements are defined or SRD (Software Requirement
Document) is shared by stakeholders.
 STLC provides a step-by-step process to ensure quality software.
STLC Phases
STLC has the following different phases but it is not mandatory to follow all phases. Phases
are dependent on the nature of the software or the product, time and resources allocated
for the testing and the model of SDLC that is to be followed.

There are 6 major phases of STLC −

 Requirement Analysis − When the SRD is ready and shared with the stakeholders,
the testing team starts high level analysis concerning the AUT (Application under
Test).
 Test Planning − Test Team plans the strategy and approach.
 Test Case Designing − Develop the test cases based on scope and criteria’s.
 Test Environment Setup − When integrated environment is ready to validate the
product.
 Test Execution − Real-time validation of product and finding bugs.
 Test Closure − Once testing is completed, matrix, reports, results are documented.

Verification
Verification is the process of checking that software achieves its
goal without any bugs. It is the process to ensure whether the
product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have.
Verification is simply known as Static Testing.

Here are some of the activities that are involved in verification.

 Inspections

 Reviews

 Walkthroughs

 Desk-checking
Validation Testing is known as Dynamic Testing in which we examine whether we have
developed the product right or not and also about the business needs of the client. Here are
some of the activities that are involved in Validation.
1. Black Box Testing
2. White Box Testing
3. Unit Testing
4. Integration Testing
Note: Verification is followed by Validation.

What is Requirements Verification?

Requirements Verification is the process of confirming that the system requirements contain
all the necessary elements of well-written requirements. Requirements verification is a
critical step in system development, as it helps ensure that the product meets its objectives
and functions as intended.
The main goals of requirements verification are to ensure completeness, correctness, and
consistency of the system requirements.
This phase can uncover missing requirements, ambiguous, or invalid ones, reducing rework
and cost overruns. It’s far more effective to resolve a little problem upfront than it is in the
future when hundreds of lines of code or a completely manufactured complex product must
be tracked down and fixed
Techniques Used in Requirements Verification:
There are several techniques that can be used for requirements verification to ensure that
the requirements meet the necessary quality criteria. Some of the commonly used
techniques include:
1. Inspection: This technique involves a systematic review of the requirements by a
team of experts to identify any errors, omissions, or inconsistencies. It can be
conducted manually or using automated tools.
2. Testing: Testing involves designing and executing tests to verify that the requirements
meet the desired functionality and quality criteria. It can be conducted at different
levels, such as unit testing, integration testing, and acceptance testing.
3. Walkthrough: In a walkthrough, the requirements are reviewed by a group of
stakeholders who provide feedback and identify any issues or concerns. It is typically
less formal than an inspection.
4. Prototyping: Prototyping involves creating a simplified version of the software to
validate the requirements and identify any issues or limitations. It can help
stakeholders visualize and understand the system better.
5. Simulation: Simulation involves creating a model of the system and testing its
behavior under different scenarios. It can help identify issues with the requirements
that may not be apparent in static documentation.
6. Traceability Analysis: Traceability analysis involves tracking the relationships
between the requirements and other artifacts, such as design documents and test
cases, to ensure that the requirements are complete, consistent, and verifiable.
These techniques can be used individually or in combination to verify that the requirements
meet the necessary quality criteria and to reduce the risk of errors and inconsistencies in the
final software product.

HIGH-LEVEL DESIGN LOW-LEVEL DESIGN

High Level Design is the general system Low Level Design is like detailing HLD
design means it refers to the overall system means it refers to component-level design
design. process.

High Level Design in short called as HLD. Low Level Design in short called as LLD.
HIGH-LEVEL DESIGN LOW-LEVEL DESIGN

It is also known as macro level/system It is also known as micro level/detailed

design. design.

Furthermore, it describes the overall It describes detailed description of each

description/architecture of the application. and every module.

High Level Design expresses the brief Low Level Design expresses details of
functionality of each module. functional logic of the module.

It is created by solution architect. It is created by designers and developers.

Here in High Level Design the participants Here in Low Level Design participants are
are design team, review team, and client design team, Operation Teams, and
team. Implementers.

It is created first means before Low Level It is created second means after High
Design. Level Design.

In HLD the input criteria is Software In LLD the input criteria is reviewed High
Requirement Specification (SRS). Level Design (HLD).

High Level Solution converts the

Low Level Design converts the High Level
Business/client requirement into a High
Solution into a Detailed solution.
Level Solution.

In HLD the output criteria is database In LLD the output criteria is program
design, functional design and review record. specification and unit test plan.