Software Engineering and

Testing (SET-315332)
 Highlights
• Teaching Scheme for 5th and 6th Sem.
• Outcome of Polytechnic
• Why software Engineering and Testing
• Teaching and Examination scheme
• Syllabus of ETI
Teaching Scheme for 5th Sem.
 Outcome of Polytechnic
3 year Diploma
in Engineering

Higher JOB
Education (Gov./Private) Entrepreneur
Name of 2025- 2024- 2023 ● Hard Skills
Institute 2026 2025 2024 Hard skills are technical knowledge
● Analytical Skills or training that you have gained
● Soft-Skill through any life experience,
XYZ including in your career or
● Mathematical Reasoning
education
POQ ● Know bout selection Process
Analytical skills refer to the ability
MNO to collect and analyze information,
problem-solve, and make
ABC Soft skills are personal habits and decisions.
traits that shape how you work, on
DEF your own and with others
 Index

Sr. Title Aligned Learning Total Slide

No. COs Hours Marks No.

1. Basic of Software Engineering CO 1 6 12 09

2. Software Requirement, Modeling and Design CO2 10 16 55
3. Software Project Management CO 3 10 16 139
4. Basics of Software Testing CO 4 8 14 157
5. Test and Defect Management CO5 6 12 181
40 70
 Why SET
• INDUSTRY / EMPLOYER EXPECTED OUTCOME
– Apply software engineering principles to develop software product.

• COURSE LEVEL LEARNING OUTCOMES (COS)

– Students will be able to achieve & demonstrate the following COs on completion of course based
learning
● CO1 - Identify relevant software process model for software development.
● CO2 - Use appropriate principles of software modeling to create data design.
● CO3 - Apply project management techniques in software development.
● CO4 - Apply different software testing types to ensure the quality of software product.

● CO5 - Identify defect to improve the overall quality of the software using automated testing tools.
Teaching-Learning & Assessment
Scheme
Unit 01

Basics of Software Engineering

CO1 - Identify relevant software process model for software development.

