Code Graphs: A Guide for Testers

With the increasing complexity of modern software, code graphs (or program graphs) emerge as powerful allies. They offer a visual and insightful approach to navigating the intricate logic of code.

This article delves into the world of code graphs, exploring key aspects. We'll uncover how these visual representations empower software testers in multiple ways: fostering improved communication and collaboration, enhancing efficiency and focus, providing valuable documentation, and enabling the early detection of issues. Through real-world scenarios and practical examples, we'll illustrate how code graphs can elevate our testing efforts. We will explore how they can lead to the development of robust and reliable software.

Code Graphs: Demystifying Program Flow

Code graphs are directed graphs used primarily at the unit testing level. They visually represent the flow of control within a program with the following:

• Nodes: Representing program statements or fragments
• Edges: Representing the flow of control between statements (i.e., an edge from node A to B indicates B can be executed immediately after A)

The Benefits of Graphical Representation

There are multiple benefits from graphical representation in software testing. Improved communication and collaboration, increased efficiency and focus, enhanced documentation and maintainability, early detection of issues, structured programming, and complexity management.

Improved Communication and Collaboration

A visual representation helps bridge the gap between technical and non-technical stakeholders. Testers can easily explain code flow and potential issues to managers, clients, or other team members unfamiliar with the code.

Sharing program graphs during discussions or code reviews builds better collaboration among testers and developers. This can lead to a more comprehensive understanding of the code and potential problem areas.

In an early role of mine as a software tester on a project developing a new fitness tracker app, we encountered challenges when testing a complex sleep-tracking algorithm. The algorithm analyzed sensor data to determine sleep stages (light, deep sleep) and generate sleep reports. Explaining the intricate logic with code alone proved cumbersome for non-technical stakeholders.

Here's where program graphs came to the rescue: by visualizing the algorithm's flow with decision points for different sensor readings and sleep pattern calculations, we could effectively communicate with product managers and designers. This visual representation helped them understand potential scenarios we needed to test, such as restless sleep patterns or missing sensor data. The program graph also facilitated collaboration with developers. During code reviews, referring to the graph alongside the code helped identify potential discrepancies between the intended logic and actual implementation. This collaborative approach using program graphs led to a more robust and well-tested sleep-tracking algorithm in the final fitness tracker app.

Increased Efficiency and Focus

By visualizing the structure and flow of the program, testers can identify potential test cases more efficiently. They can focus on critical paths within the graph, ensuring all essential functionalities are covered.

The visual representation helps testers quickly identify complex areas of the code. This can help to prioritize testing efforts on sections with higher risk or potential for issues.

Sarah, a software tester working on a new social media application, was tasked with designing test cases for a critical feature: the news feed algorithm. This algorithm personalized the content displayed to each user based on their interests and interactions.

Initially, Sarah started by carefully reviewing the code, line by line, trying to grasp the complex logic behind the algorithm. This approach was time-consuming and overwhelming, making it difficult to identify all potential test scenarios.

Frustrated with the slow progress, Sarah decided to try a different approach. She collaborated with a developer to create a program graph for the news feed algorithm. This visual representation depicted the various factors influencing the content selection, like user preferences, post interactions, and content freshness, with clear decision points and branching paths.

The program graph was a game-changer. By visualizing the algorithm's flow, Sarah could efficiently identify critical paths:

• Trending topics: She focused on testing scenarios where trending topics would be prioritized in the feed, ensuring users wouldn't miss popular content.
• Personalized recommendations: She prioritized testing different user profiles with varying interests and interactions to verify the algorithm accurately recommends relevant content.
• Edge cases: The graph also highlighted potential edge cases, like inactive users or users with limited interactions. Sarah could then design specific test cases to ensure the algorithm wouldn't malfunction in these scenarios.

Using the program graph, Sarah identified potential test cases much faster and with greater focus compared to her initial code-centric approach. This allowed her to prioritize critical areas of the algorithm, ensuring comprehensive testing and contributing to a more reliable and personalized news feed experience for users.

Enhanced Documentation and Maintainability

Program graphs serve as valuable documentation, providing a clear visual reference for future testing efforts or understanding of how the program works.

This documentation can be particularly helpful when revisiting code after significant changes or onboarding new team members. It allows them to grasp the program's flow and potential testing considerations more readily.

A once bustling e-commerce platform was experiencing growing pains. Their aging inventory management system, built years ago, was becoming increasingly complex and difficult to maintain. New features were becoming challenging to implement, and bug fixes often introduced unintended consequences. The decision was made to overhaul the system completely.

Mark, a senior developer on the project, knew the importance of proper documentation for the new system. While detailed code comments were crucial, he knew something additional was needed, especially for the intricate inventory management logic. He decided to utilize program graphs alongside traditional documentation.

The program graphs visually depicted the flow of inventory data, from product additions and updates to order processing and stock-level management. Each node represented a specific action, and edges connected them, showing the logical flow. This visual representation proved invaluable in several ways:

