Static White Box Testing

Static white box testing is a software testing technique where the internal structure, design,
and implementation of the software are analysed without executing the code. It is a static
analysis method, meaning it focuses on reviewing the source code, architecture, and
documentation rather than running the program.

1. No Execution of Code – The code is examined for errors, vulnerabilities, and logical
flaws without actually running it.
2. Access to Internal Code – Since it is a white-box approach, testers have complete
knowledge of the internal workings of the application.
3. Early Detection of Defects – It helps identify issues in the design, structure, and
logic of the code early in the development phase.
4. Automated or Manual – Can be performed manually through code reviews or
automatically using static analysis tools.

Techniques Used in Static White Box Testing

1. Code Reviews – Peers or experts manually review the source code to identify defects.
2. Walkthroughs – Developers explain the code logic and flow to a group for feedback.
3. Static Code Analysis – Tools like SonarQube, Checkstyle, or Coverity scan the code
for issues like security vulnerabilities, unused variables, and syntax errors.
4. Data Flow Analysis – Examines how data moves through the application to detect
issues like uninitialized variables.
5. Control Flow Analysis – Analyses the logical flow of the program to find potential
bugs or unreachable code.

Different Phases of Formal Review

Formal Review generally takes place in piecemeal approach that consists of six different
steps that are essential. Formal review generally obeys formal process. It is also one of the
most important and essential techniques required in static testing.
Six steps are extremely essential as they allow team of developers simply to ensure and
check software quality, efficiency, and effectiveness. These steps are given below:
Phases of Formal Reviews

1. Planning: For specific review, review process generally begins with ‘request for review’
simply by author to moderator or inspection leader. Individual participants, according to
their understanding of document and role, simply identify and determine defects,
questions, and comments. Moderator also performs entry checks and even considers exit
criteria.
2. Kick-Off: Getting everybody on the same page regarding document under review is the
main goal and aim of this meeting. Even entry result and exit criteria are also discussed in
this meeting. It is basically an optional step. It also provides better understanding of team
about relationship among document under review and other documents. During kick-off,
Distribution of document under review, source documents, and all other related
documentation can also be done.
3. Preparation: In preparation phase, participants simply work individually on document
under review with the help of related documents, procedures, rules, and provided
checklists. Spelling mistakes are also recorded on document under review but not
mentioned during meeting. These reviewers generally identify and determine and also
check for any defect, issue or error and offer their comments, that later combined and
recorded with the assistance of logging form, while reviewing document.
4. Review Meeting: This phase generally involves three different phases i.e. logging,
discussion, and decision. Different tasks are simply related to document under review is
performed.
5. Rework: Author basically improves document that is under review based on the defects
that are detected and improvements being suggested in review meeting. Document needs
to be reworked if total number of defects that are found are more than an unexpected
level. Changes that are done to document must be easy to determine during follow-up,
therefore author needs to indicate changes are made.
6. Follow-Up: Generally, after rework, moderator must ensure that all satisfactory actions
need to be taken on all logged defects, improvement suggestions, and change requests.
Moderator simply makes sure that whether author has taken care of all defects or not. In
order to control, handle, and optimize review process, moderator collects number of
measurements at every step of process. Examples of measurements include total number
of defects that are found, total number of defects that are found per page, overall review
effort, etc.
7. Individual Assessment: The stage prior to the official group meeting during which each
reviewer conducts an independent examination of the artefacts.
8. Meeting for Group Review: The cooperative stage in which the review panel discusses
over results, resolves conflicts and makes choices regarding the examined artifacts.
9. Finalization and Record-Keeping: Completing the formal review procedure, recording
the results and being ready for any necessary follow-up measures.
10. Metrics and Ongoing Improvement: Finding opportunities for ongoing improvement
and evaluating the success of the formal review process through the tracking and analysis
of review metrics.

What is Coding Standards and Guidelines?