Theory Learning Outcomes (TLO's)aligned to CO's.

TLO 1.1 Explain different types and characteristics of software.
TLO 1.2 Describe software engineering layered technology and process framework.
TLO 1.3 State software engineering principles for requirement engineering.
TLO 1.4 Select software process model for the given problem statement.
TLO 1.5 Apply agile development process with justification
Ch-01 Basics of Software Engineering

Content
1.1 Software, software engineering as layered approach, characteristics of software, types of
software
1.2 Software development framework: Software generic process framework activities and umbrella
activities
1.3 Software engineering core principles, communication practices, planning practices, modelling
practices, construction practices, software deployment practices
1.4 Prescriptive process models: Waterfall model, incremental model, RAD model, prototyping
model, spiral model
1.5 Agile software development: Agile process, and its importance, extreme programming, scrum
1.6 Selection criteria for software process model
What is Software
Software consists of computer programs that instruct the execution of a computer.
● a set of instructions to acquire the inputs and to manipulate (process) them to produce
the desired output in terms of functions and performance as determined by the user
of the software
● a software is a set of instructions computer programs that when executed provide
desire output performance and functions
● a software can be defined as a set of instruction which when executive computer
except the inputs and after doing the required computation produced output or result
as users requirement
What is Software
Software Includes:
1. Functionality: The software should perform all the operations it was designed to do, fulfilling user and business
requirements.
2. Usability: It should be easy for users to learn, understand, and use the software to accomplish their tasks effectively.
3. Efficiency: The software should optimize the use of resources (time, CPU, memory) and deliver prompt responses.
4. Reliability: The software should perform consistently and predictably without failures or errors under given conditions
and for a specified time period.
5. Dependability: The software should function without failure under specified conditions.
6. Integrity: Data processed and stored by the software should remain accurate, consistent, and unaltered unless
authorized.
7. Portability: The ease with which software can be moved from one platform or environment to another with minimal effort
or modifications.
8. Maintainability: The ease with which a software system or its components can be modified, updated, or fixed with
minimal cost, effort, and time.
9. Acceptability : Software must be accept by the uses for which it was designed.
10. Robustness : it refers to the degree to which the software can keep on functioning in spite of being provided with invalid
data
 Characteristics of Software

1. Software is developed or
engineered; it is not manufactured
in the classical sense.
2. The software doesn’t “wear out.”
3. The software continues to be
custom-built, rather than being
assembled from existing
components.
 Characteristics of Software
1. Software is developed or engineered, not manufactured

● “Think about a car. It is manufactured in a factory, and each car is made on an

assembly line. But software is not like that. We don’t ‘manufacture’ software in

factories. We design it, write code, and test it step by step. That’s why we call it

software engineering.”

Example: WhatsApp was developed once by engineers, and now millions of

copies can be installed without re-building it again.

 Characteristics of Software
2. Software doesn’t wear out
● “If you buy a mobile phone, after a few years its battery and hardware parts wear
out. But does your calculator app or game ‘wear out’? No. Software doesn’t get
old or rusty.”

● “However, sometimes it stops working properly when the environment

changes—for example, if you update your Android version, some old apps might
crash. That is not because the software wore out, but because it was not
updated.”

Example: Old PC games may not run on Windows 11 even though the game itself
has not ‘worn out.
 Characteristics of Software
2. Software doesn’t wear out
 Characteristics of Software
3. Most software is custom-built

● “In hardware, we use ready-made parts like screws, nuts, and bolts. But in
software, we usually write programs from scratch to meet user requirements.”

● “Today, we do use libraries, frameworks, and ready-made components (like

a login module or payment gateway), but still, every software has some part that
is custom-made.”

Example: An e-commerce website might use a ready-made payment system

(PayPal, Razorpay) but the overall design, products, and features are custom-built.
Types/ Categories of Software
 What is Software Engineering

● Software Engineering is the systematic approach to the development,

operation, and maintenance of software.

● It applies engineering principles (planning, designing, testing, managing) to

build reliable, efficient, and cost-effective software.

“Software Engineering is the application of engineering methods to develop high-

quality software in a systematic way.
 What is Software Engineering
Definitions of Software Engineering

1. IEEE Definition (1993):

Software Engineering is the application of a systematic, disciplined, and quantifiable approach to the development,
operation, and maintenance of software.

2. Fritz Bauer (1969):

Software Engineering is the establishment and use of sound engineering principles to obtain economically software that
is reliable and works efficiently on real machines.

3. Ian Sommerville:
Software Engineering is an engineering discipline concerned with all aspects of software production – from the early
stages of specification through to maintaining the system after it has gone into use.

4. Pressman:
Software Engineering is a layered technology and a process of analyzing user requirements, designing, building, and
testing software to satisfy those requirements.

5. General Simple Definition (for students):

Software Engineering is the process of designing, developing, testing, and maintaining software by applying engineering
principles in a systematic way.
 What is Software Engineering

“All definitions say the same thing in different words –

Software Engineering = Systematic + Engineering Principles + Reliable & Efficient Software.”

“Programming is like cooking for yourself at home. Software Engineering is like

running a big restaurant – you need recipes, planning, teamwork, quality checks,
and customer service.”
 Software Engineering (Layered Approach)
● Software Engineering follows a layered approach where each layer builds on
the foundation of the previous one.

● The layers are related and each layer demands the fulfillment of the previous
layer

● The layers technology approach ensures well designed software product

 Software Engineering (Layered Approach)
3. Methods Layer
1. Quality Focus (Core Layer)
● Provides technical methods for software
● At the very core, software engineering emphasizes development.
quality.
● Includes:
○ Requirement analysis
● Every activity (requirement, design, coding,
○ Design techniques (UML, DFD, ER diagrams)
testing, maintenance) must ensure high quality
○ Coding standards
software.
○ Testing methods
● Quality acts as the foundation of all layers. 4. Tools Layer (Top Layer)
2. Process Layer ● Provides automated or semi-automated support
for methods and process.
● Defines the framework for software development.
● Examples:
● Provides a set of activities(Key Process Areas- ○ CASE tools (Rational Rose, Enterprise
KPA) (planning, managing, monitoring) that guide Architect)
how software is built. ○ IDEs (Eclipse, Visual Studio, IntelliJ)
○ Testing tools (Selenium, JUnit)
● Examples: Waterfall, Agile, Spiral, Incremental ○ Version control (GitHub, GitLab)
models.
Software Engineering (Layered Approach)
 Software Process & Process Framework

A Software Process is a structured set of activities and associated results that are
followed to develop, operate, and maintain software. In simple terms, it’s the method
or approach used to create software systematically.

It ensures that software is delivered on time, within budget, and meets the required
quality.

A Software Process Framework is a generic structure that defines the basic set of
activities, tasks, and workflows that are common to all software development
processes.

It provides a blueprint for managing software projects and ensures that software is
 Software Development Framework

Generic Process Framework:

A generic software process framework is a set of fundamental activities that

are common to all software development projects, regardless of size, domain, or
methodology.
These activities form the backbone of any software development process.
A generic process framework for software engineering defines five framework
activities—
Communication, Planning, Modeling, Construction, and Deployment.
 Software Development Framework
1. Communication (Requirement Gathering)
○ Understanding what the client wants.
○ Activities include meetings, interviews, and requirement analysis.
○ Output: Software Requirements Specification (SRS)
2. Planning
○ Creating a roadmap for the project.
○ Activities include estimating cost, effort, resources, and scheduling.
○ Output: Project Plan / Work Breakdown Structure
3. Modeling / Analysis and Design
○ Understanding and modeling the software solution.
○ Activities include data modeling, architectural design, and UI design.
○ Output: Design Documents (Architectural, Detailed Design)
 Software Development Framework
4. Construction (Implementation / Coding)

○ Writing the actual code.

○ Activities: coding, debugging, unit testing.
○ Output: Working Software / Modules

5. Deployment (Release & Maintenance)

○ Delivering the software to the client and supporting it.

○ Activities: installation, user training, maintenance, bug fixes.
○ Output: Deployed Software and Updates

These activities are complemented by a number of Umbrella activities

Umbrella activities
 Umbrella activities
These are activities that support and span across all the fundamental activities. They are not tied to a
single phase but are ongoing throughout the software development life cycle.

1. Software project tracking and control—allows the software team to assess progress against the
project plan and take any necessary action to maintain the schedule.

2. Risk management—assesses risks that may affect the outcome of the project or the quality of the
product.

3. Software quality assurance—defines and conducts the activities required to ensure software
quality.

4. Formal Technical reviews—assesses software engineering work products in an effort to uncover

and remove errors before they are propagated to the next activity.
 Umbrella activities
5. Measurement—defines and collects process, project, and product measures that assist the team
in delivering software that meets stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.

6. Software configuration management—manages the effects of change throughout the software

process.

7. Reusability management—defines criteria for work product reuse (including software

components) and establishes mechanisms to achieve reusable components.

8. Work product preparation and production—encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.

Umbrella activities run in parallel with all stages of software development. They don’t produce the
final product directly but ensure the product is high-quality, safe, and maintainable.
1.3 Software engineering core Principles, Communication
Practices, Planning Practices, Modelling Practices, Construction
Practices, Software Deployment Practices
● The dictionary defines the word Principle as “an important underlying law or
assumption required in a system of thought.”
● Software engineering principles are fundamental guidelines that helps
developers design, develop, and maintain high-quality software systems. These
principles ensure that software is efficient, scalable, maintainable and meets
user requirements
● Software Engineering Practices are a set of guidelines, methodologies, and
principles that ensure the development of high-quality, maintainable, and
efficient software.
 Software engineering core principles

The 7 principles can be remembered as:

1. Reason it exists → Focus on customer value

2. KISS → Keep it simple

3. Maintain the vision → Clear purpose

4. What you Produce, Others will consume → Write clean & understandable code

5. Be open to future → Flexible design

6. Plan for reuse → Build reusable components

Communication Practices
● Principle 1. Listen carefully.
● Principle 2. Prepare before you communicate.
● Principle 3. Someone should facilitate the activity.
● Principle 4. Face-to-face communication is best.
● Principle 5. Take notes and document decisions.
● Principle 6. Strive for collaboration.
● Principle 7. Stay focused; modularize your discussion.
● Principle 8. If something is unclear, draw a picture.
● Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree to
something, move on. (c) If a feature or function is unclear and cannot be clarified at
the moment, move on.
● Principle 10. Negotiation is not a contest or a game.
 Software Engineering Planning Practices

Principle 1. Understand the scope of the project.

Principle 2. Involve stakeholders in the planning activity.
Principle 3. Recognize that planning is iterative
Principle 4. Estimate based on what you know.
Principle 5. Consider risk as you define the plan.
Principle 6. Be realistic.
Principle 7. Adjust granularity as you define the plan.
Principle 8. Define how you intend to ensure quality
Principle 9. Describe how you intend to accommodate change.
Principle 10. Track the plan frequently and make adjustments as required.
 Design Modeling Principles
Principle 1. Design should be traceable to the requirements model.
Principle 2. Always consider the architecture of the system to be built.
Principle 3. Design of data is as important as design of processing functions.
Principle 4. Interfaces (both internal and external) must be designed with care.
Principle 5. User interface design should be tuned to the needs of the end user.
Principle 6. Component-level design should be functionally independent.
Principle 7. Components should be loosely coupled to one another and to the
external environment
Principle 8. Design representations (models) should be easily understandable.
Principle 9. The design should be developed iteratively.
 Software Engineering Construction Practices
Coding Principles:
The principles that guide the coding task are closely aligned with programming
style, programming languages, and programming methods.
However, there are a number of fundamental principles that can be stated:
Preparation principles: Before you write one line of code, be sure you
• Understand of the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of the software to be built
and the environment in which it will operate.
• Select a programming environment that provides tools that will make your work
easier.
• Create a set of unit tests that will be applied once the component you code is
completed.
 Software Engineering Construction Practices
Programming principles:
As you begin writing code, be sure you
• Constrain your algorithms by following structured programming practice.
• Consider the use of pair programming.
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and blank lines) that aids understanding.
Software Engineering Construction Practices

