0% found this document useful (0 votes)
4 views

UNIT I Software Testing

Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

UNIT I Software Testing

Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

Software Testing

UNIT I
Unit 1

• Principles of Testing – Phases of a Software Project – Life


Cycle Models
Context of testing in Producing
Software
• Software helps h/w to do work a per the wishes of the
user
• Literally everything nowadays has a s/w element in it
• TV, fridge, wash machine, A/C, offices spaces all deal
with some sort of software
• In the above mentioned examples a s/w failure will only
harm a vendors reputation
• But in machine critical application this can be
catastrophic
Context of testing in Producing
Software (Cont…)
• A s/w failure is when the piece of s/w code is not doing
what it is supposed to do.
• S/W failure cannot be avoided at all cost
• A typical s/w that comes has 99.9 defects that can be
fixed and 0.1% remain outstanding
Relationship of effectiveness of testing
to quality of other phases
Principles of Software Testing

1. The goal of testing is to find defects before customers


find them out.
2. Exhaustive testing is not possible; program testing can
only show the presence of defects, never their
absence.
3. Testing applies all through the software life cycle and
is not an end-of-cycle activity.
4. Understand the reason behind the test.
5. Test the tests first.
Principles of Software Testing (Cont…)

6. Tests develop immunity and have to be revised constantly.


7. Defects occur in convoys or clusters, and testing should focus
on these convoys.
8. Testing encompasses defect prevention.
9. Testing is a fine balance of defect prevention and defect
detection.
10.Intelligent and well-planned automation is key to realizing the
benefits of testing.
11.Testing requires talented, committed people who believe in
themselvesand work in teams.
Point to be considered “Why Test”

• Testing should focus on finding defects before customer


detects it
• Dijkstra’s algorithm. – impossible to test all combinations.
• Testing can show presence of errors and not the absence
of the same
• Steps in a process increase the number errors in incurred
during each step and passed to the other progressively
• What one tests is as important as what to test and how to
test
Point to be considered “Why Test”

• You have to constantly revise testing methods to tackle


new age problems
• Prevention is better than cure
Phases of
Software Project
TOPIC 2
Phases of Software Project

• Requirements gathering and analysis


• Planning Design
• Development or coding
• Testing
• Deployment and maintenance
Life Cycle Models

• Waterfall Model
• Prototyping and Rapid Application Development Model
• Spiral or Iterative Model
• The V Model
• Modified V Model
Waterfall Model
Waterfall Model - Advantages

• Simple and easy to understand and use


• Easy to manage due to the rigidity of the 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.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Waterfall Model - Disadvantages

• No working software is produced until late during the life cycle.


• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to
high risk of changing. So, risk and uncertainty is high with this
process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
Waterfall Model - Applications

• Requirements are very well documented, clear and


fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to
support the product.
• The project is short.
Prototyping and Rapid Application
Development Models
• The RAD (Rapid Application Development) model is based
on prototyping and iterative development with no specific
planning involved.
• It uses minimal planning in favor of rapid prototyping.
• A prototype is a working model that is functionally equivalent to
a component of the product.
Prototyping and Rapid Application
Development Models
RAD Model - Application

• RAD model can be applied successfully to the projects in which clear


modularization is possible. If the project cannot be broken into modules,
RAD may fail.
• The following pointers describe the typical scenarios where RAD can be
used −
• RAD should be used only when a system can be modularized to be delivered in an
incremental manner.
• It should be used if there is a high availability of designers for Modelling.
• It should be used only if the budget permits use of automated code generating tools.
• RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.
• Should be used where the requirements change during the project and working
prototypes are to be presented to customer in small iterations of 2-3 months.
RAD Model - Advantage

• Changing requirements can be accommodated.


• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
RAD Model - Disadvantage

• Dependency on technically strong team members for identifying business


requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on Modelling skills.
• Inapplicable to cheaper projects as cost of Modelling and automated code
generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.
Spiral Model
Spiral Model - Applications

• When there is a budget constraint and risk evaluation is important.


• For medium to high-risk projects.
• Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough
customer feedback.
• Significant changes are expected in the product during the
development cycle.
Spiral Model - Advantages

• Changing requirements can be accommodated.


• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the
risky parts can be developed earlier which helps in
better risk management.
Spiral Model - Disadvantages

• Management is more complex.


• End of the project may not be known early.
• Not suitable for small or low risk projects and could be
expensive for small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive
documentation.
V- Model
V- Model Application

• Requirements are well defined, clearly documented and


fixed.
• Product definition is stable.
• Technology is not dynamic and is well understood by the
project team.
• There are no ambiguous or undefined requirements.
• The project is short.
V- Model Advantage

• This is a highly-disciplined model and Phases are


completed one at a time.
• Works well for smaller projects where requirements are
very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each
phase has specific deliverables and a review process.
V- Model Disadvantage

• High risk and uncertainty.


• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a
moderate to high risk of changing.
• Once an application is in the testing stage, it is difficult to go
back and change a functionality.
• No working software is produced until late during the life
cycle.

You might also like