The document describes the concepts of error, defect, and failure in software development and outlines common reasons for software bugs, highlighting the importance of identifying defects early in the software testing process. It reviews various software development life cycle (SDLC) models, including the Waterfall, V, Spiral, and Prototyping models, detailing their advantages, disadvantages, and appropriate use cases. Additionally, it emphasizes the role of testers and test managers in ensuring effective testing and communication throughout the development phases.

1. What are Error / Defect / Failure?

2. What are Error / Defect / Failure?
• Error
• Any incorrect human action that produces a
problem in the system is called an error.
• Defect
• Deviation from the expected behavior to the
actual behavior of the system is called defect.
• Failure
• The deviation identified by end-user while using
the system is called a failure.

3. What are Error / Defect / Failure?

4. Why Software has defects?
Top 5 Reasons Why There Are Bugs in Software?
• Miscommunication or no communication
• Software complexity
• Changing requirements
• Poorly documented code
• Software development tools

5. Cost of fixing defects
• identified during Software Testing, completely depends
on the impact of the defects found.
• The earlier the defect is found, easier and less costly it is
to fix these defects.
• if the defects or failures are found in the design of the
software, then the product design is corrected and then
re-issued. However, if these
defects somehow get missed by
testers and if they are identified
during the user acceptance phase,
then it can be way too expensive to fix such type of errors.

6. Role of a Tester?
Test lead/manager: A test lead is responsible for:
• Defining the testing activities for subordinates –
testers or test engineers.
• All responsibilities of test planning
• To check if the team has all the necessary resources to
execute the testing activities
• To check if testing is going hand in hand with the
software development in all phases.
• Prepare the status report of testing activities.
• Required Interactions with customers
• Updating project manager regularly about the
progress of testing activities

7. Role of a Tester?
• Test engineers/QA testers/QC testers are responsible for:
• To read all the documents and understand what needs to be
tested.
• Based on the information procured in the above step decide
how it is to be tested.
• Inform the test lead about what all resources will be required
for software testing.
• Develop test cases and prioritize testing activities.
• Execute all the test case and report defects, define severity and
priority for each defect.
• Carry out regression testing every time when changes are made
to the code to fix defects.
• Development of required Automation Scripts
• Execution of Automation Scripts

8. Software Development Life Cycle (SDLC)

9. SDLC Models
• Waterfall Model
• V Model
• RAD Model
• Spiral Model
• Prototype Model
• Agile Model

10. Waterfall Model

11. Waterfall Model
Once upon a time, software development
consisted of a programmer writing code to solve a
problem or automate a procedure.
Nowadays, systems are so big and complex that
teams of architects, analysts, programmers, testers
and users must work together to create the millions
of lines of custom-written code that drive our
enterprises.

12. Waterfall Model
The oldest of these, and the best known, is
the waterfall model: a sequence of stages in which
the output of each stage becomes the input for the
next. These stages can be characterized and divided
up in different ways, including the following:
• Requirement Specification
• Design
• Construction (AKA Implementation or Coding)
• Integration
• Testing
• Deployment
• Maintenance

13. Waterfall Model
• The waterfall, but it’s not as useful as it once was.
The problem is that the waterfall model assumes
that the only role for users is in specifying
requirements, and that all requirements can be
specified in advance. Unfortunately, requirements
grow and change throughout the process and
beyond, calling for considerable feedback and
iterative consultation. Thus many other
development models have been developed.

14. Advantages of waterfall model
• Each phase has specific deliverables and a
review process.
• Phases are processed and completed one at a
time.
• Works well for smaller projects where
requirements are very well understood.
• It reinforces the notions of “define before
design” and “design before code”.

15. Disadvantages of waterfall model
• Adjusting scope during the life cycle can kill a
project
• No working software is produced until late during
the life cycle.
• High amounts of risk and uncertainty.
• Poor model for complex and object-oriented
projects.
• Poor model for long and ongoing projects.
• Poor model where requirements are at a
moderate to high risk of changing

16. When to use waterfall model
• Such model is highly used where requirements are clear
and there will be no changes in the development time.
We can find such scenarios in defense projects, where
requirements will be clear since before they write
requirements they will analyses well.
• We can also name this kind of life cycle model for
migration projects, where requirements will be same
only platform or languages may vary / change.
• Also can use for projects where sponsor themselves will
do testing activities, since till the completion of the
coding we will not deliver the project.

17. Quality Assurance & Quality Control

18. Quality Assurance & Quality Control

20. • Walkthrough in software testing is used to review documents
with peers, managers, and fellow team members who are
guided by the author of the document to gather feedback and
reach a consensus. A walkthrough can be pre-planned or
organised based on the needs. Generally people working on the
same work product are involved in the walkthrough process.

21. Walkthrough
• Walkthrough in software testing is used to
review documents with peers, managers, and
fellow team members who are guided by the
author of the document to gather feedback
and reach a consensus. A walkthrough can be
pre-planned or organised based on the needs.
Generally people working on the same work
product are involved in the walkthrough
process.

22. V Model

23. V Model
• V Model is an enhanced version of the classic
waterfall model whereby each level of the
development life-cycle is verified before
moving on to the next level. With this model,
software testing explicitly starts at the very
beginning, i.e. as soon as the requirements
are written.

