What is Static Testing?

Static testing is a term in which the software is tested without executing the code. Code, process specifications, system architecture specifications, or other work products are evaluated through manual examination, automated tools, or both. Test objectives include improving quality, detecting defects, and assessing characteristics like readability, completeness, correctness, testability, and consistency. Static testing can be applied for both verification and validation.

Value of Static Testing

Static testing is a cost-effective way to find defects early in the software development lifecycle. It can help identify defects before they become more expensive (time and resources). Static testing provides the ability to evaluate the quality of, and to build confidence in work products. By some actions such as reviewing the documents, inspecting, the stakeholders can also make sure that these requirements describe their actual needs and shared understanding can be created among the involved stakeholders. Communication will also be improved between the involved stakeholders. For this reason, it is recommended to involve a wide variety of stakeholders in static testing.

Typical defects find through Static Testing

Defects in requirements/documentations:

• Missing requirements that were not captured during the requirements gathering phase (informal meetings, small talks)
• Ambiguous requirements that can be interpreted in multiple ways
• Contradictory requirements that conflict with each other (e.g., one requirement that notifies the user of a success in green color, while another defines the same notification in blue color)
• Incomplete requirements that do not provide enough detail for implementation
• Incorrect requirements that do not accurately reflect the intended functionality (e.g., a requirement that states a feature is for display purposes only, but it also mentions that the user should be able to share and apply an approval process)
• Redundant requirements that duplicate other requirements or are unnecessary
• Outdated or missing documentation (e.g., old API references, deprecated features, missing user guides)
• Objectives/Goals that are not clear, measurable, or testable

Design defects:

• Inconsistent design that does not follow the established architecture or design patterns (e.g., using different naming conventions for similar components, or using different colors for similar actions)
• Incorrect design that does not meet the requirements or violates constraints (e.g., using a third-party library that is not allowed by the project's licensing agreement)

Coding defects:

• Syntax errors that prevent the code from compiling or executing (e.g., missing semicolons, mismatched parentheses)
• Logic errors that produce incorrect results or unexpected behavior (e.g., using the wrong operator in a conditional statement, or wrong data type)
• Unclear naming conventions that make it difficult to understand the purpose of variables, functions, or classes (e.g., using single-letter variable names, or using abbreviations that are not well-known)
• Inefficient code that consumes more resources than necessary (e.g., nested loops)
• Inconsistent coding style that makes the code difficult to read and maintain (e.g., mixing tabs and spaces for indentation, or using different casing for variable names, or using different format code tools)

References

• ISTQB - Certified Tester Foundation Level (CTFL) Syllabus