Path testing

Path testing is created by the tom mccabe an America se in

1976.
Path testing is the foundational to the white box testing that
create the test and ensure the unique paths are checked.
Its goal to ensure all possible paths are tested.

CFG control flow graph

Its converts the code into the graphical representation which is
called control flow diagram.
Its has nodes and edge
(explain what is nodes and edges)

Independent path.
It is the unique way to find out the new paths which is not
covered in previous path.
Its least mange to find one new path.
Its goal is to cover the entire CFG with new independent paths.

Cyclomatic complexity path.

Cyclomatic path is used to measure the how program is
complicated.
And tells as how many different paths are need to test.
V=n–e+2

PROCESS OF TESTING
identify the CFG.
List out the edges and nodes.
Calculate the v = n –e + 2
And answer will come.

2. DESIGN CONCEPT
Design concepts are important in software engineering because
they give a structure to how we think about building a software
system. In Software Engineering: A Practitioner's Approach by
Roger S. Pressman, several key design concepts are outlined,
especially in the newer editions. These concepts help create
software that is easier to understand, modify, and expand. Here
are the main design concepts, simplified:

1. Abstraction
Abstraction is about focusing on the important features of
something while ignoring unnecessary details. In software, this
means breaking down complex systems into simpler parts, so
we only see what we need at any moment.
For example, when using a mobile app, you don’t need to know
how the app is coded; you just interact with buttons and
features. Abstraction helps to manage complexity.
2. Modularity
Modularity is about dividing a system into smaller parts, or
"modules," which can work independently but together make
up the whole system.
This concept allows each part to be developed and tested
separately, which is useful for handling complex software
systems. For instance, a shopping website can be split into
modules like the shopping cart, product listings, and user
profiles.
3. Encapsulation
Encapsulation is the idea of keeping data and methods
(functions that operate on data) together in a single "unit" and
protecting them from outside interference.
For example, in a program, each module only allows access to
its necessary functions, hiding the rest of its code. This helps to
prevent errors and improves security.
4. Separation of Concerns
This means dividing the software into sections where each
section deals with a specific concern or responsibility.
For example, in a website, one part could manage the
database, another handles user interface, and another controls
the business logic. This way, changes in one part don’t affect
others, making the software easier to maintain.
5. Coupling and Cohesion
Coupling is about how much different modules depend on each
other. Low coupling (less dependency) is preferred because it
makes the software easier to modify.
Cohesion is about how well the tasks within a single module fit
together. High cohesion is preferred because it means that
each module has a clear purpose and is easier to work with.
For example, a weather app could have a module that only
handles the weather data and another that only displays it.
They have high cohesion (they focus on a single task) and low
coupling (they don’t depend too heavily on each other).
6. Refinement
Refinement is a process of improving the design by adding
more details in a step-by-step way. It’s like building from a
rough outline to a finished piece.
For example, first, you might design a basic structure of a
system, like its main parts, and then gradually add details like
features, user interfaces, and databases.
7. Information Hiding
Information hiding is a design approach where each module
hides certain details about how it works from other modules.
For example, a database module in an application may hide its
complex data handling methods from other modules. This
reduces the risk of errors from other parts of the system trying
to change or misuse those details.
8. Functional Independence
Functional independence is a goal where each module can
operate independently of others as much as possible. This is
achieved through high cohesion and low coupling.
Functional independence makes software easier to test,
understand, and reuse because each part works well on its
own.
9. Design for Change
This concept means designing software in a way that it’s easy
to update when new requirements or technologies come up.
For example, using modularity and low coupling allows a
developer to update a payment module on an e-commerce
website without affecting the user interface.
10. Design for Testability
This is about creating software that can be tested easily to
ensure quality.
A good design makes it clear what each part should do, which
helps in writing tests for each part. For example, if each module
has a clear purpose, developers can create tests to check if
each one works correctly.
These concepts guide the design of reliable, maintainable, and
flexible software systems. They also support teamwork, as each
developer can focus on different modules or parts, knowing
how their part connects to the whole system.

Spiral Model in Simple Terms

The Spiral Model is a way to develop software that focuses on
finding and managing risks. It combines elements of the
Waterfall and Iterative models. Each phase in the Spiral Model
starts with a goal and ends with the client reviewing the
progress.

Phases of the Spiral Model

Planning
Estimate cost, time, and resources.
Understand requirements through communication with the
customer.