1. Clearer communication: When onboarding new developers to the project, Mark used the program graphs to explain the system's functionality. These graphs, alongside code comments, provided a clear and concise overview, allowing new team members to grasp the system's logic and testing considerations much faster.
2. Efficient code reviews: During code reviews, referring to the program graphs alongside the code changes helped identify potential issues early on. By visualizing the impact of changes on the overall flow, the team could ensure the modifications wouldn't introduce unintended side effects in other parts of the system.
3. Future-proofing maintenance: As the system evolved and new features were added, the program graphs served as a valuable reference point. Developers working on future modifications could easily understand the existing logic and potential impact areas, leading to more efficient and targeted development efforts.

By utilizing program graphs alongside traditional documentation, Mark and his team ensured a smooth onboarding process for new developers. They also ensured efficient maintenance and future development of the revamped inventory management system. The program graphs served as a bridge between code and human understanding, allowing clear communication, collaboration, and a more robust and maintainable system.

Early Detection of Issues

The visual nature of program graphs can sometimes reveal potential issues that might be missed during a purely textual code review. For instance, complex or tangled graphs might indicate sections of code with high cyclomatic complexity, which can be more prone to errors.

The pressure was on for Maya, a software tester working on a critical update to a hospital's appointment scheduling system. The update introduced a new feature allowing patients to reschedule appointments online. While the code review process hadn't identified any major issues, Maya felt uneasy about the complexity of a specific section related to handling conflicting appointments.

Traditionally, Maya relied on code reviews and test case design based on the code's logic. However, this time, she decided to create a program graph for the appointment rescheduling functionality. As the graph materialized, Maya's concerns were confirmed. The visual representation revealed a tangled mess of nodes and edges, indicative of high cyclomatic complexity.

This complex graph highlighted potential issues that might have been missed in a purely textual review:

• Multiple decision points: The graph displayed numerous decision points based on various factors like existing appointments, doctor availability, and time constraints. This complex branching structure suggested a higher risk of errors due to the difficulty of considering all possible scenarios during testing.
• Hidden logic: The tangled nature of the graph made it challenging to follow the code's logic visually. This raised concerns about potential hidden conditions or unexpected behavior within the code.

Based on these red flags identified through the program graph, Maya decided to:

• Prioritize testing: She prioritized testing scenarios involving conflicting appointments. She focused on edge cases and combinations that might expose potential errors in the complex logic.
• Collaborate with developers: Armed with the visual representation, Maya approached the developers to discuss the identified complexity. This collaboration led to a code refactoring effort, simplifying the logic and reducing the cyclomatic complexity.

By leveraging the program graph, Maya proactively identified potential issues and collaborated with developers to address them. This early detection of potential problems through visual representation ensured a more robust and reliable appointment rescheduling system for the hospital.

Structured Programming Connection

Program graphs seamlessly align with the principles of structured programming (sequence, selection, and repetition). These fundamental constructs map directly to specific graph patterns, simplifying testing for these common structures.

• Simplified test design: Structured programming emphasizes well-defined constructs like sequence, selection (if-else), and repetition (loops). Program graphs directly map these constructs to specific patterns:
  • Sequence: A straight line of nodes representing one statement following another
  • Selection: A branching structure with a single entry node, a condition node, and two outgoing edges (one for true and one for false) leading to separate sequences of statements
  • Repetition: A loop pattern with an entry node, a condition node, an edge back to the condition node, and an edge leading to the body of the loop (a sequence of statements)
• Easier test case visualization: By recognizing these familiar patterns within the program graph, testers can quickly understand the program's flow and corresponding test cases. For example, a loop pattern in the graph indicates the need for test cases covering various iterations of the loop, including boundary conditions and expected behavior.

More On Complexity Measurement

The cyclomatic number, a metric based on program graph complexity, helps assess the difficulty of testing a program. Higher complexity (more paths) often requires more thorough testing. But let's dive into some more details.

• Cyclomatic number: This metric, derived from the program graph's structure, estimates the number of independent execution paths within the program. Higher cyclomatic numbers indicate greater complexity, often due to factors like nested loops, multiple decision points, or GOTO statements.
• Informed test planning: The cyclomatic number serves as a guide for testers, suggesting the level of effort required for thorough testing. A program with a higher cyclomatic number needs more test cases to cover all potential execution paths compared to a program with a lower number. This helps testers prioritize their efforts and ensure comprehensive coverage of complex sections.

Example:

Consider a simple program with two consecutive if-else statements:

if condition1:
  # statements for if condition1 is true
else:
  if condition2:
    # statements for if condition2 is true
  else:
    # statements for both conditions false

Nodes:

• Node 1: The starting point of the program, representing the beginning of the code execution.
• Node 2: The decision node for condition1. This node evaluates the condition and determines the flow of execution based on the result (true or false).
• Node 3: The block of statements executed if condition1 is true. This node represents all the code within the "if" block for condition1.
• Node 4: The "else" node associated with condition1. This node indicates the alternative path if condition2 is not checked (i.e., condition1 is false).
• Node 5: The decision node for condition2. This node evaluates the condition and determines the flow of execution based on the result (true or false).
• Node 6: The block of statements executed if condition2 is true. This node represents all the code within the "if" block for condition2.
• Node 7: The "else" node associated with condition2- This node indicates the end point of the program, representing the code executed if both condition1 and condition2 are false.

