What is Software Testing? - QA Concepts

Software testing is a part of the software development process.

It is an activity aimed at identifying bugs in software.

The objective is to release a quality product to the client and to ensure the client of the application's correctness and completeness, i.e., that the software is working correctly against the requirements.

Advertisement

What is Software Quality?

Software quality is when the software works as per requirement and is bug-free.

It is the degree of excellence of something (a measure of how good it is).

What Defines Software Quality?

  • Bug-free
  • Delivered on time
  • Within budget
  • Meeting the customer's requirements and expectations
  • Maintainable

QA vs QC

QA (Quality Assurance)

Orientation

  • Process-oriented

Nature

  • Proactive process

Focus

  • Preventing defects

Timing

  • During development

Responsible For

  • SDLC

Example

  • Verification

QC (Quality Control)

Orientation

  • Product-oriented

Nature

  • Reactive process

Focus

  • Identifying or detecting defects

Timing

  • After QA

Responsible For

Example

  • Validation

QA works with the development team to produce quality software and ensures that approaches and techniques are implemented correctly.

QC comes into the picture after QA and verifies that the developed project meets the defined quality standards.


Objectives of Software Testing & Why Testing is Necessary

Objectives

  • To prevent defects.
  • To identify defects created by the programmer during software development.
  • To help ensure a quality product.
  • To ensure the software satisfies the BRS and SRS.
  • To ensure the result meets business and user requirements.

Why Testing is Necessary

  • We all make mistakes. Some are trivial, but some are expensive or life-threatening.
  • Testing discovers defects before delivery to the client.
  • It guarantees software quality.
  • It makes the software more reliable and easier to use.
  • It ensures high-performance operation.

Testing vs Debugging

Testing

Testing identifies bugs in the software.

It is performed by the testing team.

Debugging

Debugging is what the development team does after receiving the testing team's report.

It involves:

  • Locating the bug.
  • Removing it from the software.

It is:

  • A one-off process.
  • Done manually.

It uses a special tool called a Debugger.

Popular debugger tools include:

  • WinDbg
  • OllyDbg
  • IDA Pro

Reviews and Their Types

A review of documents conducted by two or more people is carried out to find bugs in the early stages of the SDLC and ensure correctness and completeness.

Reviews verify documents such as:

  • Requirements
  • System Designs
  • Code
  • Test Plans
  • Test Cases

Code Review

Examining the source code of the software to find and remove bugs.

Pair Programming

A type of code review involving two people who develop code together at the same workstation.

Inspection

A formal type of review where a person follows a defined set of instructions to find defects.

Peer Review

An informal review done by your colleagues.


Key Testing Principles

Pesticide Paradox

If already-prepared test cases stop finding defects, we have to add or revise test cases to find more defects.

Early Testing

Conducting testing as early as possible in the development life cycle to find defects at early stages, which reduces the cost of fixing them later.

Exhaustive Testing

A technique in which the testing team tests all possible input combinations, covering every scenario so the application does not crash.

It makes the application more robust but is generally not feasible for everything.

Risk-Based Testing

Identifying the critical functionality in the system, prioritizing test cases accordingly, and then executing them.

Visual Testing

Evaluating the visible output of an application and comparing it against the results expected by design.

Example:

On a web page, text wrapped over an advertisement is a visual bug.


When Should We Stop Testing?

  • When the application functionality looks stable.
  • When no important or major defects remain.
  • When all defects are fixed before release.
  • When the exit criteria of the test execution phase are met.

Testing Metrics & Test Estimation

Software Testing Metrics

Quantitative measures are used to estimate:

  • Progress
  • Quality
  • Productivity
  • Health of the testing process

Their goal is to:

  • Improve efficiency and effectiveness.
  • Help make better decisions by providing reliable data.

Test Estimation

A management activity that approximates how long a task would take to complete.


Risk Analysis, Root Cause Analysis & Impact Analysis

How to Conduct Risk Analysis

  • Find the score of the risk.
  • Make a profile for the risk.
  • Change the risk properties.
  • Deploy the resources for that test risk.
  • Make a database of risk.

Root Cause Analysis (RCA)

Finding the exact cause of a defect (from where it is occurring) in a systematic way to eliminate the problem.

Without RCA, the same problem can recur.

Impact Analysis

When a developer keeps changing the application code during development, those changes can impact other modules.

Example:

If the developer changes the login functionality code, the register module or other modules may be affected.

So we analyze which modules are impacted by the code changes.


GUI Testing, Data-Driven & Keyword-Driven Frameworks

GUI Testing

Checks the Graphical User Interface (GUI) of the software to ensure functionality works as per specifications by verifying screens and controls such as:

  • Menus
  • Buttons
  • Icons

It focuses on the front end:

  • Look and feel
  • Design structure
  • What the user sees

The user does not see the source code.

How to Do GUI Testing

  • Check that images are fully visible across browsers.
  • Check that links are available.
  • Verify buttons work when clicked.
  • Verify that when the user resizes the screen, neither images nor content shrink, crop, or overlap.

