Functional Testing

Functional testing checks what the software does — whether it works according to requirements. The purpose of Functional tests is to test each function of the software application by providing appropriate input and verifying the output against the Functional requirements.

It answers: “Does this feature work as expected?”

Key Points

• Focuses on functionality (not performance, not internal code).

• Based on requirements/specifications.

• Done using black-box testing (we care about input/output, not code).

Let’s use the ATM machine example:

• Insert card → Should ask for PIN.

• Enter correct PIN → Should allow withdrawal.

• Enter wrong PIN → Should show error.

• Withdraw ₹500 → Balance should reduce by ₹500.

All these are functional tests, because they check if features behave correctly.

Types of Functional Testing

1. UAT (User Acceptance Testing)

• What: Testing by the end users or clients to see if the software meets business needs.

• Goal: Is it ready for real-world use?

• Example (ATM): Bank staff test ATM: Can customers withdraw, deposit, and check balance correctly?

2. Exploratory Testing

• What: Testing without a fixed script. Testers explore the application and learn as they test.

• Goal: Find unexpected bugs by “thinking like a user.”

• Example (ATM): Tester tries weird cases — like entering symbols as PIN, pressing cancel at different steps, inserting half card, etc.

3. Sanity Testing

• What: Quick check to see if a bug fix or small change works and nothing major is broken.

• Goal: Verify specific functionality after a fix.

• Example (ATM): Developer fixes a “PIN change” bug → QA quickly checks if changing PIN now works, and ATM still allows login.

4. Regression Testing

• What: Re-running old tests to make sure new changes didn’t break existing features.

• Goal: Ensure stability after updates.

• Example (ATM): After adding a “mini statement” feature, tester checks if withdrawal, deposit, and PIN change still work.

5. Smoke Testing

• What: A basic health check to see if the system is stable enough for further testing.

• Goal: Catch showstopper issues early.

• Example (ATM): Check if ATM powers on, accepts card, asks for PIN, and responds — before doing detailed tests.

6. Unit Testing

• What: Testing the smallest piece of code (usually by developers).

• Goal: Verify individual functions/methods.

• Example (ATM): Test if the validatePin() function returns true for correct PIN and false for wrong one.

7. Integration Testing

• What: Testing how different modules work together.

• Goal: Ensure smooth data flow between modules.

• Example (ATM): Test if ATM withdrawal request → goes to bank server → updates balance → ATM dispenses money correctly.