24. Spiral Model

25. Spiral Model
• The spiral model starts with an initial pass through a
standard waterfall life cycle, using a subset of the total
requirements to develop a robust prototype.
• After an evaluation period, the cycle is initiated again,
adding new functionality and releasing the next prototype.
This process continues, with the prototype becoming larger
and larger with each iteration. Hence, the “Spiral Model”
• The theory is that the set of requirements is hierarchical in
nature, with additional functionality building on the first
efforts. This is a sound practice for systems where the entire
problem is well defined from the start, such as modeling
and simulating software.

26. Spiral Model
• Business-oriented database projects do not enjoy
this advantage. Most of the functions in a
database solution are essentially independent of
one another, although they may make use of
common data.
• As a result, the prototype suffers from the same
flaws as the prototyping life cycle. For this reason,
the software development team has decided
against the use of the spiral lifecycle for database
projects.

27. Spiral Model
1. Planning
The product manager focuses on defining the spiral’s
objectives, identifying the requirements needed to achieve the
objective, and, lastly, defining the scope of the spiral.
2.Risk analysis
In this phase of the cycle, the product manager pulls their risk
register and identifies all of the potential risks associated with
the spiral’s objectives and requirements. Risks can be
technical, financial, market-related, operational, and/or
environmental.
The product manager then established strategies to mitigate
those risks and goes back to redefine some components of
their requirements.

28. Spiral Model
3. Engineering and development
In this phase, the engineers take what was documented
in the requirements and translate it into a functional
product. The product manager in this phase validates
and ensures that what was built meets the requirements
and objectives of the spiral.
4. Evaluation
This is the last step of the cycle. The product managers
evaluate the success of the output of the spiral using the
defined metrics in the spiral objectives. The product
manager, with the internal and/or external stakeholders,
identified areas of improvement that can be
incorporated into future cycles.

29. Advantages of the Spiral Model
• Risk Handling: The projects with many unknown risks that
occur as the development proceeds, in that case, Spiral
Model is the best development model to follow due to the
risk analysis and risk handling at every phase.
• Good for large projects: It is recommended to use the
Spiral Model in large and complex projects.
• Flexibility in Requirements: Change requests in the
Requirements at a later phase can be incorporated
accurately by using this model.
• Customer Satisfaction: Customers can see the
development of the product at the early phase of the
software development and thus, they habituated with the
system by using it before completion of the total product

30. Advantages of the Spiral Model
• Iterative and Incremental Approach: The Spiral Model
provides an iterative and incremental approach to software
development, allowing for flexibility and adaptability in
response to changing requirements or unexpected events.
• Emphasis on Risk Management: The Spiral Model places a
strong emphasis on risk management, which helps to
minimize the impact of uncertainty and risk on the software
development process.
• Improved Communication: The Spiral Model provides for
regular evaluations and reviews, which can improve
communication between the customer and the
development team.
• Improved Quality: The Spiral Model allows for multiple
iterations of the software development process, which can
result in improved software quality and reliability.

31. Disadvantages of the Spiral Model
• Complex: The Spiral Model is much more complex than other
SDLC models.
• Expensive: Spiral Model is not suitable for small projects as it
is expensive.
• Too much dependability on Risk Analysis: The successful
completion of the project is very much dependent on Risk
Analysis. Without very highly experienced experts, it is going
to be a failure to develop a project using this model.
• Difficulty in time management: As the number of phases is
unknown at the start of the project, time estimation is very
difficult.
• Complexity: The Spiral Model can be complex, as it involves
multiple iterations of the software development process.

32. Disadvantages of the Spiral Model
• Time-Consuming: The Spiral Model can be time-
consuming, as it requires multiple evaluations and
reviews.
• Resource Intensive: The Spiral Model can be resource-
intensive, as it requires a significant investment in
planning, risk analysis, and evaluations.

33. When To Use the Spiral Model?
• When a project is vast in software engineering, a
spiral model is utilized.
• A spiral approach is utilized when frequent releases
are necessary.
• When it is appropriate to create a prototype
• When evaluating risks and costs is crucial
• The spiral approach is beneficial for projects with
moderate to high risk.
• The SDLC’s spiral model is helpful when
requirements are complicated and ambiguous.
• If modifications are possible at any moment
• When committing to a long-term project is
impractical owing to shifting economic priorities.

34. Prototyping Model

35. Prototyping Model
• During Prototyping model, the software
development team, clarify requirements and/or
design elements that generate mockups and
prototypes of screens, reports, and processes.
Although some of the prototypes may appear to be
very substantial, they’re generally similar to a
movie set: everything looks good from the front
but there’s nothing in the back.

36. Prototyping Model
• When a prototype is generated, the developer
produces the minimum amount of code necessary
to clarify the requirements or design elements
under consideration. No effort is made to comply
with coding standards, provide robust error
management, or integrate with other database
tables or modules. As a result, it is generally more
expensive to retrofit a prototype with the
necessary elements to produce a production
module then it is to develop the module from
scratch using the final system design document.

37. Prototyping Model
• For these reasons, prototypes are never
intended for business use, and are generally
crippled in one way or another to prevent them
from being mistakenly used as production
modules by end-users.