Data-Driven Testing

A methodology where a test's input and output values are separated from the code.

Test scripts read data from data files such as:

  • Data Pools
  • CSV Files
  • Excel Files
  • ADO Objects
  • ODBC Sources

Keyword-Driven Framework

A framework created by a technical person and then given to non-technical people without programming knowledge.

The technical team creates an Excel file with keywords.

Using these keywords, non-technical people can run automation scripts based on their business knowledge.


Sign-Off / Summary Report

Created by the testing team.

It is used formally to declare the completion of testing.

It provides the team's approval or judgment for releasing the software to the market.

It contains:

  • Overall testing summary
  • Test execution status
  • Defect summary
  • Quality status

Based on the overall quality and exit criteria, the testing team provides a final recommendation on whether to release or reject the software.


Software Testing Glossary

Estimation

Providing the time to finish specific work.

Project

Requirements come from one customer and are mostly used by that customer and their people.

Product

Requirements come from various customers and are used by many customers.

Application

A group of programs designed for customers to use for specific operations.

AUT (Application Under Test)

After the design and coding phase, the application (build) that comes for testing.

Quality

Justification of the requirements and the absence of defects, delivered on time.

Defect

A deviation from the requirement.

SRS

System Requirement Specification.

The actual requirement document.

Mock-Ups

Sample screens or replicas of the actual application provided to the team during the design or requirement phase.

Use Case

Describes:

  • Basic flow
  • Alternate flow
  • Exceptional flow

of how the application will be processed.

Written by Business Analysts from the Functional Requirements Document.

It serves as a basis for:

  • Developers (to write code)
  • Testers (to write test scenarios and test cases)

Test Case

A step-wise description of activities executed to validate the application.

It includes:

  • Step number
  • Description
  • Input data
  • Expected result
  • Actual result

Prepared by the testing team.

Test Data

The data used in tests.

It can be:

  • Entered manually using Excel.
  • Read automatically from XML files.
  • Flat files.
  • Databases.

Automation tools can also use this data.

Version Control

A system that records changes to a file or set of files over time so you can recall specific versions later.

Release Notes

A document prepared by the development team at release time and delivered to customers.

It contains technical information about changes in the current release.

Build

A version of the software given to the testing team for testing.

A release usually contains multiple builds.

The software is still in the testing phase.

Release

Software that is no longer in the testing phase and is ready to deliver to the customer.

Delivery

Handing over the working software to the customer on or before the delivery date.

Code Freeze

Finalization of code.

Once finalized, no further changes are allowed.

Deployment

The mechanism or process through which the software is made available for use.

Primary Key

A column (or set of columns) that uniquely identifies each record in a table.

Tester's Daily Activities

  • Attend the daily stand-up.
  • Check emails.
  • Check Jira.
  • Check assigned tasks.
  • Understand requirements and user stories.
  • Prepare or update test cases.
  • Perform Smoke Testing on the latest build.
  • Execute assigned test cases.
  • Log defects with steps, screenshots, severity, and priority.
  • Perform retesting for fixed defects.

Verifying an Email Address Field

Verify that it:

  • Accepts only valid email formats.
  • Rejects invalid email formats.
  • Shows mandatory-field validation when left blank.
  • Handles leading and trailing spaces correctly.
  • Accepts uppercase and lowercase characters.

FAQs

1. What is the difference between QA and QC?

QA

  • Process-oriented.
  • Proactive.
  • Focuses on preventing defects during development.
  • Example: Verification.

QC

  • Product-oriented.
  • Reactive.
  • Focuses on detecting defects after QA.
  • Example: Validation.

2. What is the difference between Testing and Debugging?

Testing

Identifies bugs and is performed by the testing team.

Debugging

Locates and removes bugs and is performed by the development team.


3. What is the Pesticide Paradox?

When existing test cases stop finding new defects, you must add or revise test cases to uncover more defects.


4. What is Early Testing?

Conducting testing as early as possible in the development life cycle to find defects sooner and reduce the cost of fixing them later.


5. What is Risk-Based Testing?

Identifying critical functionality, prioritizing test cases accordingly, and executing them first.


6. What are the types of Reviews?

  • Code Review
  • Pair Programming
  • Inspection (Formal)
  • Peer Review (Informal)

7. What is Root Cause Analysis (RCA)?

Systematically finding the exact cause of a defect so the problem can be eliminated and does not recur.


8. What is the difference between a Build and a Release?

Build

A version of the software given to the testing team while it is still in testing.

Release

Software that has passed testing and is ready to deliver to the customer.


9. What is a Keyword-Driven Framework?

A framework built by a technical person using an Excel file of keywords.

It enables non-technical people to run automation scripts based on their business knowledge.


10. What is a Sign-Off / Summary Report?

A formal document prepared by the testing team declaring testing completion.

It contains:

  • Testing summary
  • Execution status
  • Defect summary
  • Final Release-or-Reject recommendation