Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
49 views34 pages

ST Final

Software testing is the evaluation and verification of software applications to ensure they perform as expected, identifying defects and ensuring quality. Key principles include the impossibility of exhaustive testing, the importance of early testing, and the context-dependent nature of testing. The Software Testing Life Cycle (STLC) outlines phases from requirement analysis to test closure, while various SDLC models like Waterfall, V-Model, and Agile guide the software development process.

Uploaded by

Vivek Patil
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
49 views34 pages

ST Final

Software testing is the evaluation and verification of software applications to ensure they perform as expected, identifying defects and ensuring quality. Key principles include the impossibility of exhaustive testing, the importance of early testing, and the context-dependent nature of testing. The Software Testing Life Cycle (STLC) outlines phases from requirement analysis to test closure, while various SDLC models like Waterfall, V-Model, and Agile guide the software development process.

Uploaded by

Vivek Patil
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Q.1 what is software testing.

explain the principles of software testing in deatiled Software


Testing is the process of evaluating and verifying that a software application or system
performs as expected. It helps identify bugs, errors, or missing requirements in the software.
The goal of software testing is to ensure the quality, reliability, and performance of the
product before it is delivered to users.
Principles of Software Testing:
1. Testing shows the presence of defects
Testing can show that defects are present, but it cannot prove that there are no defects.
It helps reduce the probability of undetected defects but does not guarantee a 100% bug-free
system.
2. Exhaustive testing is impossible
It is not practical to test all possible inputs, paths, and scenarios in real-world software.
Therefore, we use techniques like risk-based testing and prioritization to test effectively
within limited time and resources.
3. Early testing saves time and money
Testing activities should start early in the software development lifecycle, such as during
requirement or design phases.
This helps in detecting and fixing defects early, which is cheaper and less time-consuming.
4. Defect clustering
A small number of modules usually contain most of the defects (commonly referred to as the
Pareto Principle: 80% of defects are found in 20% of modules).
This helps testers to focus testing efforts on the most error-prone areas.
5. Pesticide paradox
If the same set of test cases is run repeatedly, they will eventually stop finding new defects.
To overcome this, test cases must be regularly reviewed and updated, and new tests must be
added to find more defects.
6. Testing is context dependent
The type and approach of testing depend on the software being tested.
For example, testing a banking application requires more security testing, while a game
application focuses more on performance and usability.
7. Absence of errors fallacy
Finding and fixing defects does not help if the software does not meet the user’s
requirements.
A bug-free system is useless if it is not usable or does not solve the intended problem.