Risk Analysis
Identify potential risks.
Plan how to handle these risks.

Engineering
Develop and test the software.
Install the software at the customer's site.

Evaluation
Customer reviews the software.
Check for risks like delays and cost overruns.

When to use spiral

Large project
Cost
Frequent changes
Unclear requirements
risk

Advantages
Flexibility
Cost estimation
Systematic development
Risk management
Customer evaluation

Disadvantages
Schedule budget
More documentation
High experience
Strict protocols
Small project

Waterfall model
When to use
Clear requirements
Clear idea
No updates
Simple and better understanding
Understanding the technologies

Advantages
Simple and easy
Easy to mange
Step by step
Customer evaluation
No update

Disavantages
No updates
No reset
Errors occurs
Bad for long term
May not match to new era

Analysis model
The am is used to to understand and collects the requirements
and convert into the specific model. When its collects the
requirements and transform into design and building system.

ERD
Entity relationship diagram
Erd is used to show the relationship between the different
entities.
One-one one-many many-one
+--------------+ +--------------+
| Customer | | Order |
+--------------+ 1 N +--------------+
| -CustomerID | <-------------> | -OrderID |
| -Name | | -OrderDate |
| -Email | | -TotalAmount |
+--------------+ +--------------+
^ |
| |
| v
+--------+---------+ +--------------+
| Book | | Payment |
+------------------+ N 1 +--------------+
| -BookID | <-----------> | -PaymentID |
| -Title | | -Amount |
| -Author | | -PaymentDate |
| -Price | +--------------+
+------------------+

DFD
Data flow diagram is used to represent the data flow, chart,
external entities, store data.
Level 0
+-------------------+
| Customer |
+---------+---------+
|
v
+---------+---------+
| Online Bookstore |
+---------+---------+
|
v
+---------+---------+
| Payment Gateway |
+-------------------+

Level1
+-------------------+
| Customer |
+---------+---------+
|
v
+---------+---------+
| Browse Books |
+---------+---------+
|
v
+---------+---------+
| Place Order |
+---------+---------+
|
v
+---------+---------+
| Confirm Payment |
+-------------------+
 |
v
+-------------------+
| Manage Orders |
+-------------------+

STD
State transition is used to state the process of enities.

Order place -> processing -> order shipping -> processing ->
completed

Explain 4ps in project management

People
Process
Product
Project

types of testing
testing is used to identify the quality, completeness , correction
of the software.
Its ensure the specification , functionality, performance of the
software.
Its test the software in manual or auto in condition positive or
negative.
Testing cycles
Project intiaition
System study
Test plan
Test design
Auto manual
Report defects
Regression test
Analysis
Submit

Test plan
Testing planning is used plan the testing. It has detail about it
Test cases
Its specific test case.

Different types of testing

1.Unit testing
Definitions
Testing the individual components like function , modules are in
system.
Purpose
Ensures the components parts are working
Ex:

2. Integrating test
Definitions
This testing is used to test different paths of software.
Purpose
To check is all the parts are working together.
Types
Top-down integration testing. Its start from top and down
modules will add on.
Bottom-up integration testing. Its start from bottom and up
modules will add on.
Big bang integration testing. mix
Mix up integration testing. Work at same time

3. Unit testing
Unit testing is used to test the entire software.
Its ensure the every parts of program are working
Ex: shopping cart.

4. Acceptance testing
This testing is used to check is the software has the user
requirements clearly.
Its determine by customer
Alpha testing. Its done within the developer organization
Beta testing. Its done between friends, customers.

5. regression testing. Is new updates are effecting the software.

(matching)
6.Performs testing – stress testing, load testing, soak testing.
7.Security testing.
8. usability testing.

SOFTWARE MYTHS
Myths means
In software myths means

Mangament myths . A wrong belief by mangers in software

industries.
Customer myths. A wrong belief by user who is going to buy
software.
Developer myths. A wrong belief by developer who going to
develop the software.

MM
Book
Last moment adding new employes.
Latest computers.

CM
Simple idea
Changes whenever you want
No changes after developing software.

DM
Code is important
Once the software is complete our job is done.
Only success is to working of software.
(note the increment process model is rad model and
increment model and evolutionary process model is
protyping and spiral model)

Prototyping
Means a template or sample for better understanding for
customer.

Refer the question in note

