Software Testing

What is Software Testing is?

It is process of Finding the defects inside the Developed Software Against the Customer requirement
specification is called software testing

What are all the application using the world wide?

Web Applications : - Need URL and Internet connection launched by Browser ex (chrome, Edge,
Fire fox, and Mozilla Fire Fox etc . Example websites Birch street, Teradata)

Mobile Applications :- Can download form the play store in the mobile , need internet connection
called Mobile applications ( What Sapp , Instagram , Facebook etc)

Desktop Applications : - Can get via file installing in the pc or lap these applications dose not need
internet no need servers no need to download (paint, word, calculator, notepad)

Types of Software Testing

White Software Testing is the process of finding ds the process of finding

defects in the developed software against the customer's requirement
specifications."
White Box Testing ?

 Testing each and every line of the source code is called White Box Testing.
 It is done by development engineers.
 White box Testing is the First Testing in the development environment
 Developer’s will do only positive testing
 It is also called as Unit Testing

Path Testing
In Path Testing, we write the flow graph and execute the program independently.

 In path testing, we write the flow graph and execute the program independently.
 There are fewer chances to miss the testing of some programs.
 Hence, we can avoid repetitive testing of the same code.
2. Conditional Testing

 In this testing, we check the program for both true and false conditions.
 Example:
o if (a > b) – True path
o if (a < b) – False path

53. Loop Testing

 In this testing, we test all the looping statements.

 It is used when we have to perform certain actions repeatedly.

Types of Loops:

 While loop
 Do-while loop
 For loop

Example of While Loop:

