Static Testing and Dynamic Testing

Static Testing and Dynamic Testing
Static Testing and Dynamic Testing

A software application is not just written and released overnight. Every feature, every requirement, every piece of code, and every user interaction must be carefully examined before the software reaches customers. If errors are found late, fixing them often becomes expensive and time-consuming.

This is where software testing plays a very important role.

Testing is not only about clicking buttons after the application is developed. In reality, testing starts much earlier. Even before developers execute the program, many defects can already be identified by carefully reviewing documents, requirements, designs, and source code.

This early verification is known as Static Testing.

Once the software is developed, testers execute the application to verify whether everything works as expected. This practical verification is known as Dynamic Testing.

Non-execution-based testing is called as Static Testing.

Static Testing is the process of verifying software documents, design, requirements, or code without executing the application.

Instead of running the software, the testing team carefully examines project documents, requirement specifications, design documents, user stories, source code, and other development artifacts to identify defects as early as possible.

The main objective of Static Testing is to detect mistakes before coding is completed or before the application is executed.

Think of it like proofreading a book before it gets printed. You read every page carefully to identify grammar mistakes, spelling errors, missing paragraphs, or incorrect information. You do not need to print thousands of copies before discovering these issues.

Static Testing consists of several review techniques.

Each technique has a different purpose.

This is the simplest review method.

One team member casually reviews another person’s work.

There is no predefined process, checklist, or meeting.

It is commonly used for small changes or quick validations.

Example:

A tester asks another tester to quickly verify a few test cases before execution.


A walkthrough is led by the author of the document.

The author explains each section while team members ask questions and suggest improvements.

The goal is knowledge sharing along with defect detection.

Example:

A Business Analyst explains the SRS document to developers and testers before development begins.


Technical experts evaluate the document from a technical perspective.

Participants may include:

  • Developers
  • Architects
  • QA Leads
  • Database Engineers

The focus is on identifying design flaws and technical issues.


Inspection is considered the most formal review technique.

It follows a structured process.

Each participant has predefined responsibilities.

A moderator controls the meeting.

Defects are documented, analyzed, and tracked until closure.

Inspection generally finds more defects than other review techniques.

Execution-based testing is called as Dynamic Testing.

Reviewing requirements, design documents, or source code helps identify many issues early, but it cannot guarantee that the application will behave correctly when real users interact with it. To gain that confidence, the software must actually be executed.

This process is called Dynamic Testing.

Dynamic Testing is a software testing technique in which the application is executed using test data. The tester interacts with the software, performs different operations, observes the results, and compares the actual behavior with the expected behavior.

Unlike Static Testing, which focuses on preventing defects before execution, Dynamic Testing focuses on finding defects while the software is running.

A simple example is a login page. During Static Testing, a reviewer may verify whether the login requirements are documented correctly and whether the code follows coding standards. During Dynamic Testing, the tester opens the application, enters valid and invalid usernames and passwords, clicks the Login button, and checks whether the application responds correctly.

Dynamic Testing gives confidence that the software works as expected in real-world situations. It helps uncover issues that cannot be identified by reviewing documents or source code alone, such as incorrect calculations, broken links, validation failures, slow performance, or unexpected system crashes.

Everything begins with a well-defined test plan.

At this stage, the QA team studies the Software Requirement Specification (SRS), understands the application’s functionality, identifies testing objectives, estimates the required effort, and prepares the testing schedule.

The team also decides:

  • What features need to be tested
  • Which testing techniques will be used
  • What resources are required
  • Who will perform the testing
  • What tools will be used

A good test plan acts like a roadmap for the entire testing activity.

Once the planning is complete, testers create detailed test cases.

A test case describes:

  • Preconditions
  • Test steps
  • Input data
  • Expected result
  • Actual result
  • Test status

Well-written test cases ensure that every functionality is verified consistently, even when different testers execute them.

Before execution begins, the application must be deployed in a suitable testing environment.