Good software development organizations want their programmers to maintain to some
well-defined and standard style of coding called coding standards. They usually make their
own coding standards and guidelines depending on what suits their organization best and
based on the types of software they develop. It is very important for the programmers to
maintain the coding standards otherwise the code will be rejected during code review.

Coding Standards in Software Engineering

Some of the coding standards are given below:
1. Limited use of globals : These rules tell about which types of data that can be declared
global and the data that can’t be.
2. Standard headers for different modules : For better understanding and maintenance of
the code, the header of different modules should follow some standard format and
information. The header format must contain below things that is being used in various
companies:
 Name of the module
 Date of module creation
 Author of the module
 Modification history
 Synopsis of the module about what the module does
 Different functions supported in the module along with their input output parameters
 Global variables accessed or modified by the module
3. Naming conventions for local variables, global variables, constants and
functions: Some of the naming conventions are given below:
 Meaningful and understandable variables name helps anyone to understand the
reason of using it.
 Local variables should be named using camel case lettering starting with small letter
(e.g. localData) whereas Global variables names should start with a capital letter
(e.g. GlobalData). Constant names should be formed using capital letters only
(e.g. CONSDATA).
 It is better to avoid the use of digits in variable names.
 The names of the function should be written in camel case starting with small
letters.
 The name of the function must describe the reason of using the function clearly and
briefly.
4. Indentation: Proper indentation is very important to increase the readability of the
code. For making the code readable, programmers should use White spaces properly.
Some of the spacing conventions are given below:
 There must be a space after giving a comma between two function arguments.
 Each nested block should be properly indented and spaced.
 Proper Indentation should be there at the beginning and at the end of each block in
the program.
 All braces should start from a new line and the code following the end of braces also
start from a new line.
5. Error return values and exception handling conventions : All functions that
encountering an error condition should either return a 0 or 1 for simplifying the
debugging.

Coding Guidelines in Software Engineering

Coding guidelines give some general suggestions regarding the coding style that to be
followed for the betterment of understandability and readability of the code.
Some of the coding guidelines are given below :
1. Avoid using a coding style that is too difficult to understand: Code should be easily
understandable. The complex code makes maintenance and debugging difficult and
expensive.
2. Avoid using an identifier for multiple purposes : Each variable should be given a
descriptive and meaningful name indicating the reason behind using it. This is not
possible if an identifier is used for multiple purposes and thus it can lead to confusion to
the reader. Moreover, it leads to more difficulty during future enhancements.
3. Code should be well documented : The code should be properly commented for
understanding easily. Comments regarding the statements increase the understandability
of the code.
4. Length of functions should not be very large : Lengthy functions are very difficult to
understand. That’s why functions should be small enough to carry out small work and
lengthy functions should be broken into small ones for completing small tasks.
5. Try not to use GOTO statement : GOTO statement makes the program unstructured,
thus it reduces the understandability of the program and also debugging becomes
difficult.

Generic code review checklist

A generic code review checklist in software testing ensures that the code meets quality
standards, follows best practices, and is maintainable. It covers various aspects, including
functionality, security, performance, and coding standards.

1. Code Functionality

 Does the code meet the requirements?

 Are edge cases and error conditions handled?
 Are the inputs and outputs validated correctly?

2. Code Readability & Maintainability

 Is the code easy to read and understand?

 Are proper naming conventions followed for variables, functions, and classes?
 Is the code modular, with reusable functions and minimal redundancy?
 Are meaningful comments and documentation provided where necessary?

3. Code Efficiency & Performance

 Are there any unnecessary computations or redundant code?

 Are loops and recursive functions optimized?
 Are database queries optimized to prevent performance bottlenecks?

4. Coding Standards & Best Practices

 Is the code following the project’s style guide (e.g., Google Style Guide, PEP8 for
Python)?
 Is indentation, spacing, and formatting consistent?
 Are function and class definitions structured properly?
5. Security Considerations

 Is user input properly validated and sanitized to prevent injection attacks?

 Are API keys, credentials, and sensitive data stored securely (e.g., environment
variables, encrypted storage)?
 Is authentication and authorization implemented correctly?