public class LoopExample {

public static void main(String[] args) {

int i = 1;

while (i <= 5) {

[Link](i);

i++;

}
White Box Testing (Memory Point of View)

1. Because of Not Using Proper Logic

 This happens when we use the wrong logic, which increases the length of the code
unnecessarily.
 Example: Wrong logic in nested loops or inefficient design patterns can increase
execution time and memory usage.

2. Because of Not Using Functions

 If we don’t use functions, the same code is repeated multiple times, leading to an
increase in the size of the code.
 Functions help reduce redundancy and improve maintainability.

3. Because of Not Using Built-in Functions

 The lack of using inbuilt functions leads to writing extra code manually, which could
have been simplified.
 Example: Sorting an array manually instead of using a built-in sorting function.
4. Because of Unused Variables and Functions

 Unused variables take up memory unnecessarily.

 Example: Declaring variables or methods that are never used in the program increases
memory usage and code size.

White Box Testing (Performance Point of View)

 Performance issues can arise if the program is written inefficiently by the developer.
 The time taken to run a program may be increased due to unnecessary steps in the
logic.
 Example:

java
CopyEdit
if (a == b) {
print("Yes");
} else {
print("No");
}

 If you’re using one condition, you can check it directly without extra code to save
execution time.
 Optimizing if-else and loop conditions can significantly improve performance.
Scenarios:
→ Scenario is a one line description (or) high level description of a functionality that we use
to test the website.

→ Will conclude What to test What not to test

Why do we need Scenarios

→ Help to understand the real user behaviour.
→ Easy to communicate with non technical person.
→ Save time by identifying the core functionality.
→ Forms base for writing the test cases.
→ Useful for both manual and automation testing.

Where do we use scenarios

1. Test case designing / drafting the test case (or) test design → understanding the
features.
2. Requirement review.
3. Manual testing: for daily activities.

Real time Scenarios For White Board Marker

Positive Scenarios ✅

1. Verify that the whiteboard marker writes smoothly on the whiteboard surface without
skipping ink.
2. Verify that the ink color matches the label on the marker (e.g., blue ink for a blue
marker).
3. Verify that the marker ink can be easily erased from the whiteboard using a dry
eraser.
4. Verify that the marker cap fits tightly to prevent ink from drying.
5. Verify that the marker can be used for a continuous duration (e.g., 2–3 minutes)
without fading.

Negative Scenarios ❌

1. Verify that the marker does not leave permanent stains on the whiteboard surface.
2. Verify that the ink does not smudge when touched immediately after writing.
3. Verify that the marker does not leak ink when stored horizontally or vertically.
4. Verify that the marker writes only on appropriate surfaces and not on glass or paper
(if not intended).
 5. Verify that the marker does not emit a strong or unpleasant odor that causes
discomfort.

Real time Scenarios For Mobile Phone

Positive Scenarios ✅

1. Verify that the mobile powers on successfully when the power button is pressed.
2. Verify that the touchscreen responds accurately to single and multi-touch gestures.
3. Verify that the device connects to Wi-Fi networks and can browse the internet.
4. Verify that calls can be made and received without call drops in a good network area.
5. Verify that the camera captures clear images according to its specifications.

Negative Scenarios ❌

1. Verify that the mobile does not overheat during normal usage.
2. Verify that the battery does not drain excessively in standby mode.
3. Verify that the mobile does not crash or freeze when multiple apps are running.
4. Verify that the mobile does not allow unauthorized access without a correct
password, PIN, or biometric authentication.
5. Verify that the mobile does not get damaged under minor accidental drops within safe
height limits.

Test cases
In major stage, it is the document which contains possible scenarios for a specific
requirement.

It’s a different fields like:

1. TC ID
2. Tittle of the Test Case
3. Pre Conditions
4. Test steps
5. Test Data
6. Expected Result
7. Actual Result
8. Status
9. Comment’s
Need & Advantages of test writing test cases

 We write test cases to maintain the consistency.

 If we don’t write test cases we have to depend on the mood of the test engineer.
 If we don’t write test cases we have to depend on the memory power of the test
engineer.
 We write test cases because without test cases the quality of testing will depend from
person to person.

Why do we write test cases?

 When the developers are developing the s/w

 When the developers are modifying the s/w also we will modify the test cases.

Why do we write test cases?

 If we write test cases, we have better test coverage.

 When the developers are busy in developing the s/w the test

Engineer to identify all the possible scenarios and document these identify scenarios.

 When the build comes you can immediately start executing the test cases.
 We write test cases to have better consistency, if you have not documented the
scenarios by executing the scenarios you can make sure that you have executed all the
documented scenarios.
 We write test cases so that we don’t have to hand over every new person to the
project.
 We write test cases to depend on the project rather than the person.
 Test cases act like proof document for the customer after testing the whole s/w we
will deliver all the test cases as proof to the customer.
 Test cases act like a base document for writing the automation test scripts.
 If we write test cases we don’t have to remember scenarios.
 If we write test cases then test execution will be done in an organized way.
 By writing test cases the time taken to execute will be less.

1. TC ID (Test Case ID)

 Meaning: A unique identifier assigned to each test case.

 Purpose: Makes it easy to track, reference, and manage test cases.
 Example: TC_UI_001 (where UI stands for User Interface and 001 is the sequence
number).

2. Title of the Test Case

 Meaning: A short, descriptive name for the test case.

  Purpose: Gives a quick understanding of what is being tested without reading the
whole test case.
 Example: "Verify login with valid username and password".

3. Pre-Conditions

 Meaning: The specific setup or state the system must be in before executing the test.
 Purpose: Ensures that the environment is ready for testing to avoid false failures.
 Example: User must be registered and have a valid account; Browser must be open
on login page.

4. Test Steps

 Meaning: Step-by-step instructions on how to perform the test.

 Purpose: Ensures the test can be consistently repeated by anyone.
 Example:
1. Enter username in the username field.
2. Enter password in the password field.
3. Click on the "Login" button.

5. Test Data

 Meaning: Input values used during the test.

 Purpose: Standardizes the data used so results are reliable.
 Example:
o Username: john_doe
o Password: Password123

6. Expected Result

 Meaning: The outcome you expect if the system works correctly.

 Purpose: Defines the criteria for pass/fail.
 Example: User is redirected to the dashboard page and sees a welcome message.

7. Actual Result

 Meaning: What actually happened when the test was executed.

 Purpose: Used to compare with the expected result to determine pass/fail.
 Example: User successfully logged in and dashboard displayed.
8. Status

 Meaning: Indicates whether the test passed, failed, or was blocked.

 Purpose: Tracks testing progress and identifies issues quickly.
 Common values: Pass, Fail, Blocked, Not Executed.

9. Comments

 Meaning: Any additional notes or observations from the tester.

 Purpose: Helps explain anomalies, failures, or other relevant information.
 Example: "Test failed because the password field did not accept special characters".

Test Case Template

Tittle of the Test Pre Test Test Expected Actual
TC -ID case Condition steps Data Result Result Status
Black box Testing

1. Functionality testing
It is also know as component testing also called as field level testing

Verifying the functionality component thoroughly against the prepared specification

called as functionality testing

Testing each and every component of the application against whether it is meeting
requirement specification — we call it as functionality testing.

Components

 Text box (could provide data)

 Field box (could provide data in some maximum logical box etc.)
 Drop downs
 Hyper links
 Radio buttons
 Buttons etc

Thoroughly means by entering all possible values

Example Scenarios for name text Field

Requirements for above sign up image

Name → It should accept alphabets

 Try to enter a number → should not accept

Email → It should accept valid email address

 Try to enter without “@” → should show “Email format invalid”

 Example: [Link] (invalid)
 Example: test@[Link] (valid)

Password →

 It should accept more than 6 characters

 It should mask the password (●●●●●●)
 Should allow special characters: @, #, $, %, &, * etc.

Confirm Password →

 It should match exactly with the Password field

 If mismatch → show error “Passwords do not match”

Ways of Testing

There are three ways of testing:

1. Under Testing
2. Over Testing
3. Optimized Testing

Under Testing
Testing the application with insufficient scenarios we call it as under testing.

Example:
Phone →
Valid: 9876543210 (valid)
Invalid: ABCD, 123, !@#$$

Disadvantages of under testing:

While doing under testing we might miss some defects.
Over Testing
Testing the application with same set of scenarios again and again we call it as over testing.

Phone
Valid → 9876543210 (10 digits)
Invalid →

 abcd
 12345
 abcd1234
 !@#

Disadvantages of Over Testing:

While doing over testing, we might lose precious time.

Optimized Testing
Testing the application with sufficient scenarios we call it as optimized testing.

Phone
Valid: 9876543210 (valid)
Invalid:

 123 (less digits)

 98989898989 (11 digits)
 ABCD (alphabets)
 abc@123 (special char)
 1234abcd (mix of numbers & letters)

Advantages of Optimized Testing:

While doing optimized testing, we can find maximum bugs in minimum time.

Types of Testing:

1. Positive Testing
2. Negative Testing

Positive Testing
Testing the application or module with valid values we call it as positive testing.
Phone
Valid: 9876543210 (10 digits)

Negative Testing
Testing the application with invalid values we call it as negative testing.

Phone
Invalid:

 123 (less digits)

 98989898989 (11 digits)
 ABCD (alphabets)
 abc@123 (special char)
 1234abcd (mix of numbers & letters)
 !@#

Real time Scenarios for Phone number text field

Positive Scenarios ✅

1. Verify the phone number field accepts exactly 10 digits (e.g., 9876543210).
2. Verify the phone number field accepts a valid 10-digit number starting with 6, 7, 8, or
9.
3. Verify the phone number field accepts a valid 10-digit number pasted from the
clipboard.
4. Verify the phone number field accepts numbers without spaces or formatting
characters.
5. Verify the phone number field accepts numbers entered using a numeric keypad only.
Negative Scenarios ❌

1. Verify the phone number field rejects numbers with less than 10 digits.
2. Verify the phone number field rejects numbers with more than 10 digits.
3. Verify the phone number field rejects alphabetic characters.
4. Verify the phone number field rejects special characters.
5. Verify the phone number field rejects alphanumeric characters.

Integration Testing
Testing the data flow between two modules — we call it integration
testing.

How do we do integration testing?

Understanding the application is important

Understanding the data flow between the modules

Identifying the scenarios

Prioritizing the scenarios

Positive Integration Testing

Testing the data flow with valid data — we call it positive integration
testing.

Example:
 Balance Page:
Your current balance is ₹10,000

Amount Transfer Page:

FAN: 12345

TAN: 678910

Amount: 10,000

Buttons: Transfer | Cancel

Confirmation Page: Transaction Success

Negative Integration Testing

Testing the data flow with invalid values — we call it negative integration testing.

Example:

Balance Page:
Your current balance is ₹10,0000

Amount Transfer Page:

FAN: 12345

TAN: 678910

Amount: 50,0001

Buttons: Transfer | Cancel

Confirmation Page: Transaction Failed — Not possible

Identifying the scenarios for g mail

Scenarios:

Drafts → Compose ✔

Drafts → Sent items ✔

Drafts → All mails ✔

Drafts → Calendar ✔

Drafts → All mails ✔

All Mails →

Compose ✔️

Sent Items ✔️

Drafts ❌

Cal ❌

Fav ✔️
Fav →

Compose ✔️

Sent Items ✔️

Drafts ❌

Calendar ❌

All Mails ❌

Sent Items →

Compose ✔️

Drafts ❌

Fav ✔️

Calendar ❌

All Mails ❌

Calendar →

Compose ✔️

Sent Items ❌

Drafts ❌

Fav ❌

All Mails ❌

Ways of Integration Testing

[Link] way integration testing

[Link] way integration testing

 [Link] way / No way integration testing

1) Two way integration testing

The data flow between module A → module B and from module B → module A — we call it
as two way integration testing.

A↔B

Edit user ↔ Delete user

Example: From edit user to delete user & delete user to edit user.

2) One way integration testing