Q.2 explain the phases of testing software development life cycle model in detailed
The Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the
testing process to ensure software quality. Each phase has specific goals and deliverables.
Testing is not just a single activity—it begins early and is carried out in a systematic way.
Phases of Testing in SDLC (STLC):
1. Requirement Analysis
In this phase, testers study and analyze the requirements documents (SRS, BRS) to
identify what is testable.
Objective: Identify testable requirements, testing scope, and possible risks.
Deliverables: Requirement Traceability Matrix (RTM), automation feasibility report.
2. Test Planning
The test manager prepares a test plan that includes strategy, resources, schedule, and
scope of testing.
Objective: Define objectives, tools, timelines, and responsibilities.
Deliverables: Test Plan Document, Effort Estimation, Test Tool Selection.
3. Test Case Design / Test Development
Based on requirements, testers create detailed test cases and test scripts.
Objective: Create positive and negative test cases, define test data and expected results.
Deliverables: Test cases, Test scripts, Test data.
4. Test Environment Setup
This phase ensures the setup of software and hardware conditions under which testing is
to be performed.
It involves installing servers, networks, databases, tools, etc.
Deliverables: Environment readiness report, smoke test results.
5. Test Execution
Testers run the test cases and compare the actual results with expected results.
Defects are logged in defect tracking tools (e.g., JIRA).
Deliverables: Test Execution Report, Defect Report.
6. Defect Reporting and Tracking
Any deviations from expected results are logged as defects.
Developers fix them, and testers retest and close if resolved.
Deliverables: Updated Defect Log, Defect Status Report.
7. Test Closure
After testing is completed, all testing activities are reviewed and closed.
Includes metrics analysis, documenting lessons learned, and finalizing test deliverables.
Deliverables: Test Summary Report, Test Closure Report, Defect Analysis Report.
Q.3 Compare Validation & Verification
Q.4 explain the software development life cycle and its models each in detailed
The Software Development Life Cycle (SDLC) is a structured process used for developing high-
quality software. It defines phases and activities that take place from the initial idea to the
final deployment and maintenance of the software product. It helps ensure that the software
is delivered on time, within budget, and meets user requirements.
Phases of SDLC:
Requirement Gathering & Analysis: Collect and analyze business needs from
stakeholders. Outputs: Software Requirement Specification (SRS).
System Design: Design system architecture, databases, UI, and modules. Outputs: High-
Level Design (HLD), Low-Level Design (LLD).
Implementation / Coding: Developers write code based on design documents. Tools,
languages, and coding standards are used.
Testing: Testers check the software for defects and bugs. Ensures the software works as
expected.
Deployment: Software is released to the user environment (production). Can be done in
phases or all at once.
Maintenance: Post-deployment updates, bug fixes, and performance improvements.
Ensures long-term success and usability.
SDLC Models:
Waterfall Model: It is the oldest and simplest SDLC model. The process flows in a linear
sequential manner, like a waterfall one phase must be completed before the next begins.
Phases:
Requirements → Design → Implementation → Testing → Deployment → Maintenance
Advantages: Easy to understand and manage, Works well for well-defined projects
Disadvantages: Cannot go back to a previous phase, Not suitable for changing
requirements
Best used for: Small projects with clear and fixed requirements.
V-Model : Also known as the Verification and Validation model, this is an extension of the
waterfall model where each development phase is matched with a testing phase.
Structure:
Left side = Development phases
Right side = Corresponding testing phases
Middle = Coding
Example:
Requirement phase ↔ Acceptance Testing
Design phase ↔ System Testing
Coding ↔ Unit Testing
Advantages: Testing is planned early, Good for safety-critical systems
Disadvantages: Still not flexible for requirement changes, No working software until late
in the cycle
Best used for: Banking, aviation, healthcare software where defects are costly.
Incremental Model: Software is developed in parts or increments. Each increment adds new
functionality and is tested independently.
Process: First, core features are developed → then more features are added in the next
increments.
Advantages: Functional software is delivered early, Easier to manage and test smaller
components
Disadvantages: Requires good planning and design, Integration of increments can be
complex
Best used for: Medium-sized projects where quick delivery is needed.
Spiral Model: Combines the features of both iterative and waterfall models with a focus on
risk analysis. The project passes through repeated cycles (spirals).
Phases in each spiral: Planning → Risk Analysis → Engineering → Evaluation
Advantages: Excellent risk management, Suitable for complex and high-budget projects
Disadvantages: Expensive and complicated, Requires expertise in risk assessment
Best used for: Large-scale, mission-critical systems with high uncertainty.
Agile Model: A flexible and iterative model that promotes frequent releases, customer
collaboration, and continuous feedback.
Key Terms:
Sprints: Time-boxed development cycles (1–4 weeks)
Scrum: A popular Agile framework
Daily Stand-ups: Short meetings to sync team efforts
Advantages: Quick delivery and customer feedback, Flexible to changes in requirements
Disadvantages: Less documentation, Requires experienced developers and continuous
customer involvement
Best used for: Startups, evolving projects, or products with fast-changing requirements.

Q.5 explain white box testing (wbt) in deatiled with example


