✅ What is Test-Driven Development (TDD)?
Test-Driven Development means writing tests before writing actual code.
First, you create a test that fails, then you write code to make it pass. This helps developers
find mistakes early and build better quality software.
🔁 TDD Cycle (Red – Green – Refactor)
TDD follows three simple steps:
🔴 Red: Write a test and run it. It should fail because the feature is not built yet.
🟢 Green: Write minimum code to pass the test.
●
🔵 Refactor: Improve the code without changing its behavior.
●
●
This cycle keeps the code clean and correct.
📌 Three Rules of TDD
1. Don’t write code unless a test fails first.
2. Write only enough test to make it fail.
3. Write only enough code to pass the test.
These rules help developers focus and avoid unnecessary code.
🧮 Example (Calculator)
In the report, a calculator example is shown.
First, a test is written to check addition. The test fails.(RED)
# test_calculator.py
import unittest
# Step 1: create a simple Calculator class
class Calculator:
def add(self, a, b):
return a + b
# Step 2: create a test for addition
class TestCalculator([Link]):
def test_add(self):
calc = Calculator()
[Link]([Link](2, 3), 5) # 2 + 3 should be 5
# Step 3: run the test
if __name__ == "__main__":
[Link]()
Then code is written to make the test pass. (GREEN)
# [Link]
class Calculator:
def add(self, a, b):
return a + b
This ensures every feature works correctly and is tested.
🌟 Benefits of TDD
✔️ Finds bugs early
✔️ Improves code quality
●
✔️ Makes software easier to maintain
●
✔️ Acts like documentation (tests explain how code works)
●
✔️ Makes changes safer (tests catch errors)
●
✔️ Reduces debugging time
●
●
Studies show TDD reduces errors by up to 40–90%.
⚠️ Challenges of TDD
⏳ Takes more time in the beginning
📚 Needs practice to learn
●
🧪 Tests must be maintained
●
❌ Not suitable for every project (UI, prototypes, etc.)
●
👥 Team members may resist change
●
●
🛠️ Best Practices
● Write small and clear tests
● Keep tests independent
● Run tests fast
● Refactor regularly
● Balance unit, integration, and system tests
🏁 Conclusion
TDD helps build high-quality, reliable software by testing early instead of fixing bugs later.
Although it needs time and practice, it saves effort in the long run and improves confidence
in the code.
Testing Stages (in easy words):
Unit Testing
Unit Testing checks small parts of the software, like a single function or module, to make
sure it works correctly. Developers usually do this.
Integration Testing
Testing how different pieces of the software work together after being combined.
System Testing
Testing the entire software as one complete system to check if it meets all requirements.
Acceptance Testing
Final testing by users or clients to confirm the software is ready for real use.
Alpha — Done by internal teams.
Beta — Done by real users outside the company before final release.
Test Case (in easy words):
A test case is a set of steps used to check whether a software feature works correctly or
not.
It tells:
● What to test
● How to test
● What result is expected
Parts of a Test Case:
1. Test Case ID – unique number
2. Test Description – what is being tested
3. Preconditions – things needed before testing
4. Test Steps – actions to perform
5. Test Data – input values
6. Expected Result – what should happen
7. Actual Result – what actually happened
8. Status – Pass / Fail
Black Box Testing
Black box testing is when the tester does not know the internal code. The focus is only on
checking if the software works correctly with given inputs and expected outputs, like testing a
login form with username and password.
White Box Testing
White box testing is when the tester knows the internal code. It focuses on testing the logic,
loops, and paths in the code to ensure everything works as intended.
Gray Box Testing
Gray box testing is a mix of black and white box testing. The tester knows some parts of the
system, allowing them to test functionality with partial knowledge of the internal structure.
Equivalence Class Partitioning Testing
✅
“Equivalence Class Partitioning: Divide input values into valid and invalid groups, then test
one value from each group.”
Boundary Value Testing
Boundary Value Testing is testing inputs at the edges , including minimum, maximum, inside
and outside limits .”
Example
If a form accepts ages 18 to 60, you test the edges: 17, 18, 60, 61 to check if the system
handles minimum, maximum, and out-of-range values correctly.
Fuzzy Testing (Fuzz Testing)
Fuzzy Testing, or Fuzz Testing, is a technique where random or unexpected inputs are
given to a program to find bugs, crashes, or security vulnerabilities.
Example
A login form expects a username of 5–15 letters. In fuzzy testing, instead of normal names,
the tester might enter random inputs like @@##$$, 1234567890abcdef, or leave it blank.
The goal is to see if the system crashes or handles these unexpected inputs safely.
Omission Testing
Omission testing checks whether a system works correctly when certain parts are missing or
intentionally left out.
Example: What if a user submits a form without filling a required field?
Comparison Testing
Comparison testing (also called comparative testing) is testing two or more products
side-by-side to compare their performance, features, behavior, or quality.
Example: A new calculator app is tested against a standard calculator by performing the
same calculations to see if both give the same results.
End-to-End Testing
End-to-End Testing (E2E Testing) is a method where you test the entire software application
from start to finish in a real-world scenario.
Example: For an online shopping website, end-to-end testing would cover searching a
product, adding it to the cart, making payment, and receiving an order confirmation to
ensure the entire process works smoothly.
Localization Testing
Localization Testing is testing a software application to make sure it is properly adapted for a
specific country, region, or language.
Example:
Testing a travel website for Japan would involve checking:
Globalization Testing
Globalization Testing (also called Internationalization Testing or "i18n" testing) is making sure
a software application is designed and built to work easily in any language, region, or
culture, without needing major changes.
Example
Testing if the software can display Arabic text (right-to-left).
Error Handling Testing
Error Handling Testing is a type of testing that checks how a software application responds
to errors or unexpected situations. The goal is to make sure the system doesn’t crash
and gives useful error messages when something goes wrong.
Example
Entering a password that’s too short
Sandwich Testing
Sandwich Testing is a hybrid Integration Testing strategy that combines Top-Down and
Bottom-Up approaches.
What is Debugging?
Debugging is the process of finding and fixing errors or bugs in a software program to
make it work correctly. It is done after testing when a problem or unexpected behavior is
found.
Steps of Debugging
1. Identify the Bug: Notice and understand the error or unexpected behavior.
2. Reproduce the Problem: Run the program to see the bug in action.
3. Locate the Source: Find the part of the code causing the problem.
4. Analyze the Cause: Understand why the bug is happening.
5. Fix the Bug: Correct the code or logic causing the error.
6. Test the Fix: Run the program again to make sure the bug is resolved and nothing
else is broken.
Methods of Debugging
1. Debugging by Brute Force Attack: This method involves checking all parts of the
program one by one to find the bug. It is simple but can be time-consuming.
2. Debugging by Induction: In this method, the debugger starts from a part that
works correctly and moves forward step by step to find where the error occurs.
3. Debugging by Deduction: This method starts from the observed problem and
works backward to find the cause of the bug.
4. Debugging by Backtracking: The program is traced backward from where the
error occurs to locate the source of the bug.
5. Debugging by Testing: Bugs are found and fixed by repeatedly running the
program with different test cases to see where it fails.
Aspect Testing Debugging
Purpose To find errors in the software To fix the errors found
Process Running the program and checking Analyzing code and correcting
results mistakes
Who Testers Developers
Performs
Timing Before debugging After testing
Focus Detecting bugs Solving bugs
What is a Bug?
A bug is an error, flaw, or defect in a software program that causes it to behave
unexpectedly or produce incorrect results. Bugs can occur due to coding mistakes, logic
errors, missing requirements, or incorrect inputs.
Example: A login form allows a user to log in without entering a password — this is a bug.
Bug Lifecycle
The Bug Lifecycle is the process a bug goes through from discovery to closure. The
main stages are:
1. New: Bug is reported for the first time.
2. Assigned: Bug is assigned to a developer to fix.
3. Open/Working: Developer starts analyzing and fixing the bug.
4. Fixed: Developer corrects the bug in the code.
5. Retest: Tester tests the software to check if the bug is fixed.
6. Verified: If the bug is fixed, it is verified by the tester.
7. Closed: Bug is resolved and no longer exists in the software.
8. Reopened (if needed): If the bug still exists after fixing, it is reopened and the cycle
repeats.
💡 Tip to remember: New → Assigned → Fixed → Retest → Verified → Closed (or
Reopened)
CMMI Model (Capability Maturity Model Integration)
The CMMI model is a framework for improving and measuring the maturity of software
development processes in an organization. It helps organizations deliver high-quality
software consistently by following defined processes and continuously improving them.
CMMI has five maturity levels:
1. Level 1 – Initial: Work is done without proper planning. Success depends on
individual effort and things are often chaotic.
2. Level 2 – Managed: Projects are planned and managed. Basic rules are followed
and past experience is used.
3. Level 3 – Defined: Everyone follows the same fixed and written process in the
organization.
4. Level 4 – Quantitatively Managed: Work is checked using numbers and data to see
how good it is.
5. Level 5 – Optimizing: The organization keeps improving its way of working to get
better results.
Process Improvement (PI) in Software Quality Engineering:
Process improvement is about finding problems in how work is done and fixing them to
get better results.
Stages of Process Improvement Cycle (easy words):
1. Process Measurement
Attributes of the current process are measured.
These measurements act as a baseline for evaluating future improvements.
2. Process Analysis
The current process is carefully examined to identify bottlenecks, weaknesses, and
problem areas.
3. Process Change
Improvements and changes identified during analysis are implemented to enhance
the process.
Process Measurement (in easy words)
Process measurement is the activity of measuring how well a process is working by
using numbers and data. It helps an organization understand the current performance of a
process and decide where improvement is needed.
Techniques of Process Analysis (easy words)
Questionnaires and Interviews:
Workers are asked questions about how work is done. Questionnaires are used first, then
interviews are done for better understanding.
Ethnographic Analysis:
The process is understood by watching people while they work. It is useful for studying
small parts of a process in detail.
Process Change Stages (easy words)
Improvement Identification:
First, problems and weak areas in the current process are identified where improvement is
needed.
Improvement Prioritization:
Next, the most important improvements are selected first based on impact and urgency.
Process Change Introduction:
Then, the selected changes are introduced and applied to the process.
Process Change Training:
After that, people are trained so they understand and can correctly follow the new process.
Change Tuning:
Finally, the changed process is adjusted and fine-tuned based on feedback and results to
make it work better.
Easy to remember:
Find → Choose → Apply → Train → Improve