The environment generally includes:

  • Application Server
  • Database Server
  • APIs
  • Network Configuration
  • Test Accounts
  • Required Software Versions

If the testing environment does not match the production environment, certain defects may remain unnoticed.

This is the most visible stage of Dynamic Testing.

Testers execute each test case one by one.

They compare:

Expected Result

with

Actual Result

If both match, the test case passes.

If they differ, a defect is reported.

Whenever a defect is found, it is logged into a defect management tool such as:

  • JIRA
  • Azure DevOps
  • Bugzilla
  • Redmine

A defect report generally contains:

  • Defect ID
  • Summary
  • Steps to reproduce
  • Expected Result
  • Actual Result
  • Severity
  • Priority
  • Screenshots
  • Environment Details

A well-written defect report helps developers reproduce and fix the issue quickly.

  • Functional Testing
  • Non-Functional Testing
  • Black Box Testing
  • White Box Testing
  • Gray Box Testing

Although both techniques aim to improve software quality, their approaches are completely different.

The following table highlights the major differences.

FeatureStatic TestingDynamic Testing
Application ExecutionNot RequiredRequired
ObjectivePrevent defects earlyFind defects during execution
Performed OnDocuments, Requirements, CodeRunning Software
Main FocusVerificationValidation
Defect Detection StageEarly SDLCLater SDLC
CostLowerHigher
Execution SpeedFasterSlower
AutomationRareCommon
Coding RequiredNoDepends on testing type
Detects Performance IssuesNoYes
Detects UI IssuesNoYes
Detects Runtime ErrorsNoYes
ParticipantsBA, QA, DevelopersQA, Users, Developers
ExamplesReviews, Walkthroughs, InspectionsFunctional Testing, Non-Functional Testing

Static and Dynamic Testing are not isolated activities. They complement each other throughout the Software Development Life Cycle (SDLC).

During the Requirement Analysis phase, business analysts and testers review requirement documents to ensure they are clear, complete, and testable. This is an example of Static Testing.

In the Design Phase, architects and developers review system architecture, database designs, and user interface wireframes. Again, this is Static Testing.

During the Development Phase, developers perform code reviews and peer reviews to identify coding issues before execution.

Once development is complete, Dynamic Testing begins. Testers execute the application, verify functionality, report defects, and perform regression testing until the software is ready for release.

By combining both approaches, organizations can deliver high-quality software while reducing overall project costs.

Static Testing and Dynamic Testing are both essential for delivering high-quality software. Static Testing helps identify defects early by reviewing requirements, designs, and code without executing the application, while Dynamic Testing verifies that the software works correctly by running it in real-world scenarios.

Together, these testing techniques improve software quality, reduce development costs, and enhance user satisfaction. For anyone learning Manual Testing, understanding when and how to use both approaches is a fundamental skill that will be valuable in interviews as well as real-world software projects.

What is the difference between Static Testing and Dynamic Testing?

Static Testing reviews documents and code without executing the application, whereas Dynamic Testing involves running the software to verify its actual behavior.


Is Static Testing part of Manual Testing?

No. Static Testing is a testing technique, not a testing type. It can be performed manually through reviews and inspections without executing the application.


Which testing is more cost-effective?

Static Testing is generally more cost-effective because it identifies defects early, reducing the effort required during later stages of development.


Can developers perform Static Testing?

Yes. Developers frequently perform code reviews, peer reviews, and technical reviews as part of Static Testing.


Why is Dynamic Testing important?

Dynamic Testing verifies that the software functions correctly under real-world conditions and helps identify runtime defects that cannot be detected through reviews alone.


Is Dynamic Testing always manual?

No. Dynamic Testing can be performed manually or through automation tools. The defining characteristic is that the software is executed.

Click here for more on Software Testing

ISTQB Foundation Level Syllabus
https://istqb.org/certifications/certified-tester-foundation-level/

Leave a Comment

Your email address will not be published. Required fields are marked *