Validation Principles:

After you’ve completed your first coding pass, be sure you

• Conduct a code walkthrough when appropriate.

• Perform unit tests and correct errors you’ve uncovered.

• Re factor the code. Refactoring

The authorisofthe theprocess of restructuring
code presents it to theexisting
team, code
without changing
explaining its external
its logic and flow,behavior or functionality
while other to
team members
improve readability, maintainability, and structure.
ask questions and provide feedback to identify errors
Common refactoring techniques include renaming
and foster collaboration. Code walkthroughs are
variables and methods, breaking down large methods,
particularly useful for complex code, new team
removing duplicate code, and extracting common
members, and
functionality into to
new ensure common
methods understanding of the
or classes.
codebase.
 Software Engineering Testing Practices

In a classic book on software testing, Glen Myers states a number of rules that can

serve well as testing objectives:

• Testing is a process of executing a program with the intent of finding an error.

• A good test case is one that has a high probability of finding an as-yet-

undiscovered error.

• A successful test is one that uncovers an as-yet-undiscovered error.

Software Engineering Testing Practices

Principle 1. All tests should be traceable to customer requirements.

Principle 2. Tests should be planned long before testing begins.

Principle 3. The Pareto principle applies to software testing.

Principle 4. Testing should begin “in the small” and progress toward testing “in

