Software Testing Functional Testing

Functional testing checks whether each feature of the software works correctly according to its specified requirements. It answers one question: does this function do what it is supposed to do?

Functional vs Non-Functional Testing

  FUNCTIONAL                    NON-FUNCTIONAL
  ──────────                    ──────────────
  Does the login work?          How fast does the login load?
  Does the cart calculate       Can the cart handle
  the total correctly?          10,000 users at once?
  Does the email send?          Is the email secure?

  → Checks WHAT the            → Checks HOW WELL the
    software does                 software performs

Functional testing is about behaviour. Non-functional testing is about performance, security, and reliability.

Types of Functional Testing

Smoke Testing

A quick, high-level check to see if the most basic features work after a new build is deployed. If the smoke test fails, the build is rejected and the team does not proceed with more detailed testing.

  Smoke Test for a Messaging App:
  ──────────────────────────────
  ✔ App opens without crashing
  ✔ User can log in
  ✔ User can send a message
  ✔ User can log out

  If any of these fail → Build is sent back to developers

Sanity Testing

A focused check performed after a bug fix or a small change, to verify that the specific area that was fixed now works correctly. It is narrower than a full regression test.

  Developer fixed: "Cart total not updating after coupon applied"

  Sanity Test:
  ✔ Apply coupon → Verify total updates correctly
  ✔ Remove coupon → Verify original total restores

  (Only the fixed area is tested, not the whole app)

Regression Testing

After any change to the code, regression testing re-runs previously passing test cases to ensure new code did not break existing features. This is covered in depth in a later topic.

Integration Testing

Tests that verify multiple modules or services work correctly when connected together. Integration testing catches bugs that only appear when components interact.

User Acceptance Testing (UAT)

The final phase of testing performed by the actual business users or clients to verify that the software meets their real-world needs before they approve it for release.

The Functional Testing Process

  1. Read the requirement
         |
         v
  2. Identify what inputs the feature accepts
         |
         v
  3. Identify what outputs or actions are expected
         |
         v
  4. Write test cases covering valid, invalid, and edge inputs
         |
         v
  5. Execute tests and compare actual vs expected results
         |
         v
  6. Log any failures as bugs

Functional Testing Example: Registration Form

Requirement: "Users must be able to register with a valid email and a password of at least 8 characters."

  TEST ID  INPUT                          EXPECTED RESULT
  ───────  ─────                          ───────────────
  TC01     Valid email + 8-char password  Registration succeeds
  TC02     Valid email + 5-char password  Error: "Password too short"
  TC03     Invalid email + valid password Error: "Invalid email format"
  TC04     Already-used email             Error: "Account already exists"
  TC05     Both fields empty              Error on both fields
  TC06     Email with spaces              Error: "Invalid email format"

Functional Testing Tools

  • Selenium: Automates browser interactions for web application functional testing.
  • Postman: Tests API endpoints by sending requests and verifying responses.
  • TestComplete: A commercial tool for automating functional tests across web, mobile, and desktop.
  • Katalon Studio: An all-in-one tool for web, mobile, and API functional testing, requiring minimal coding.
  • Cucumber: Allows functional tests to be written in plain English using the Gherkin language.

Writing a Functional Test in Plain English (Gherkin Style)

  Feature: User Login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters "user@test.com" as email
    And the user enters "Pass@1234" as password
    And the user clicks the "Login" button
    Then the user should be redirected to the dashboard
    And the header should display "Welcome, User"

This format is readable by developers, testers, and business stakeholders, which makes it a powerful communication tool in cross-functional teams.

Previous lessons
Back to courses
Next lessons

Leave a Comment