White Box Testing (WBT), also known as Clear Box, Glass Box, or Structural Testing, is a
software testing technique where the internal structure, logic, and code of the software are
tested. The tester needs knowledge of the source code and programming logic.
Key Features of White Box Testing:
Focuses on code structure, loops, branches, and paths.
Conducted usually by developers or technical testers.
Ensures that all code paths are tested, not just inputs and outputs.
Objectives of White Box Testing:
Verify flow of inputs and outputs through the code.
Check loop conditions, logic paths, and exception handling.
Test decision-making statements (like if, switch).
Ensure complete code coverage (line, branch, path).
Types of White Box Testing Techniques:
Statement Coverage: Checks whether each line of code is executed at least once.
Branch(Decision) Coverage: Ensures that all branches (true/false) in decision points are
tested.
Path Coverage: Tests all possible paths in the code for full coverage.
Condition Coverage: Tests each boolean expression in conditional statements.
Example:
def check_even_odd(num):
if num % 2 == 0:
return "Even"
else:
return "Odd"
Statement Coverage: Ensure both lines inside if and else are executed.
Branch Coverage:
Input num = 4 → checks the if branch.
Input num = 5 → checks the else branch.
Path Coverage: Covers both possible logical paths (even and odd).
Condition Coverage: % operation and comparison must be tested.
Advantages of White Box Testing: Efficient in optimizing code, Helps detect hidden errors and
dead code, Allows for early detection of defects
Disadvantages: Requires programming knowledge, Not suitable for large, complex systems
due to high effort, May miss unimplemented or missing features (since it focuses only on
code)
Q.6 explain black box testing (bbt)in deatiled with example
Black Box Testing (BBT) is a software testing method in which the internal structure or code of
the application is not known to the tester. The tester focuses on inputs and expected outputs,
not how the program arrives at the result. It is also called behavioral testing or functional
testing, and it is done to check functionality, usability, and reliability of the software.
Key Features of Black Box Testing:
Tester is not concerned with the internal code or logic.
Only the functionality of the system is tested.
Performed usually by testers or QA teams, not developers.
Based on requirements and specifications.
Objectives of Black Box Testing:
Verify the software's functionality as per user requirements.
Check how the system responds to valid and invalid inputs.
Ensure correct input-output behavior.
Find missing or incorrect features, interface issues, or performance bugs.
Black Box Testing Techniques:
1. Equivalence Partitioning: Divides input data into valid and invalid partitions. Only
one value from each partition is tested.
2. Boundary Value Analysis (BVA): Tests values at the boundaries of input ranges
(min, max, just inside/outside). Example: For input range 1 to 100, test 0, 1, 100,
101.
3. Decision Table Testing: Creates tables for different input combinations and their
expected outputs.
4. State Transition Testing: Used when software behaves differently based on current
state and input.
5. Error Guessing: Relies on tester’s experience to guess where bugs may exist.
Example:
Let’s say we are testing a login form with the following conditions:
Username and password must be correct to allow login.
Invalid username or password must show an error message.
The tester will:
Enter valid username & password → expect success.
Enter invalid username → expect error.
Leave both fields blank → expect validation message.
Here, the internal code is unknown, only the input and output behavior is tested.
Advantages: No need for programming knowledge, Useful for large systems where internal
logic is complex, Can find missing functionalities, Focuses on user experience
Disadvantages: Cannot test internal logic or structure, Limited coverage (may miss logic-level
bugs), Difficult to design test cases without clear specifications

Q.7 explain static testing & structural testing each in deatiled with example
1. Static Testing
Static Testing is a type of software testing where the code, design documents, or requirements
are reviewed without executing the program. It helps in identifying errors early in the
software development lifecycle. It is also known as verification because it verifies correctness
before the software runs.
Techniques Used:
Reviews – Formal or informal examination of documents (e.g., code review, requirement
review).
Walkthroughs – Developer presents the code or document to the team for feedback.
Inspections – Formal checking of documents by a team with defined roles.
Static Analysis Tools – Automated tools check for code issues like syntax errors, unused
variables, or potential security issues.
Example:
A developer writes code and before running it, the code is reviewed by a senior developer to
find syntax errors, logic issues, or missing conditions.
Or a tester checks the Software Requirement Specification (SRS) document for inconsistencies
before test case creation.
Benefits: Finds defects early, Reduces cost of fixing bugs, Saves time in later testing phases,
No need to execute code
2. Structural Testing (White Box Testing)
Structural Testing focuses on the internal logic and structure of the code. It is a white box
testing technique where the tester checks how the code works internally by designing test
cases based on the code structure. It is part of dynamic testing since it requires code
execution.
Common Techniques:
Statement Coverage – Ensures every line of code is executed at least once.
Branch Coverage – Every decision (if/else) has both true and false tested.
Path Coverage – All possible paths in the control flow are tested.
Condition Coverage – All logical conditions are tested for both true and false.
def check_age(age):
if age >= 18:
return "Adult"
else:
return "Minor"
Structural testing would involve test cases like:
Input 18 → true path
Input 16 → false path
This ensures both branches of the if statement are tested.
Benefits: Helps improve code quality, Finds hidden logic errors, Ensures complete code
coverage

Q.8 explain integration testing & types of integration testing each in detailed
Integration Testing is a type of software testing where individual modules or components are
combined and tested as a group. Its goal is to verify the data flow and interaction between
integrated units/modules. After unit testing (where individual modules are tested separately),
integration testing ensures that modules work together correctly when combined.
Why Integration Testing is Needed:
Individual modules may work correctly in unit testing, but they may fail when interacting
due to issues like: Wrong data passing, Incorrect API usage, Interface mismatch,
Improper error handling
1. Big Bang Integration Testing: All individual modules are integrated simultaneously after unit
testing, and the entire system is tested as a whole.
How it works: No incremental testing. All modules are brought together in one go.
Example: In an e-commerce application, login, cart, and payment modules are developed
separately and tested together in a single step.
Advantages: Simple and saves integration time initially. Good for small systems.
Disadvantages: Difficult to identify the root cause of failure. Bugs are detected late.
Entire system may crash if a critical module fails.
2. Top-Down Integration Testing: Testing starts from the top-level module and progresses downward.
How it works:

The main control module is tested first.

Lower-level modules are replaced with stubs (temporary dummy modules).


Sub-modules are integrated one by one.
Example: Start testing the homepage of an app → then integrate login → then product listing →
then cart.

Advantages: Early detection of high-level design flaws. Major functionalities tested first.

Disadvantages: Requires stubs for unready modules. Low-level utility functions are tested late.
3. Bottom-Up Integration Testing: Testing begins with lowest-level modules and progresses upward.
How it works: Lower modules are tested first. Higher-level modules are integrated and tested step by
step. Drivers (dummy calling modules) are used in place of the main program.
Example: Start testing the database interaction module → then integrate with business logic →
then with UI.
Advantages: Low-level bugs found early. Modules are tested thoroughly before integration.

Disadvantages: Requires drivers for upper modules. Overall system behavior is visible late.

4. Sandwich (Hybrid) Integration Testing: This approach combines Top-Down and Bottom-Up testing.
How it works: Testing is done in both directions simultaneously. Middle layer is tested after both ends
are tested. Requires both stubs and drivers.
Example: UI and database modules are tested separately, and then connected through the
business logic layer.
Advantages: Parallel development and testing possible. Combines benefits of both top-down
and bottom-up.
Disadvantages: Complex to manage. More resource and planning effort required
Q.9 explain scenario testing in detailed
Scenario Testing is a software testing technique where real-world situations or workflows are
used to test the application. The goal is to validate that the system behaves correctly in end-
to-end scenarios, just like how a real user would use it. It focuses on high-level business flows
rather than individual functions or features, making it a useful technique for validating critical
business operations.
Scenario Testing involves creating and executing test cases based on real-life scenarios, which
often include multiple features or modules interacting together. These scenarios are usually
complex, realistic, and meaningful.
Characteristics of Scenario Testing:
1. Based on real user behavior
Scenarios reflect actual usage patterns and business needs.
2. Covers end-to-end flows
Often includes multiple steps across different parts of the system.
3. Involves complex interactions
Useful for testing systems where simple input-output testing isn’t enough.
4. Designed using "what-if" thinking
Testers think like users: "What if the user does this?"
Steps to Perform Scenario Testing:
1. Study the requirements, user stories, and business rules.
2. Identify critical business flows and user behavior.
3. Design scenarios that represent complete user journeys.
4. Write test cases for each scenario.
5. Execute and record results.
Example:
Application: Online shopping website
Scenario: A user logs in, searches for a product, adds it to the cart, applies a discount coupon,
selects a delivery address, pays via UPI, and logs out.
This scenario tests multiple modules: login, search, cart, discount logic, payment
gateway, and logout.
Rather than testing each module separately, the whole real-world flow is tested.
Benefits of Scenario Testing:
✓ Reflects actual user experiences
✓ Helps detect issues across multiple modules
✓ Enhances understanding of the system's business logic
✓ Useful for regression and acceptance testing
Limitations:

✗ Time-consuming to design and maintain


✗ Requires domain knowledge and input from stakeholders
✗ May miss edge cases if only high-level scenarios are tested

Q. 10 explain system scenerio and use case scenerio each in detailed


1. System Scenario: A System Scenario is a high-level end-to-end situation that describes how
a user interacts with the entire system to complete a task or fulfill a business objective. It
represents a complete workflow involving multiple subsystems or modules. It is used in
Scenario Testing to simulate real-world user behavior and check how well the software
performs in actual usage.
Characteristics: Involves multiple components or modules (e.g., login, search, payment).
Describes a realistic flow of user interaction with the system. Covers positive and negative
user actions. Helps test system integration, usability, and reliability.
Example:
In an e-commerce platform:
"A user logs in, searches for a mobile phone, adds it to the cart, applies a coupon, proceeds to
payment, completes payment using UPI, and logs out."
This System Scenario covers: Login module, Product search, Cart, Discount system, Payment
system, Logout functionality
Purpose: To test real-world workflows. Ensure that all modules interact correctly. Validate the
system as a whole rather than individual parts.
2. Use Case Scenario: A Use Case Scenario describes a specific interaction between a user
(actor) and the system to achieve a single goal or task. It is a step-by-step description of how
the system should respond to inputs. It is derived from Use Case Diagrams in UML (Unified
Modeling Language) and used in requirement gathering and functional testing.
Characteristics: Focused on a single feature or function. Describes main flow and alternate
flows (e.g., success and failure conditions). Involves one actor (user or system) and one system
behavior. Includes preconditions, steps, and expected results.
Structure of a Use Case Scenario:
1. Title: Name of the use case
2. Actor: Who is performing the action
3. Preconditions: What must be true before it starts
4. Steps: The actions taken by user and system
5. Postconditions: Result of the interaction
Example:
Use Case Scenario: "User Login"
• Actor: Registered User
• Precondition: User must have a valid username and password
• Steps: User opens login page, Enters username and password, Clicks 'Login',
System verifies credentials, Redirects to dashboard
• Postcondition: User successfully logged in
Purpose: To validate specific functionalities, Helps in writing test cases, Ensures each
requirement is testable