Advantages.
Customer has great satisfaction because of revaluating.
Changes can be done
Code can be reused
Easy findout missing

Disadvantages
Costly
Poor documentation as changes occurs
Complexity
Not satisfied
Demand may be changes.

SOFTWARE ENGINEEERING ROLES

1. Understanding Requirements: System engineers gather and
understand the full requirements of the project, including
hardware, software, and user needs. They look at the project as
a whole to make sure all parts fit together.

2. Designing the System: They design the high-level structure

of the system, defining how each component will interact and
work together. This includes planning both software and
hardware components.

3. Coordination and Communication: System engineers act as a

bridge between different teams (software, hardware, network)
to ensure smooth communication and coordination. They make
sure that everyone works towards the same goals.

4. Ensuring Quality and Safety: They ensure the system is

reliable, secure, and meets quality standards. This includes
testing and verifying that each part of the system functions
properly.

5. Problem Solving and Support: Throughout the project,

system engineers solve any technical problems that come up
and support the team in adapting the system to any new
requirements or issues.

Introduction to Eliciting Requirements

In software development, eliciting requirements means
gathering detailed information about what the software should
do. This step is one of the first and most important in creating
software because it ensures that the final product meets the
needs of the people who will use it.
The process of eliciting requirements involves talking to people
like users, clients, and anyone else who has an interest in the
software, known as stakeholders. By understanding their
needs, we can design software that matches what they expect.

Steps in Eliciting Requirements

1 Identify Stakeholders
First, we identify all the people involved with the project. These
are the stakeholders—people like end users, clients, managers,
or anyone who cares about the project. Knowing who they are
helps us understand who will be affected by the software.

2 Gather Information from Stakeholders

After identifying stakeholders, we gather information about
their needs using several techniques:
Interviews: Asking questions directly to the people involved to
get detailed answers.
Questionnaires and Surveys: Sending out questions to get
feedback from a larger group of people.
Workshops: Holding group discussions where stakeholders can
talk about their needs.
Observation: Watching users interact with any current system
to understand what improvements are needed.
3. Define and Organize Requirements
Once we collect information, we organize it into two types:
Functional Requirements: These are specific features or actions
that the software should perform (like processing payments or
tracking orders).
Non-Functional Requirements: These describe qualities the
software should have, such as being fast, secure, or easy to
use.
4.Resolve Conflicts Between Requirements
Sometimes, stakeholders have different ideas about what the
software should do, which can lead to conflicts. We work to
balance these different needs so that the software meets the
main goals.

5.Use Prototyping and Models

Building a simple model or prototype of the system helps
stakeholders understand how the software will look and work,
allowing them to give better feedback.

6. Document Requirements
Finally, we write down all the gathered information in a
document called the Software Requirements Specification
(SRS). This document clearly describes what the software
needs to do, serving as a guide for developers.

Summary
In short, eliciting requirements is about collecting and
organizing information about what the software should do. This
helps to ensure that the final product meets the needs of the
users and stakeholders, leading to a successful project

Components of a Design Model

1. Data Design:
o Converts information from the analysis model into data structures
needed for software implementation.
2. Architectural Design:
o Defines the relationships among major components of the software.
3. Interface Design:
o Describes how the software interacts with other systems and users.
4. Procedural Design:
o Converts the architecture's structural elements into detailed
descriptions of software components.
 +---------------------------+-------------------------------+
| Testing | Debugging |
+---------------------------+-------------------------------+
| 1. Finds bugs and errors. | 1. Fixes bugs and errors. |
| 2. Done throughout | 2. Done after testing finds |
| development. | issues. |
| 3. Performed by testers. | 3. Performed by developers. |
| 4. Checks the entire | 4. Focuses on specific parts |
| system or parts. | of the code. |
| 5. Can be automated with | 5. Generally a manual process.|
 | tools. | |
| 6. Ensures software works | 6. Corrects the code to work |
| as expected. | properly. |
| 7. Identifies bugs that | 7. Fixes bugs and errors in |
| need fixing. | the code. |
| 8. Involves creating test | 8. Keeps logs and notes about |
| plans and reports. | fixes. |
| 9. Validates software | 9. Modifies code to eliminate |
| meets requirements. | issues. |
| 10. Includes unit, | 10. Involves identifying, |
| integration, system, | analyzing, and fixing |
| acceptance testing. | problems. |
+---------------------------+-------------------------------+