The data flow between module A → module B but there is no data flow from module B →
module A — we call it as one way integration testing.

A → B

Add user → Inbox

3) Zero way / No way integration testing

When there is no data flow from module A → module B or from module B → module A —
we call it as no way integration testing.

css

CopyEdit

A X B

Add user Product sales

3) System Testing
It is an end to end testing where in the test environment is similar to the product environment.

End-to-End Testing:
Navigating through all the features of the S/w, To check whether the end feature working
properly or not.
1: Eg Flipkart – Navigating thro all module
Login → Search Product → Add to cart → checkout → Address → Payments → Order
Confirm → My orders → Delivered → Feedback (End feature)

Real Time Scenarios

1. Fund Transfer (NEFT/IMPS/RTGS)

Scenario: Verify the user is able to Transfer ₹10,000 from one account to another
using NEFT.

Steps: Login → Go to Fund Transfer → Select NEFT → Enter beneficiary details →

Enter amount → Confirm with OTP.

Expected Result: Amount should be deducted from sender’s account, credited to

receiver’s account, and both should get SMS/email notifications.

2. Fixed Deposit Creation

Scenario: Verify the user is able to Create a Fixed Deposit of ₹50,000 for 1 year.

Steps: Login → Deposits → Create FD → Select amount & tenure → Confirm

transaction with OTP.

Expected Result: FD should be created successfully, interest rate should match

current bank rates, and FD details should reflect in account summary.

3. Loan EMI Payment

Scenario:Verify the user is able to Pay monthly EMI for an active personal loan.

Steps: Login → Loan Accounts → Select EMI Payment → Enter amount → Confirm
with OTP.

Expected Result: EMI should be deducted, loan outstanding should reduce

accordingly, and receipt should be generated.

4. Bill Payment (Electricity/Water/Phone)

Scenario: Pay an electricity bill of ₹2,000.

 Steps: Login → Bill Payments → Select Electricity Provider → Enter consumer
number → Fetch bill → Pay via net banking.

Expected Result: Payment should be successful, transaction ID generated, biller

should update payment status.

5. Overdraft Facility Application

Scenario: Apply for an overdraft (OD) facility on a current account.

Steps: Login → Loans → Apply for OD → Enter required limit → Submit.

Expected Result: System should validate eligibility, calculate applicable fees &
interest, and confirm application submission.

Adhoc Testing

Definition:
Adhoc Testing is an informal and unstructured type of software testing performed without
any formal test planning or documentation. The main aim is to find defects through random
testing of the application’s functionality.

Key Points:

Performed without test cases or a test plan.