the large.”

Principle 5. Exhaustive testing is not possible.

In testing,
The numberthe Pareto
of path Principle (or 80/20 for
permutations rule)even
states
a that approximately
80% of software defects are concentrated in 20% of the application's
moderately sized program is exceptionally large.
code or features. Testers use this principle to prioritize their efforts,
For this reason, it is impossible to execute every combination
focusing on the "vital few" modules or features that are most likely to
of paths
contain theduring
majoritytesting.
of the bugs
Software Engineering Deployment Practices

Principle 1. Customer expectations for the software must be managed.

Principle 2. A complete delivery package should be assembled and tested.

Principle 3. A support regime must be established before the software is

delivered.

Principle 4. Appropriate instructional materials must be provided to end users.

Principle 5. Buggy software should be fixed first, delivered later.

 1.4 Prescriptive process models: Waterfall
Model, Incremental Model, RAD Model,
Prototyping model, Spiral Model
● The process model is an abstraction of the software development process.
● Software Process Models are systematic methods for controlling and
coordinating the development of a software product achieving all the stated
objectives or goals
● A framework containing the process, activities and task involved in the
development operation and maintenance of the software product, spanning the
life of the system from the definition of its requirements to the termination of its
uses.
● A process model is blueprint of how to organise, implement, conduct and
manage software engineering processes in an organisation with an established,
validated, and proven process system and good practices
 Prescriptive Process Models

● Prescriptive process models are traditional software development models that

