3.1 Static Testing Basics

Question 1

Define static testing.

Answer 1

Software under test does not need to be executed for static testing. Code, processes specification, system architecture specification or other work products are evaluated through manual examination (e.g., reviews) or with the help of a tool (e.g., static analysis).

Question 2

What are the objectives of static testing?

Answer 2

• improving quality early
• detecting defects around readability, completeness, correctness, testability, and consistency

Question 3

Does static testing require more or less effort to find defects compared to dynamic testing?

Answer 3

Often less, since no test cases are required and tools are typically used to speed up the process.

Question 4

What work products are examined by static testing?

Answer 4

Almost any can be. Requirement specification docs, source code, test plans, test cases, product backlog items, test charters, project docs, contracts, and models are all examples.

Work products need a structure against which they can be checked to be testable in this way (formal syntax, etc).

Question 5

What value does Static Testing offer?

Answer 5

It can detect defects in the earliest phases of the SDLC, effectively shifting left and catching errors early.

It can identify defects which cannot be detected by dynamic testing, such as unreachable code, design patterns not implemented, defects in non-executable work.

Catching code defects with static analysis is more efficient and usually results in fewer code defects and lower overall dev costs and effort.

Question 6

What types of defects are easier to find through static testing?

Answer 6

• Requirements defects: inconsistencies, ambiguities, contradictions, omissions, inaccuracies, duplications
• Design defect: inefficient database structures, poor modularization
• Some coding defects: undefined variables, unreachable code, duplicated code, complex code
• Deviations from standards: poor syntax, lack of adherence to coding standards or naming conventions
• Incorrect interface specifications: mismatched number, type, or order of parameters
• Some types of security vulnerabilities: buffer overflows
• Test basis coverage gaps: missing tests, etc