Q. 11 what is defect bash in integration testing explain in detailed


Defect Bash is a software testing technique where a group of people—including testers,
developers, business analysts, and sometimes end-users—come together for a fixed time to
test the application with the specific goal of finding as many defects/bugs as possible. In
integration testing, Defect Bash is used to uncover interface issues, data flow errors, and bugs
that occur when modules interact. Defect Bash is an informal but focused bug-hunting
activity, where multiple team members test the integrated system using various approaches
without following a strict set of test cases.

Purpose: To discover as many defects as possible in a short time. To test real-world workflows
and module interactions. To find bugs that are missed during formal test execution. To
simulate diverse usage patterns from different perspectives.
How Defect Bash Works:
1. Organized session is planned by the QA team.
2. Testers, developers, and others are divided into teams.
3. Each team is assigned a part of the system or user scenario to explore.
4. Session duration is usually 1–2 hours.
5. All bugs found are documented immediately.
6. Bugs are reviewed, prioritized, and assigned for fixing.
Example in Integration Testing:
Imagine an online travel booking application where modules like login, flight search, payment,
and booking confirmation are integrated.
During a Defect Bash:
• One group may simulate booking with invalid payment.
• Another may try logging in on multiple devices.
• A tester might try to book while network is off.
• Someone may try changing travel dates mid-process.
These unusual test patterns can expose integration issues that wouldn’t be found in standard
scripted tests.
Benefits:
✓ Uncovers hidden defects quickly
✓ Involves multiple perspectives (realistic usage)
✓ Boosts team collaboration
✓ Cost-effective and requires minimal planning
Limitations:

✗ No formal documentation or coverage guarantee


✗ Hard to reproduce defects sometimes
✗ Not suitable for critical systems unless used alongside formal testing
Q. 12 explain boundry values in detailed
Boundary Values refer to the values at the edge or boundary of an input range. Testing these
values is called Boundary Value Testing (BVT) or Boundary Value Analysis (BVA). It is a Black
Box Testing technique used to check how a system behaves at and near the boundaries of
valid input ranges, where errors are most likely to occur.
What is Boundary Value?
Every input field has a range — minimum and maximum values.
• Boundary values are the smallest and largest possible values, as well as the just-
below and just-above values around the limits.
Example:
If a system accepts ages from 18 to 60, the boundary values are:
→ 17, 18, 19 and 59, 60, 61
Why Boundary Values Are Important:
• Most bugs occur at edge conditions rather than in the middle.
• Developers may miss conditions like >= or <=.
• It helps ensure robust input validation.
Boundary Value Testing Rules:
1. Test values just below, at, and just above the boundaries.
2. Minimum and maximum input boundaries are critical.
Example:
Let’s say a form accepts a number from 1 to 100:

Advantages of Boundary Value Testing:

✓ Finds errors quickly and effectively


✓ Reduces number of test cases but gives high defect detection
✓ Simple to understand and implement
✓ Useful for numeric, ordered, or range-based fields
Limitations:

✗ Not suitable for non-numeric data (like text input or dropdowns)


✗ Doesn’t cover complex business logic
✗ May miss mid-range errors

Q. 13 explain system intergration testing


System Integration Testing (SIT) is a type of software testing where multiple systems, modules,
or subsystems are combined and tested as a complete integrated system.
It ensures that all components work together as expected when interfacing with each other..
System Integration Testing validates data flow and interaction between integrated software
components and external systems like databases, APIs, third-party services, or hardware.
Purpose of SIT:
• To verify that integrated modules interact correctly
• To ensure that interfaces, APIs, protocols, and data exchange are functioning
properly
• To find defects related to communication, control flow, and data flow between
subsystems
Examples of Integration in SIT:
Let’s say a banking system has:
• A frontend application (web/mobile app)
• A backend processing system
• A payment gateway (external API)
• A transaction database
SIT will check:
• If user details from the frontend are passed correctly to the backend
• If the backend can successfully communicate with the payment gateway
• If the transaction is properly recorded in the database
• If failures from one module are handled gracefully by others
Approaches Used in SIT:
1. Top-Down Integration – Start from main modules and integrate downwards using
stubs
2. Bottom-Up Integration – Start from sub-modules and integrate upwards using
drivers
3. Big Bang Integration – Integrate everything at once
4. Hybrid (Sandwich) Integration – Combination of top-down and bottom-up
Activities in SIT:
• Prepare test scenarios based on system workflows
• Set up the test environment (e.g., multiple systems, networks, tools)
• Use real or simulated data
• Execute test cases focusing on module interaction
• Log defects and perform retesting
Tools Used:
• Postman / SoapUI – for API testing
• Selenium / JUnit – for automated integration
• JIRA / Bugzilla – for defect tracking
Advantages:
✓ Ensures real-world readiness of the application
✓ Catches interface-level bugs early
✓ Validates data consistency and accuracy
✓ Improves overall system stability
Disadvantages:

✗ Requires multiple systems to be ready


✗ Defect tracing is difficult if many modules are integrated
✗ Complex to plan and execute
Q. 14 explain system & acceptence testing each in detailed
1. System Testing: System Testing is a type of software testing where the entire software
system is tested as a whole to verify that it meets the specified requirements. It is the first
level of testing where the application is tested in a complete, integrated environment.
Key Features:
• Conducted by independent QA/test team.
• Performed after Integration Testing and before Acceptance Testing.
• Based on functional and non-functional requirements.
• It’s a Black Box Testing method (internal code not required).
Types of System Testing:
1. Functional Testing – Verifies core functionalities (e.g., login, search).
2. Performance Testing – Checks speed, load, and scalability.
3. Security Testing – Ensures protection from unauthorized access.
4. Usability Testing – Validates user-friendliness.
5. Compatibility Testing – Ensures software works across different devices, browsers,
or platforms.
Example:
For an online railway booking system, system testing would verify:
• Ticket search
• Train seat selection
• Payment process
• Ticket confirmation
• Integration with SMS/email system
Purpose:
• To verify that the complete system meets functional and quality standards.
• To detect any major defects before delivery to client or customer.
2. Acceptance Testing: Acceptance Testing is the final phase of software testing where the
system is tested to determine whether it is ready to be released to the customer.
It checks whether the software meets business needs and customer expectations.
It is also called User Acceptance Testing (UAT).
Key Features:
• Performed by end users, clients, or business analysts.
• Focuses on real-world usage and requirements.
• Usually conducted in a staging or UAT environment.
• Based on Use Case Scenarios or Business Requirements.
Types of Acceptance Testing:
1. User Acceptance Testing (UAT) – Done by client or end-user.
2. Alpha Testing – Performed at the developer's site with limited users.
3. Beta Testing – Performed by real users at the client’s environment before full
release.
4. Contract Acceptance Testing – Validates terms agreed in the contract.
Example:
For a banking app, acceptance testing would verify:
• Whether customers can log in and view balance
• Transfer funds
• Receive confirmation notifications
• All business flows function as expected
Purpose:
• To confirm that the software is ready for release
• To ensure it meets user expectations and business goals
• To gain approval from the customer or client

Q. 15 explain fucntional & non fucntional testing each in detailed


1. Functional Testing: Functional Testing is a type of software testing that validates the
functional requirements of a software application.
It checks whether the system performs the intended operations correctly, based on the
Software Requirements Specification (SRS).
It is a Black Box Testing method — the internal structure of the code is not known to the
tester.
Purpose:
• To ensure that the software behaves as expected when given valid and invalid
inputs.
• To test the actual functions the system is supposed to perform.
Key Features:
• Focuses on what the system does
• Tests individual features and workflows
• Verifies input-output behavior
• Usually done during System Testing or Acceptance Testing
Examples of Functional Testing:
1. Login Functionality – Does the system allow users to log in with valid credentials?
2. Search Feature – Does the search return the correct results?
3. Payment Processing – Does the system correctly process transactions?
Techniques Used:
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• Use Case Testing
Tools: Selenium, TestComplete, QTP/UFT
2. Non-Functional Testing: Non-Functional Testing checks the quality attributes of the system
that are not related to specific behaviors or functions, such as performance, reliability,
security, usability, etc. It ensures that the software is usable, fast, stable, and secure, under
various conditions.
Purpose:
• To validate how well the software performs under expected and unexpected
conditions.
• To improve the user experience and system stability.
Key Features:
• Focuses on how the system performs
• Tests system’s non-functional aspects
• Helps in identifying performance bottlenecks, UI issues, and security flaws
Examples of Non-Functional Testing:
1. Performance Testing – Does the system load within 2 seconds under 1000 users?
2. Security Testing – Can unauthorized users access secure data?
3. Usability Testing – Is the app easy to use and navigate?
4. Compatibility Testing – Does the software work across different browsers and
devices?
Types of Non-Functional Testing:
• Performance Testing
• Load Testing
• Stress Testing
• Security Testing
• Usability Testing
• Scalability Testing
• Reliability Testing
Tools: JMeter, LoadRunner, Burp Suite, Lighthouse
Functional Testing Non-Functional Testing