follow a structured and well-defined sequence of steps.
● Prescriptive process models provide a structured, step-by-step roadmap for
software development, emphasizing defined phases, activities, and deliverables
in a specific order to ensure order and quality
● Prescriptive process models provide structured approaches to software
development.
● While they ensure discipline and organization, they may not always be flexible
enough for modern, rapidly changing projects
Prescriptive Process Models
➢ A linear process flow
executes each of the five
framework activities in sequence,
beginning with communication and
culminating with deployment
➢ An iterative process flow
repeats one or more of the
activities before proceeding to the
next
➢ An evolutionary process flow
executes the activities in a
“circular” manner.
➢ A parallel process flow
executes one or more activities in
parallel with other activities.
 Waterfall Model

● Introduced by Winston W. Royce in 1970.

● The waterfall model is a traditional, linear-sequential software development
process where each phase flows sequentially into the next, with no overlap, and
● Each phase must be completed before the subsequent one begins.
● This model includes phases like Requirements Gathering, System Design,
Implementation, Testing, Deployment, and Maintenance.
● It is suitable for projects with fixed, unchanging requirements, such as small or
simple projects, but is inflexible and does not allow for changes or feedback once
a phase is completed.
Waterfall Model
 Waterfall Model

Advantages:
• Simple and easy to understand and use.
• Works well for smaller projects with clear, fixed requirements.
• Easy to manage due to its rigidity (each phase has specific deliverables).

Disadvantages:
• Inflexible to changes: hard to go back to a previous phase.
• Poor model for long-term or complex projects.
• Late discovery of issues (testing happens after implementation).
• Limited customer involvement once requirements are finalized.
 Incremental Model

● It developed by Harlan Mills et al., in 1980

● The incremental model in software engineering builds a system in small,

manageable parts called increments rather than all at once.

● Each increment represents a working piece of software that is built, tested, and
delivered incrementally, adding new features and functionality with each release
until the complete system is finished.

● This phased approach allows for early delivery of functional software, provides
opportunities for early user feedback, and makes it easier to adapt to changing
requirements.
Incremental Model
 Incremental Model
Each following increment repeats all the same phases
• New features are planned, designed, built, and deployed.
• These increments are integrated with previous ones to enhance the software.
• Each delivery improves overall functionality.
Advantages:
• Delivers working software early and frequently.
• Easier to test and debug smaller increments.
• Flexible: easier to accommodate changes in requirements. •
Customers can provide feedback after each increment.
Disadvantages:
• Needs good planning and design upfront to define increments well.
• Integration of increments can be complex.
• Total cost may be higher than using the waterfall model for simple projects.
RAD Model
● IBM first proposed the Rapid Application Development or RAD Model in the
1980s.
● The RAD model is used when the requirements are fully understood and the
component-based construction approach is adopted.
● Various phases in RAD are Requirements Gathering, Analysis and Planning,
Design, Build or Construction, and finally Deployment.
● The important feature of RAD Model is increased involvement of user customer
at all stage of life cycle through the use of powerful development tool
● The RAD Model is a high speed adaptation of waterfall model in which Rapid
development is achieved by using a component-based construction approach.
● This model distribute the analysis design built and taste phases into a series of
short iterative development cycles
RAD Model
 RAD Model
Advantages of Rapid Application Development Model (RAD)
● The use of reusable components helps to reduce the cycle time of the project.
● Feedback from the customer is available at the initial stages.
● Reduced costs as fewer developers are required.
● The use of powerful development tools results in better quality products in
comparatively shorter periods.
● The progress and development of the project can be measured through the
various stages.
● It is easier to accommodate changing requirements due to the short iteration
time spans.
● Productivity may be quickly boosted with a lower number of employees.
 RAD Model
Disadvantages of Rapid application development model (RAD)
● The use of powerful and efficient tools requires highly skilled professionals.
● The absence of reusable components can lead to the failure of the project.
● The team leader must work closely with the developers and customers to
close the project on time.
● The systems which cannot be modularized suitably cannot use this model.
● Customer involvement is required throughout the life cycle.
● It is not meant for small-scale projects as in such cases, the cost of using
automated tools and techniques may exceed the entire budget of the project.
● Not every application can be used with RAD
Unit 02

Software Requirement, Modeling and Design

CO2 - Use appropriate principles of software modeling to create data design.