6. Error Handling & Logging

 Are exceptions handled properly with appropriate error messages?

 Are logs added where necessary without exposing sensitive data?
 Is debugging information removed from the final code?

7. Compatibility & Scalability

 Is the code compatible with different environments, browsers, or platforms?

 Can the code handle increased workloads without breaking?

8. Unit Tests & Test Coverage

 Are unit tests written for all critical functionalities?

 Does the code have sufficient test coverage?
 Do the tests pass successfully without breaking existing functionality?

9. Dependency Management

 Are dependencies and third-party libraries updated and necessary?

 Are package versions locked to prevent compatibility issues?

10. Version Control & Documentation

 Are meaningful commit messages used?

 Is the code properly reviewed and merged without unnecessary conflicts?
 Is documentation updated for any changes in logic or API behavior?

What is Dynamic White Box Testing?

Dynamic White Box Testing is a testing approach where the internal structure, logic, and flow of a
software application are tested while it is running. It is used to analyze how the program behaves
under different conditions, ensuring correctness, performance, and security.

✅ Requires Code Knowledge – Testers have full access to source code.

✅ Executed at Runtime – Unlike static analysis, it runs the program to identify issues.
✅ Finds Runtime Errors – Helps detect memory leaks, logic errors, and security vulnerabilities.
✅ Used in Unit Testing, Integration Testing, and Security Testing
📝 Example: Detecting Runtime Errors (Handling Zero Division Error)

✅ We check if the program crashes when dividing by zero.

def divide(a, b):

return a / b

try:
print(divide(10, 2)) # Works fine, prints 5.0
print(divide(10, 0)) # Causes an error
except ZeroDivisionError:
print("Error: Cannot divide by zero!")

💡 What happens?

 If b = 0, Python throws a ZeroDivisionError.

 The try-except block catches the error and prints a message instead of crashing.

Dynamic White Box Testing vs Debugging

Both Dynamic White Box Testing and Debugging involve running the code and analyzing its
behavior, but they serve different purposes.

Feature Dynamic White Box Testing 🧪 Debugging 🐞

Purpose Finds errors before deployment Fixes errors after they occur

When During development &

During testing phase
Used? maintenance

Scope Tests the entire application or module Focuses on fixing specific issues

Unit testing frameworks, security scanners, Debuggers, print statements,

Tools Used
performance analyzers breakpoints

Pass/Fail results, security warnings, performance Error messages, variable states,

Output
reports execution flow

📝 Example: Dynamic White Box Testing vs Debugging in Action

🔍 Case 1: Testing for Runtime Errors (Dynamic Testing)

✅ Goal: Ensure the function doesn't crash for any input.

import unittest

def divide(a, b):

return a / b

class TestMathOperations(unittest.TestCase):
def test_division(self):
 self.assertEqual(divide(10, 2), 5) # Expected output: 5
self.assertRaises(ZeroDivisionError, divide, 10, 0) # Should handle division by zero

unittest.main()

🔹 What happens?

 The test automatically checks if the function works for all inputs.
 If an error occurs, the test fails and warns the developer before release.

🔍 Case 2: Debugging a Division Error (Fixing a Bug)

✅ Goal: Fix an error when b = 0.

def divide(a, b):

if b == 0:
print("Error: Cannot divide by zero!")
return None # Prevents crash
return a / b

print (divide(10, 2)) # Output: 5.0

print (divide(10, 0)) # Output: Error message instead of crash

🔹 What happens?

 A bug is found (division by zero crash).

 The developer fixes it manually using a condition.

🛠️Key Differences in Practice

1️⃣ Testing: Finds bugs before code is deployed.

2️⃣ Debugging: Fixes bugs after they cause an issue.
3️⃣ Testing: Uses automated tests to catch multiple issues.
4️⃣ Debugging: Uses manual steps like breakpoints and print statements.