Tester uses their understanding of the application and intuition to find defects.

Usually done after formal testing is completed to catch hidden defects.

Often involves exploratory testing techniques.

Can be done anytime during the testing phase but is most effective after the build is
stable.

Advantages:

Helps find unexpected defects that scripted tests might miss.

Requires less preparation time.

Encourages creativity and out-of-the-box thinking.

Useful when time is limited.

Disadvantages:

Difficult to track what has been tested.

No proper documentation for future reference

Relies heavily on tester’s skill and domain knowledge.

Defects may be hard to reproduce if steps are not recorded immediately.

Best Practices:

Ensure the tester is familiar with the application.

Combine with exploratory techniques.

Keep notes of steps when a defect is found.

Use Adhoc Testing as a supplement, not a replacement, for structured testing.

Exploratory Testing

Definition:
Exploratory Testing is a type of software testing where test design, test execution, and
learning happen simultaneously. The tester explores the application, learning about its
behaviour, and designs tests on the fly based on observations.

Key Characteristics:

 Simultaneous process: Test planning, design, and execution are done together.
 Learning-focused: The tester learns the application while testing it.
 Unscripted but structured: Not based on pre-written test cases but follows certain
charters or goals.
 Creative and adaptive: The tester adapts based on findings in real-time.

When to Use Exploratory Testing

 When requirements are incomplete or unclear.

 When there is limited time for testing.
 To discover hidden defects after formal testing.
 In agile environments where rapid feedback is needed.
Advantages

1. Finds critical bugs that scripted testing may miss.

2. Encourages creativity and out-of-the-box thinking.
3. Adapts quickly to changes in the application.
4. Improves tester’s domain knowledge.

Disadvantages

1. Difficult to measure coverage.

2. Relies heavily on tester’s skill and experience.
3. Requires good documentation of findings to reproduce bugs.

Process Flow (Diagram Description)

[ Explore the Application ]

[ Learn the Functionality or Understand the functionality ]

[ Find the scenarios ]

[Document the scenarios]

[ Execute the test cases ]

[ Test report Generation ]

[ Refine Next Tests ] → (Loops back to Explore)

Usability Testing

Definition:
Usability Testing is a type of software testing used to evaluate how easy and user-friendly a
software application is for the end users. The goal is to identify any usability problems,
collect feedback, and improve the overall user experience.

When to Perform

 During the design phase (with prototypes).

 Before release (on completed product).
 After release (to gather improvement ideas).

Advantages

 Improves customer satisfaction.

 Reduces training and support costs.
 Detects issues early in development.

Disadvantages

 Can be time-consuming.
 May require special tools and labs.
 Results depend on participant selection.

Smoke Testing

Definition:
Smoke Testing is a preliminary testing process performed to check whether the critical
functionalities of a software build are working correctly before proceeding with more detailed
testing. It is often called “Build Verification Testing (BVT)”.

When to Perform

 After receiving a new build from developers.

 Before starting full regression or system testing.

Characteristics

 Shallow and wide approach: Tests cover most major functionalities but not in depth.
 Quick execution — usually 1–2 hours for small builds.
 Can be manual or automated.
Advantages

 Saves time and cost by detecting major defects early.

 Reduces risk of wasting resources on a broken build.
 Simple and fast to perform.

Disadvantages

 Does not cover detailed functionality.

 Cannot guarantee that all defects are found.

Smoke Testing Process

[ Receive New Build ]

↓
[ Install & Configure Build ]
↓
[ Execute Smoke Test Cases ]
↓
[ Pass? ] → Yes → [ Proceed to Detailed Testing ]
→ No → [ Reject Build & Send to Dev ]

Globalization Testing

Definition:
Globalization Testing is a type of software testing performed to ensure that an application
works seamlessly across different languages, regions, and cultures without the need for code
changes. It verifies that the product can be global-ready and supports internationalization
(i18n) and localization (l10n) requirements.

Purpose

 Ensure the application can adapt to multiple languages and regions.

 Verify that UI, date formats, currency, time zones, and cultural aspects display
correctly.
 Ensure that text expansion in different languages does not break the UI layout.
Key Focus Areas

1. Language Compatibility – Application can display and process multiple languages

without data corruption.
2. Date & Time Formats – Correct formatting for different locales (e.g.,
DD/MM/YYYY vs MM/DD/YYYY).
3. Currency – Correct symbols, decimal separators, and currency formats (e.g., ₹100.50
vs $100.50).
4. Sorting & Collation – Sorting rules according to regional language rules.
5. Number Formats – Different decimal separators (e.g., 1,000.50 vs 1.000,50).
6. Text Expansion/Shrinkage – UI should accommodate longer words in some
languages (e.g., German).
7. Cultural Sensitivity – No offensive or culturally inappropriate words/images.
8. Right-to-Left (RTL) & Left-to-Right (LTR) Support – For languages like Arabic,
Hebrew.

Types of Testing in Globalization

1. Internationalization Testing (i18n) – Checks if the application can be adapted to

different languages and regions without code changes.
2. Localization Testing (l10n) – Checks if the application displays content correctly for
a specific language/region.

Advantages

 Expands application reach to global markets.

 Improves customer satisfaction in different regions.
 Avoids cultural/formatting errors that could cause user frustration.

Disadvantages

 Requires skilled testers who understand multiple locales.

 Can be time-consuming if many languages/regions are involved.
Performance Testing