introduction
In software design, the user interface (UI) is crucial because it’s how users
interact with the software. Roger Pressman introduced three "golden
rules" for creating user-friendly interfaces that improve usability and
make the experience smoother and more enjoyable. These rules help
designers focus on the user’s needs and create software that’s easy to
understand and navigate.

Here are the three golden rules:

1. Place the User in Control
Main Idea: The user should feel in charge of the software, not controlled
by it.
How to Do This:
Give Choices: Let users choose options, change settings, and go back if
they make mistakes.
Prevent Errors: Make it easy for users to use the software without getting
lost or making errors.
Allow Exploration: Users should feel safe trying out features without the
fear of causing permanent mistakes.

2. Reduce the User’s Memory Load

Main Idea: Don’t make users remember too much while using the
software.
How to Do This:
Keep Information Visible: Show important information so users don’t have
to remember it.
Use Simple Words and Symbols: Choose terms and icons that are easy to
understand.
Guide Users: For complicated tasks, help users with step-by-step
instructions.
3. Make the Interface Consistent
Main Idea: Make the software work and look the same throughout.
How to Do This:
Use the Same Design Everywhere: Keep colors, fonts, and buttons the
same across the app.
Standardize Navigation: Make menus and options appear in the same
places on every screen.
Follow Common Standards: Use familiar designs and layouts for the
platform (like Windows, iOS) so users feel comfortable
What is an Empirical Estimation Model?
Empirical estimation models are used to predict how much
time, effort, or money a software project will need. These
models are based on data from past projects. They use facts
and numbers from previous software projects to make
predictions about new ones.

How Do They Work?

Use Data from Past Projects: These models look at completed
projects and gather information about how long they took, how
many people worked on them, and how big the projects were.

Make Predictions for New Projects: After looking at the past

data, the model tries to predict how long or how much effort a
new project will take, based on how similar it is to the past
projects.

Types of Empirical Estimation Models:

COCOMO (Constructive Cost Model):

What it does: This model uses the size of the software (usually
measured by lines of code) to predict how much effort is
needed.
Example: If you know how many lines of code you’ll write,
COCOMO can predict how many people (and how much time)
will be needed to finish the project.
It has a formula, like:
Effort=𝑎×(KLOC)𝑏
Effort=a×(KLOC) b
Where KLOC is the number of lines of code (in thousands), and
"a" and "b" are numbers based on the project type.
Function Point Analysis (FPA):
What it does: Instead of measuring software by the number of
lines of code, FPA counts the features or functions the software
needs to have. The more features, the bigger the software.
Example: The model gives points to things like inputs, outputs,
and files the software needs to use. More points means a
bigger project, which takes more time.

Why Are These Models Useful?

Real Data: They use information from past projects, which
makes them practical and grounded in reality.
Quick Estimates: Once you have the model set up, you can
quickly estimate how much time and effort a new project will
need.

Problems with These Models:

Depends on Good Data: If you don’t have good data from past
projects, the predictions can be wrong.
Not for Unique Projects: If your new project is very different
from past ones, the model might not work well.
Not Always Very Accurate: They give rough estimates, but not
exact answers

Here are 7 key points for each type of testing that you can
easily remember for your exam:

### White Box Testing:

1. **Tests the Code**: Focuses on the internal code and logic.
2. **Requires Coding Knowledge**: Testers need to know how
the code works.
3. **Checks Functions & Logic**: Tests if functions and
conditions work as expected.
4. **Full Code Coverage**: Aims to test every part of the code.
5. **Tests Code Paths**: Ensures all possible paths (e.g., loops,
branches) are covered.
6. **Example**: Checking if a function works for different inputs
(like adding numbers).
7. **Detailed & Time-Consuming**: Needs detailed testing,
which can take time.

### Black Box Testing:

1. **Tests Functionality**: Focuses on how the software
behaves, not the code.
2. **No Coding Knowledge Required**: Testers don’t need to
understand the code.
3. **Checks User Experience**: Tests the software’s user
interface and features.
4. **Based on Requirements**: Tests are based on what the
software is supposed to do.
5. **Focuses on Outputs**: Ensures correct outputs for given
inputs.
6. **Example**: Checking if a login button works correctly when
clicked.
7. **Quick & Simple**: Doesn’t need knowledge of the code and
can be done quickly.

These points are simple and should help you remember the
main differences for your exam.