Edges:

• Edge 1: Connects Node 1 to Node 2, indicating the initial flow from the starting point to the first decision point
• Edge 2 (True): Connects Node 2 to Node 3, representing the flow of execution if condition1 is true
• Edge 3 (False): Connects Node 2 to Node 4, representing the alternative flow if condition1 is false
• Edge 4: Connects Node 4 to Node 5, indicating the flow from the "else" block of condition1 to the second decision point
• Edge 5 (True): Connects Node 5 to Node 6, representing the flow of execution if condition2 is true
• Edge 6 (False): Connects Node 5 to Node 7, representing the endpoint if condition2 is false

The corresponding program graph would have a branching structure with three decision points and multiple execution paths. The cyclomatic number for this graph would be 4 (nodes - edges + 2). This indicates potentially more complex logic and the need for more test cases compared to a program with a simpler structure.

By understanding these benefits, software testers can leverage program graphs to efficiently navigate program logic, design effective test cases, and contribute to delivering high-quality software.

Calculation of the Cyclomatic Number

Let's explain in detail how we arrive at the cyclomatic number of 4.

• Cyclomatic complexity tells us how many independent paths there are through a program. The more paths, the more complex it is to test thoroughly.
• In this code, we have two decisions (checking condition1 and condition2). Each decision creates a potential fork in the path (true or false).
• However, since the else block of condition1 leads directly to the decision for condition2, there's no real branching there. It's like a one-way street leading to another decision point.

• So, we only count the independent decision points:

  1. Starting point
  2. condition1 (true or false)
  3. condition2 (true or false)

Since we have 3 decision points, but adding 1 because of the starting point is a common way to calculate cyclomatic complexity, the final number is 3 + 1 = 4.

Remember:

• A higher cyclomatic complexity doesn't necessarily mean bad code, but it suggests there might be more scenarios to consider for testing.
• With a complexity of 4, this code snippet isn't overly complex, but as the number of decisions and nesting of conditionals increases, the cyclomatic complexity and testing effort can grow significantly.

Limitations of Program Graphs

While program graphs offer valuable insights, they come with certain limitations that testers need to be aware of:

Non-Executable Elements

• Omission of comments and declarations: Program graphs primarily focus on the flow of control within the program, represented by executable statements. Non-executable elements like comments and data declarations are typically ignored, as they don't directly impact code execution.
• Potential for misinterpretation: While ignoring these elements simplifies the graph, it can potentially lead to misinterpretations. Testers need to be aware of these excluded elements and ensure they are considered during test design to avoid overlooking potential issues related to data initialization, logic comments, or other non-executable code sections.

Distinguishing Path Feasibility

• The challenge of identifying meaningful paths: Not all paths within a program graph represent valid or meaningful execution sequences. Some paths might be technically possible based on the graph structure (topologically possible) but illogical or nonsensical in the context of the program's logic (semantically infeasible).
• Increased testing effort: Identifying and prioritizing feasible paths for testing can be challenging and requires additional effort from testers. They need to analyze the program logic and context to distinguish between valid and invalid paths, potentially leading to additional test case design and execution time.

Mitigating These Limitations

• Combining with other testing techniques: Program graphs work best when combined with other testing techniques like code reviews or data flow analysis. These techniques can help identify non-executable elements and their potential impact while also aiding in understanding the program's logic for a better assessment of path feasibility.
• Focus on key paths: Testers can prioritize testing high-risk or critical paths within the program graph. This involves considering factors like loop conditions, expected user inputs, and potential error scenarios to identify the most impactful paths for testing.

By understanding and addressing these limitations, testers can leverage program graphs effectively. Comprehensive and efficient testing can take place while acknowledging their inherent limitations and the need for combining them with other testing approaches.

Wrapping Up

Program graphs are a valuable asset in the software tester's toolkit. Their ability to visually represent program flow offers a multitude of benefits, including:

• Enhanced communication and collaboration: Bridging the gap between technical and non-technical stakeholders, allowing smoother collaboration within development teams.
• Increased efficiency and focus: Allowing testers to identify critical paths and prioritize testing efforts on areas with higher risk or complexity.
• Improved documentation and maintainability: Providing a clear visual reference for future development/testing endeavors and onboarding new team members.
• Early detection of issues: Revealing potential problems through visual complexity cues, enabling proactive mitigation strategies.

Furthermore, program graphs offer two key benefits that also impact the development process directly:

• Alignment with structured programming: By visually mapping to the principles of structured programming (sequence, selection, and repetition), program graphs streamline testing for these common constructs, making the process more efficient and consistent.
• Complexity management: The cyclomatic number, derived from the program graph's structure, provides an objective measure of program complexity. This metric aids testers in prioritizing testing efforts and collaborating with developers to potentially simplify complex sections of code, creating more maintainable and testable software.

By leveraging the power of program graphs, software testers can gain deeper insights into program logic. They can design more effective test cases and contribute to the delivery of high-quality software. As the software landscape continues to evolve, program graphs are poised to remain a crucial tool for ensuring the reliability and robustness of the applications that shape our world.