Definition:
Performance Testing is a type of non-functional testing that measures how well a software
application performs under a particular workload. The goal is to ensure the application is fast,
stable, and scalable.

Objectives

 Verify speed – Response time of the system.

 Verify stability – Application performance under continuous load.
 Verify scalability – Application’s ability to handle increasing users or data.
 Detect bottlenecks in hardware, software, or network.

Key Performance Metrics

1. Response Time – Time taken for the system to respond to a request.

2. Throughput – Number of transactions handled per second.
3. Resource Utilization – CPU, memory, disk, network usage.
4. Concurrent Users – Number of users system can handle simultaneously.
5. Error Rate – Percentage of failed requests.

Types of Performance Testing

1. Load Testing – Checks system performance under expected user load.

2. Stress Testing – Tests beyond normal load to find breaking point.
3. Spike Testing – Sudden increase in load to see if system recovers.
4. Endurance (Soak) Testing – Long duration load to check stability.
5. Scalability Testing – Measures ability to scale up with more resources.
6. Volume Testing – Checks system performance with large data volumes.

Advantages

 Improves system reliability.

 Enhances user satisfaction.
 Prevents downtime and crashes during peak usage.
 Identifies performance bottlenecks before release.
Disadvantages

 Requires specialized tools (e.g., JMeter, LoadRunner).

 Needs skilled testers and performance engineers.
 Test environment should closely match production, which can be costly.

Regression Testing

Definition:
Regression Testing is a type of software testing performed to ensure that a recent code
change or bug fix has not adversely affected the existing functionality of the application.

Purpose

 To verify that new changes have not broken existing features.

 To detect side effects of enhancements, bug fixes, or updates.
 To maintain software stability with every release.

When to Perform

 After bug fixes.

 After adding new features.
 After code optimization or updates.
 During maintenance releases.

Types of Regression Testing

1. Unit Regression Testing

 Focuses on a specific unit/module of the application where changes were made.

 Conducted during the unit testing phase.
 Ensures changes in one module do not break its own internal functionality.
 Usually done by developers.
 Example: If a developer changes the interest calculation formula in a loan module,
they only test that formula’s functions.

2. Regional Regression Testing

 Tests a specific region or group of related modules where the change occurred.
 Ensures the modified module works well with its closely connected modules.
 Broader than unit regression, but not full application testing.
  Example: If a “Fund Transfer” feature changes, regional regression will test transfer
module, account balance update, and transaction history — but not unrelated modules
like “Loan Application.”

3. Full Regression Testing

 Entire application is tested to ensure no new changes have broken any functionality.
 Usually performed before major releases.
 Time-consuming and requires more resources.
 Example: After a big system upgrade in a banking app, test all features like login,
fund transfer, bill payments, FD creation, and loan modules.

Advantages

 Ensures software stability.

 Reduces risk of introducing new bugs.
 Builds confidence before release.

Disadvantages

 Can be time-consuming for large applications.

 Requires frequent test maintenance.
 May need automation for efficiency.
Defect Tracking or Defect Life Cycle

By function we concentrate what is not working according to the requirement

specification. We call this deviation from requirement specification at all the stages a
defect.

Types of defect
We get defects because of three scenarios:

1. Missing implementation
2. Wrong implementation
3. Extra implementation

Missing Implementation
Anything which is present in requirement specification but not present in the SRS we call it a
missing implementation.

Sale page → Defect

Req Sale page

P1, P2, P3 p1, ,p3

Wrong Implementation
Anything which is present in the requirement specification but wrongly based on the info we
call it as a wrong implementation.

Req Sale page

P1, P2, P3 P1, P3, P2

Extra Implementation
Anything which is present in the SRS but not present in the requirement we will call it as
extra implementation.
 Req Sale page

P1, P2, P3 P1, P2, P3, P4

What is the difference between defect, bug, error?

1. Defect — If deviation from requirement/specification, we call it a defect.

2. Bug — It is an informal name given to the defect.
3. Error --- Mistakes done by the programmer is called Error

There are two types of Errors:

1. Compile Time Error

2. Run Time Error

1. Compile Time Error

Any mistake done by programmer in the syntax code — we call it as compile time error.