Theory Learning Outcomes (TLO's)aligned to CO's.
TLO 2.1 Determine requirement engineering tasks in the given problem.
TLO 2.2 Prepare use case diagram for given scenario.
TLO 2.3 Prepare SRS for the given problem.
TLO 2.4 Convert analysis model into requirement model.
TLO 2.5 Apply the specified design feature for requirements software modeling.
TLO 2.6 Represent the specified problem in the given design notation.
 Ch-02 Software Requirement,
Modeling and Design
Content
2.1 Requirement engineering: Requirement engineering task, types of requirement,
developing use-case
2.2 SRS (Software Requirements Specifications): Need of SRS, format and it's
characteristics
2.3 Translating requirement model into design model
2.4 Design modelling: Fundamental design concepts - abstraction, information
hiding, patterns, modularity, concurrency, verification, aesthetics
2.5 Design notations: Data flow diagram (DFD), structured flowcharts
Unit 03

Software Project Management

CO3 - Apply project management techniques in software development.

Theory Learning Outcomes (TLO's)aligned to CO's.

TLO 3.1 Explain 4 P's of management spectrum.
TLO 3.2 Estimate the size of the software product using the given method.
TLO 3.3 Evaluate the cost of the given software using COCOMO model.
TLO 3.4 Describe the RMMM strategy for the given problem.
TLO 3.5 Use various scheduling techniques for the given project.
TLO 3.6 Prepare the Timeline chart / Gantt chart to track progress of the given project
Ch-03 Software Project Management

Content
3.1 The management spectrum- 4P's
3.2 Metrics for size estimation: Line of code (LoC), function points(FP)
3.3 Project cost estimation using COCOMO (Constructive Cost Model), COCOMO II
3.4 Define risk, types of risk, RMMM strategy
3.5 Project scheduling: Basic principle, scheduling techniques - CPM, PERT
3.6 Project tracking: Timeline charts, Gantt charts
Unit 04

Basics of Software Testing

CO4 - Apply different software testing types to ensure the quality of software
product.
Theory Learning Outcomes (TLO's)aligned to CO's.
TLO 4.1 State the importance of software testing.
TLO 4.2 Identify errors and bugs in the program.
TLO 4.3 Prepare test case for the application.
TLO 4.4 Identify the entry and exit criteria for the given test application.
TLO 4.5 Describe features of the given software quality evaluation standard.
TLO 4.6 Explain V model for the given application.
TLO 4.7 Describe features of the given testing method.
TLO 4.8 Apply specified testing levels for the given application.
Ch-04 Basics of Software Testing
Content
4.1 Software testing, objective of testing, software testing life cycle (STLC)
4.2 Failure, fault, error, defect, bug terminology
4.3 Test case, when to start and stop testing
4.4 Quality assurance, quality control and verification - validation, Quality
evaluation standards: Six sigma, CMMI levels
4.5 Static and dynamic testing
4.6 The box approaches: Compare white box testing, black box testing
4.7 Levels of testing: Unit testing, integration testing, system testing, acceptance
testing
Unit 05

Test and Defect Management

CO5 - Identify defect to improve the overall quality of the software using
automated testing tools.
Theory Learning Outcomes (TLO's)aligned to CO's.
TLO 5.1 Prepare test plan for the given application.
TLO 5.2 Identify the resource requirement for test infrastructure management.
TLO 5.3 Prepare test report of executed test cases for given application.
TLO 5.4 Apply defect life cycle.
TLO 5.5 Prepare defect report for identified defect for AUT.
TLO 5.6 Compare automation and manual testing based on various parameters.
TLO 5.7 Describe metrics and measurement for the given application.
Ch-05 Test and Defect Management
Content
5.1 Test planning: Preparing a test plan
5.2 Test management: Test infrastructure management
5.3 Test reporting: Executing test cases, preparing test summary report
5.4 Definition and types of defect, defect life cycle, defect template
5.5 Comparison of manual testing and automation testing
5.6 Metrics and measurement: Types of metrics - product metrics and process metrics
Thank You…!
Get in Touch
AISSMS Polytechnic
Kennedy Road, Near R.T.O.,
Pune - 411 001, Maharashtra (INDIA)
www.aissmspoly.org.in

png-clipart-icon-logo-twitter-logo-twitter-logo-blue-social-media-thumbnail.pn
52-524733_transparent-background-facebook-icon-png-png-download.png
circle-instagram-logo-media-network-new-social-icon-instagram-logo-circle-p
72-729738_youtube-red-circle-circle-youtube-logo-png-clipart.png
57-571935_linkedin-icon-vector-png-linkedin-circle-logo-tran
/ AISSMS_POLY