It is executed to check the


It is executed to analyze the
performance, reliability,
functionality of components
scalability, and other non-
of an application as per the
functional aspects of an
client’s requirements.
application.

It is executed in the early It is generally performed after


stages of development. functional testing.

Can be performed both


Requires automation tools for
manually and with
effective testing.
automation tools.

Focuses on user
Focuses on user expectations.
requirements.

Determines what the Determines how effectively the


product is capable of product works

Business requirements are Parameters like speed,


the inputs of functional scalability are the inputs of
testing. non-functional testing.

Examples of Non-Functional
Examples of Functional
Testing: Performance Testing,
Testing: Unit Testing, White
Load Testing, Stress Testing,
Box Testing, Smoke Testing,
Security Testing, Installation
Sanity Testing, Usability
Testing, Cross Browser
Testing, Regression Testing.
Compatibility Testing.
Q. 16 explain performance testing in detailed
Performance Testing is a type of non-functional testing that evaluates how a software
application behaves in terms of speed, stability, scalability, and responsiveness under a given
workload. It helps ensure that the system meets performance requirements like response
time, throughput, resource usage, etc.
Performance Testing is used to determine the system’s performance under expected or peak
conditions, such as:
• Number of concurrent users
• Data processing speed
• Response times
• System resource usage (CPU, memory, bandwidth)
Objectives of Performance Testing:
• To check if the software performs quickly and efficiently under real-world
conditions
• To identify performance bottlenecks
• To ensure stability under heavy load
• To validate scalability and reliability
Types of Performance Testing:
1. Load Testing:
o Checks the system's performance under normal and peak load conditions.
o Example: Testing an e-commerce site with 500 users simultaneously.
2. Stress Testing:
o Tests the system beyond its limits to see how it handles overload.
o Helps identify the breaking point.
3. Spike Testing:
o Checks system behavior when the load suddenly increases or decreases.
o Example: During flash sales.
4. Endurance (Soak) Testing:
o Verifies if the system can handle sustained usage over time.
o Example: Running the app for 24–48 hours continuously.
5. Scalability Testing:
o Determines the system’s ability to scale up (e.g., more users, more data)
efficiently.
Performance Metrics:
• Response Time – Time taken to respond to a request
• Throughput – Number of transactions per second
• Latency – Delay before a transfer of data begins
• Resource Utilization – CPU, memory, disk, and network usage
Example: In an online banking system, performance testing will:
• Measure how fast users can log in
• Check transaction completion time under 500+ users
• Test how the system behaves during monthly salary credit (heavy load)
Tools Used:
• Apache JMeter
• LoadRunner
• Gatling
• NeoLoad
• Locust
Advantages:

✓ Improves system reliability and speed


✓ Identifies and fixes performance bottlenecks
✓ Ensures user satisfaction and business continuity
✓ Prevents system crashes in real environments
Q. 17 explain regression testing in detailed
Regression Testing is a type of software testing performed to ensure that recent changes,
updates, or bug fixes in the code have not negatively affected existing functionalities.
Whenever code is modified — due to new features, enhancements, or defect fixes —
regression testing checks that the system still performs correctly.
Regression Testing is the re-execution of previously passed test cases to ensure that existing
functionalities continue to work after changes in the code, configuration, or environment.
Why Regression Testing is Needed:
• Software is frequently updated. Changes in one part may cause bugs in another.
• To catch side-effects caused by bug fixes or enhancements.
• To ensure code stability and reliability over time.
When is Regression Testing Performed?
• After bug fixes
• After code optimization or refactoring
• After adding new features
• After environment or configuration changes
How Regression Testing is Done:
1. Identify the test cases that are affected by the code change.
2. Re-run those test cases (manually or using automation).
3. Compare the current output with previous output.
4. Log defects if any unexpected behavior is found.
Example: In a mobile banking app:
• A developer fixes a bug in the fund transfer module.
• Regression testing is done to check if login, balance check, and transaction history
modules are still working correctly.
This ensures that fixing one issue didn’t break other features.
Manual vs Automated Regression Testing:
• Manual – Done by executing test cases by hand (good for small projects).
• Automated – Uses tools to re-run test cases quickly (ideal for large systems or
frequent releases).
Popular Tools:
• Selenium
• TestNG
• JUnit
• QTP/UFT
• Appium (for mobile apps)
Advantages:

✓ Ensures software remains bug-free after changes


✓ Improves software reliability and confidence
✓ Helps maintain long-term product quality
✓ Highly effective when automated
Disadvantages:

✗ Can be time-consuming if done manually


✗ Requires good test case management
✗ May result in testing overhead if not planned properly

Q. 18 explain internationalization testing in detailed


Internationalization Testing (I18N Testing) is a type of non-functional software testing that
ensures the application is capable of adapting to different languages, cultures, regions, and
formats without requiring any code changes.nIt is performed before localization testing and
ensures that the software is ready to be translated and used globally.
Internationalization Testing verifies whether the application can support multiple languages
and regions by checking the correct design and development practices, such as:
• Unicode support
• Externalizing text from code
• Formatting of dates, times, numbers, and currency
• UI adaptability (layout, fonts, text expansion)
Purpose:
• To ensure that the software can be easily localized (translated and adapted)
• To validate that there are no hardcoded strings, formats, or culturally sensitive
content
• To make the software globally usable without modification
Key Areas Tested:
1. Language Support:
o All strings should be externalized and stored in language resource files.
o Text should support Unicode (e.g., Chinese, Arabic).
2. Date, Time, and Number Formats:
o Application should support different formats like:
▪ Date: DD/MM/YYYY (India) vs MM/DD/YYYY (USA)
▪ Currency: ₹, $, €, ¥
▪ Time: 12-hour vs 24-hour clock
3. User Interface (UI) Compatibility:
o UI should adjust for long translated strings
o No text truncation or overlap
o Support for right-to-left (RTL) languages like Arabic and Hebrew
4. Input and Sorting:
o Should accept international characters in input fields
o Sorting and filtering should work for multi-language datasets
5. Legal and Cultural Considerations:
o Symbols, colors, and images should be culturally neutral or appropriate
o No use of hardcoded country-specific values
Example: Suppose a travel booking website is being internationalized:
• It should allow changing the language from English to Japanese.
• Display prices in local currency (₹, $, ¥).
• Show date/time formats based on region.
• Accept local address formats and special characters.
• The UI should resize automatically when longer translated text appears.
Tools Used:
• Pseudo-localization tools (simulate other languages)
• Globalyzer
• Selenium/WebDriver (for automation)
• Apache i18n framework
• TestRail / JIRA for test case and defect tracking
Advantages:

✓ Makes software global-ready


✓ Prevents redesign during localization
✓ Reduces cost and time of future translations
✓ Helps expand market reach
Disadvantages:

✗ Requires early planning during development


✗ Needs domain knowledge of multiple regions
✗ Can be time-consuming if not automated
Q. 19 explain adhoc testing in detailed
Ad Hoc Testing is an informal and unstructured type of software testing performed without
any formal documentation, test plans, or test cases.
The main goal is to find defects by exploring the system freely, based on the tester’s intuition,
experience, and creativity.
Ad Hoc Testing is a random and unscripted testing approach where testers try to "break the
system" by using unexpected or unusual inputs and flows.
It is typically performed after formal testing to find defects that may have been missed.
Key Characteristics:
• No need for test documents or plans
• Relies on tester’s knowledge of the application
• Conducted in a creative and free-flowing way
• Helps in identifying critical bugs quickly
When is Ad Hoc Testing Performed?
• After formal testing is done
• When there is limited time for testing
• To validate a fix quickly
• During early builds or prototypes
Techniques Used in Ad Hoc Testing:
1. Error Guessing:
o Based on tester's experience, guess where the application is likely to fail
o Example: Entering special characters in login fields
2. Monkey Testing:
o Random inputs and clicks without any sequence
o Example: Clicking all buttons rapidly to check stability
3. Buddy Testing:
o Developer and tester work together to test a feature informally
4. Pair Testing:
o Two testers work on the same system, discuss and execute random tests
Example:
Suppose a shopping cart system has passed all formal test cases.
In Ad Hoc Testing:
• A tester might try adding 0 quantity of a product
• Try clicking “Place Order” without logging in
• Entering emojis or SQL queries in the address field
• Rapidly add and delete products to check system crash
These actions might reveal bugs missed during structured testing.
Advantages:

✓ Helps find unexpected defects


✓ Quick and easy to execute
✓ Requires no preparation or documentation
✓ Good for last-minute testing or testing time constraints
Disadvantages:

✗ Cannot be repeated or traced


✗ Difficult to measure coverage or completeness
✗ May miss bugs if tester is inexperienced
✗ Not suitable for critical systems that require formal testing

You might also like