public class CompileTimeErrorExample {

public static void main(String[] args) {

int number = "Hello"; // ❌ Compile-time error: incompatible types

[Link](number);

2. Run Time Error

Any mistake done by programmer in the logic code — we call it as run time error.

Example:

public class RuntimeErrorExample {

public static void main(String[] args) {

int[] numbers = {1, 2, 3};

[Link](numbers[5]); // ❌ Runtime error:

ArrayIndexOutOfBoundsException

}
Rejected Status

Common Defect Statuses List:

1. New/Open
2. Assigned
3. Rejected Status
4. Deferred Defects
5. Duplicate Defects
6. Postponed Defects
7. Cannot be fixed Defects
8. Not reproducible Defects
9. RFE Defects
10. Fixed
11. Reopen
12. Closed

01. New / Open

 Meaning:
When a tester finds a defect and logs it into the defect tracking tool, it is initially
given the status New or Open.
 Purpose:
Indicates that the defect has been reported but not yet reviewed by the developer or
triage team.
 Next Step:
The development team will analyze it and decide whether it’s valid, needs fixing, or
should be rejected.

2. Assigned

 Meaning:
Once the defect is reviewed and confirmed as valid, it is assigned to a specific
developer for fixing.
 Purpose:
Shows responsibility has been given to a developer to work on resolving it.
 Next Step:
The developer starts working on the code changes needed to fix the defect.
[Link] Status
Anything which is in Test Engineer phase (in defect progress) and found already reported
earlier in the same module or another module gets the status Duplicate.

Why do we get duplicate status?

 The tester might log the same defect which already exists in the defect management
tool

How to avoid Duplicate Status:

 Check the Advanced Search in the defect tracking tool before logging.
 Search using keywords and description to ensure the defect is not already reported.
 Communicate with team members to confirm defect existence before logging.

[Link] Status

Definition:
When a test engineer reports a defect, but the development team decides not to fix it
immediately and schedules it for a later release, the defect is marked as Postponed.

This happens when:

 The defect is minor and does not affect current functionality.

 The defect fix requires significant changes that could delay the current release.
 The defect is in an area planned for redesign in the future.

Why defects get Postponed status:

1. Time constraints – Developers don’t have enough time in the current sprint/release
cycle.
2. Low priority – The defect is not critical for current operations.
3. Dependency on future changes – The defect will naturally be fixed when another
module is updated.

[Link] Reproducible Status

Definition:
A defect is marked as Not Reproducible when the test engineer reports a bug, but the
development team cannot reproduce it in their environment — even after multiple attempts
using the same steps.

Reasons for Not Reproducible status:

 1. Mismatch in environments – The defect occurs in the tester’s setup but not in the
developer’s setup (e.g., OS version, browser, device).
2. Incomplete steps – The tester’s bug report may be missing detailed steps to
reproduce.
3. Intermittent issue – The bug appears only in rare conditions or due to unstable
network/load.
4. Data dependency – Bug occurs only with specific data that is not available in the
developer’s environment.

[Link] (Request for Enhancement) Defects

Definition:
RFE = Request for Enhancement.
When a developer or tester suggests an improvement or new feature which is not part of the
original requirements, it is called an RFE defect.

Example:

 Requirement: Create a Login page.

 Enhancement request: Add "Forgot Password" option.

07. Fixed

 Meaning:
The developer has made the necessary code changes and believes the defect is
resolved.
 Purpose:
Indicates that the fix is ready for verification by the tester.
 Next Step:
The tester will retest the defect to confirm the fix works and doesn’t cause new issues.

08. Reopen

 Meaning:
If, during retesting, the tester finds that the issue still exists or the fix is incomplete,
the defect is reopened.
 Purpose:
Sends the defect back to the developer for further investigation and fixing.
 Next Step:
Developer reviews and fixes it again before sending back for retesting.
09. Closed

 Meaning:
When the tester confirms that the defect is completely fixed and no longer
reproducible, it is closed.
 Purpose:
Marks the defect’s life cycle as complete.
 Next Step:
No further action required unless the issue resurfaces in the future.

[Link] Status
Anything which is in Test Engineer phase (in defect progress) is rejected. This means it is not
a valid defect and needs to be closed.

Why do we get rejected status? – They assign the status to "Rejected".

We get rejected status because of extra implementation.

Severity

It is the impact created by the defect on the business or customer.

Levels of Severity

1. Blocker / Show Stopper

2. Critical
3. Major
4. Minor

1. Blocker / Show Stopper

Any defect which stops our ability to test further, we call it a blocker or show stopper.

Example diagram in your notes:

 Citi Bank (Amount Transfer feature)

o Amount Transfer → Balance Transfer → FD / RD
o Blank page defect → Blocked defect
Critical defect
Any defect which creates huge loss for the customer or the company — we call it a critical
defect.
Major defect
Any defect which does not create a huge loss for the customer — we call it a major defect.

Minor defect
Any spelling mistake or colour change in the SRS — we consider it as a minor defect.

Priority
It is the importance given to the defect.
There are three levels of priority:

1. High (P1)
2. Medium (P2)
3. Low (P3)

Note:

 Generally, all the blocker & critical defects get high priority.
 All the major defects get medium priority.
 All the minor defects get low priority.
 But under other circumstances, the levels of severity & priority change from company
to company and project to project.

Example:

 Minor defect with high priority – e.g., Company logo missing on login page.
 Critical defect/blocker defect with low priority – e.g., A defect in a rarely used
feature that doesn’t impact immediate release.

Defect Tracking Tool: (diagram shown)

  Used to log, track, and manage defects.
 Example: JIRA, ALM, Bugzilla.

Test cases Design Techniques

Types into it

[Link] Value Analysis (BVA)

02. Equivalence Partitioning (EP)

[Link] Transition Testing

04. Error Guessing (Experience-Based Techniques)

[Link] Value Analysis (BVA)

Boundary Value Analysis is a Black Box Test Design Technique where test cases are
designed to include values at the edges of input ranges.
Why? Because defects are most likely to occur at the boundaries rather than in the middle
of the range.

Key Idea

If an input field accepts values between min and max, you test:

 Exactly at the minimum value

 Just below the minimum value
 Exactly at the maximum value
 Just above the maximum value

Example 1 — Age Field

Requirement: Age must be between 18 and 60 (inclusive).

Boundaries:

 Minimum = 18
 Maximum = 60

BVA Test Cases:

Test Data Expected Result

17 Invalid (below min)

18 Valid (min boundary)

19 Valid (just above min)

59 Valid (just below max)

60 Valid (max boundary)

61 Invalid (above max)

[Link] Partitioning (EP)

 Divides input data into valid and invalid partitions.

 Example: If age input is 100–500, test one value from valid range and one from
invalid range.

Equivalence Classes:

1. Invalid – Less than 100 characters (e.g., 50)

2. Valid – Between 100 and 500 characters (e.g., 300)
3. Invalid – More than 500 characters (e.g., 600)

Test Cases Table:

Input Length Expected Result

50 Invalid
300 Valid
Input Length Expected Result
600 Invalid

[Link] Transition Testing

is a black-box test design technique used to test how a system behaves when transitioning
between different states in response to events or inputs.

It’s useful when:

 The system has finite states (e.g., idle, processing, completed, error).
 The output or behavior depends on the current state and the input received.

Key Concepts

1. State – A condition or situation during the life of an object/system (e.g., "Logged In",
"Logged Out").
2. Transition – A movement from one state to another caused by an event/input.
3. Event – A trigger that causes a transition (e.g., user clicks “Login”).
4. Action – The output/result that occurs during the transition.

Example

ATM Machine States

 State 1: Card Inserted

 State 2: PIN Entered Correctly
 State 3: Transaction Selected
 State 4: Cash Dispensed

Transitions:

 Insert Card → Enter PIN → Select Transaction → Dispense Cash.

Advantages

 Ensures all valid and invalid state transitions are tested.

 Detects defects caused by wrong order of operations.

When to Use

 Login/logout flows
  ATM operations
 Elevator control systems
 Online order status changes

Error Guessing

is a software testing technique where the tester uses experience, intuition, and prior
knowledge to guess the most probable areas where defects might occur.

It’s not based on formal design methods, but on the tester’s skills and understanding of
similar systems.

Key Idea

The tester "guesses" the errors by thinking:

“Where could this system fail?”

How It Works

1. Use past defect history.

2. Think about common mistakes developers make.
3. Focus on complex logic, boundary conditions, and integrations.
4. Write test cases targeting those areas.

Example

If testing a login page, an experienced tester might guess:

 What happens if the username is left blank?

 What if the password contains special characters?
 What if the user tries to log in multiple times quickly (brute force)?

Advantages

 Can quickly find hidden bugs.

 Complements formal test design techniques like BVA, Equivalence Partitioning, State
Transition Testing.
Disadvantages

 Relies heavily on tester’s experience.

 Not systematic — may miss defects if tester lacks domain knowledge.

Test Plan

A Test Plan is a document that contains all the features, testing activities, and details about
how testing will be done.

It may include:

1. Objective
2. Scope
3. Approach
4. Testing Methodology
5. Schedule
6. Effort Estimation
7. Assumptions
8. Criteria
9. Mitigation Plan (Backup Plan / Contingency Plan)
10. Entry and Exit Criteria
11. Test Case Creation
12. Test Automation
13. Defect Tracking
14. Deliverables
15. Roles & Responsibilities
16. Test Environment
17. Templates

1. Objective

In this stage, we define the main goal of our testing.

Here, we decide what is the aim of our testing and why exactly we are doing it.

2. Scope

In this stage, we decide which features to test and which features not to test.
3. Approach

In this stage, we decide what kind of approach or strategy to take for testing.
We outline:

 Which activities will be done

 In what order
 The criteria and standards to follow during testing

4. Testing Methodology

In this stage, we decide what types of testing will be done.

Testing Type E-commerce Banking App

Smoke ✔ ✔
Functionality ✔ ✔
System ✔ ✔
Integration ✔ ✔
Performance ✔ ✘
Adhoc ✔ ✘
Compatibility ✔ ✔
Usability/Interface ✔ ✘

✔ = Will be tested
✘ = Will not be tested

5. Schedule

In this stage, we plan the time line of the product.

We decide the time and schedule of each step,
every task and activity, which will be done in the testing process.

6. Effort Estimation

In this stage, we decide how much effort we are

going to put into the project.

 We estimate human effort (number of people, number of hours, required skills,

upcoming tasks).
 We estimate financial effort (cost of resources, tools, equipment, environment,
salaries, etc.).
  We also consider time effort for the project (total time for testing per project, work
distribution, etc.).

7. Assumptions

Whenever we are testing a product, we might assume a few things:

1. All the test engineers will be working till the end of the project.

8. Risk

If we are missing something without any clarity, we can understand it as:

 Mitigation Plan (before the damage)

 Contingency Plan (after the damage)

In this stage, we will create the recovery plan for all the risks when we are testing the
project.

Primary Owner

Test Engineer who is responsible at the time of the failure of the feature.

Secondary Owner

It is a backup option. In case the primary owner of the feature drops out or is not able to
perform.

9. Entry and Exit Criteria

 Entry Criteria:
These are the conditions which need to be satisfied before starting the test flow.
  Exit Criteria:
In this step, we will check all the closing conditions from when we will start the test
to project end, and exit conditions from which we will stop the test in that particular
project.

Entry Criteria

 Test environment should be ready.

 Test document should be prepared.
 Test data should be ready.
 Application should be ready.
 All the required licenses should be available.
 Tools for testing of a project.

If facilities need to be arranged:

 There could be required working displays.

 All the network logs should be working wherever offline.
 All log files should be created according to requirement.

Test Stop Criteria

In this stage we will decide when to close, start and stop a particular type or kind of testing.

We will stop testing any type under two conditions:

1. When the quality of S/W is very good.

2. When the quality of S/W is very bad.

a) Very Good Quality S/W

 When there are no critical and blocker defects.

 The data is functioning effectively.
 All the modules and features are working properly, etc.

(b) Very Bad Quality S/W

 When there are too many critical and blocker defects.

 The product is not ready.
 The features are not ready, etc.

(12) Test Automation

In this stage, we will decide the features which can be automated (the feature should not be
manual).
In this stage, we will decide and which stages we will start automation testing:

 Which automation test framework we are going to use.

 Which automation tool and language we are using, etc.

(13) Defect Severity

In this stage, we will decide all the severity and the priority of the defects found during
testing.

Here we decide the levels of Severity:

 Blocker
 Critical
 Major
 Minor

Here we decide the levels of Priority:

 High
 Medium
 Low

(14) Test Environment

In this stage, we will check all the hardware and software which needs to be in place in the
test environment.

How to establish or host a copy of the production environment, given by the customer, and
create all the necessary changes.

Necessary changes mean all the stakeholders involved and services which need to be added
or modified in the test environment.

(15) Deliverables
In this stage, we list all the documents which are to be delivered to the customer, along with
the S/W.

Some of these deliverables are:

1. Test Plan
2. Test Scenarios
3. Test Execution Report
4. Traceability Matrix
5. Release Notes
6. Graphs and Charts
Release notes: An automated written document that contains the instructions and list of steps
to install the S/W in the production environment.

(16) Roles & Responsibility

In this stage, we will decide the detailed roles of all the test engineers working in the project
and we will decide the responsibilities covered by each test engineer.

In this stage, we will also decide the tasks and activities which are to be completed by the
responsible test engineer.

(17) Templates
In this stage, we will decide the outlines of all the documents and formats of the documents
which we will be following in that project.

Agile Methodology
It is a step-by-step procedure to develop a software.
It is an incremental and iterative process of software development.
It was designed to overcome the drawbacks of traditional model (waterfall model) of
developing. The aim of agile model is to deliver the project quickly.
The agile model was developed for the SDLC (Software Development Life Cycle).

All the people involved in developing the S/w in the project of agile model are called Scrum
Team.

Scrum Team can be categorized into:

1. Core Team
2. Shared Team

Core Team

 S/w engineers
 Test engineers
 Team lead
 Scrum master

Shared Team
  Business Analyst (BA)
 Product Architect
 UI/UX designer
 Database Engineer
 Product Owner

The head of the entire Scrum Team is called a Scrum Master.

He will be responsible for the core team as well as shared team.

Core team consists of: Scrum master, development engineers, test engineers.
Shared team consists of: BA, product architect, UI/UX designer, database engineer, product
owner.

Product Owner

 He is a person who acts as a customer.

 He is either from the customer side or from the company itself.
 He is the one who will decide the acceptance criteria for the product.

Product Backlog

 It is the prioritized list of stories which is to be developed in the complete project.

 Generally, Product Owner + Customer + Business Analyst create product backlog.
 The stories in product backlog need not be detailed.

Sprint Planning Meeting

 Here, the entire team chooses the stories and tasks to be done from the Product
Backlog.
 The Scrum Master will assign each story for development to team members.
 The development engineers and Test engineers will estimate the duration to complete
that feature.
 Sprint planning meeting usually completed within time box (max 8 hrs).

Sprint Backlog

 It is a prioritized list of the stories which are to be completed during the sprint and is
created during Sprint Planning.
 It is prepared by the entire Scrum team.
Daily Stand-up Meeting (Daily Scrum)

 Conducted every day during the sprint.

 Happening before starting the work, the entire Scrum team meets.
 It is usually done within 15–20 minutes.
 Three main questions will be asked:
1. Tasks that were completed yesterday.
2. Hurdles/problems faced by doing tasks yesterday.
3. Tasks for the planning of the day.
 Hurdles/problems faced yesterday will be tracked.
 Each engineer will speak about these points in front of the team.
 Scrum Master will not be in charge of this meeting.
 If Scrum Master has any problem faced by engineers, outside the meeting he will do it
on spot.

 The problem will take longer time to solve than to resolve → make a note of it in the
Impediment Backlog.

Retrospective Meeting

 After the release, the Scrum team meets and discusses whether the good process
followed and will tell the problems (if any) so that they can be corrected quickly.
 Each member makes a note of all these points and finalizes them by a document
called a retrospect document.
 Before starting the next sprint, we will look at the retrospect document and ensure that
all the best practices that were followed in the previous sprint and the good practices
were followed in the coming sprint too.

Employee Story Point Pending Story Point Ongoing tory Point Completed
Supreme 3 5 4
Ajith 1 2 1
Suriya 5 2 4
Ramesh 2 4 1
Kamlesh 3 1 2

Story Point

 It is the estimated time taken to complete a task or story.

Chicken
  It is the person who will observe how the entire scrum process is working; they will
not be doing any tasks.

Traceability Matrix

 It is the document which ensures that each & every requirement has got at least one
requirement.
 Requirement Table (Example)

Requirement Detailed Requirement Tester Name

9.1 Login button [Link]
9.2 Registration [Link]
10 Name [Link]

 It is also called a Cross Reference Matrix (CRM) and Requirement Traceability
Matrix (RTM).

Forward Traceability

 Starting from the first requirement and going all the way to end of requirement and
forcing it with test case document is called forward traceability matrix.

Backward Traceability

 Starting from the end requirement and tracing it until the first requirement is called
backward traceability matrix.

Bi-Directional Traceability

 Starting from anywhere in between or covering from both the ends of the requirement
from start to last.