Unpredictable Properties – Tricentis Tosca

by

Summary

The goal is to create a reusable Test Step block in Tricentis Tosca to verify the title on different screens, despite the property type varying between TextBox and Container. Additionally, the name attribute is unstable, and other identifiers like Tag, className, and ID are not reliable.

Root Cause

The root cause of this issue lies in the inconsistent property types used across different screens for the title element. This inconsistency makes it challenging to create a generic verification step. Key factors contributing to this issue include:

  • Unstable name attribute
  • Variability in Tag (either INPUT or DIV)
  • Usually empty className and ID

Why This Happens in Real Systems

This happens in real systems due to:

  • Lack of standardization in UI component development
  • Evolution of the application over time, leading to inconsistent design patterns
  • Different development teams or individuals working on various parts of the application, each with their own coding practices

Real-World Impact

The real-world impact includes:

  • Increased test maintenance efforts due to the need for screen-specific test steps
  • Reduced test efficiency because of the inability to reuse test steps across different screens
  • Higher risk of test failures due to the unstable nature of the identifiers used for the title element

Example or Code (if necessary and relevant)

// Example of how you might approach this in a dynamic manner
// Note: This is a simplified example and may require adjustments based on the actual Tosca API and your specific requirements

public class DynamicTitleVerifier
{
    public bool VerifyTitle(string expectedTitle)
    {
        // Assuming you have a method to get the current screen element
        var titleElement = GetTitleElement();

        if (titleElement == null) return false;

        // Check if the element is a TextBox or Container and verify accordingly
        if (titleElement.GetType() == typeof(TextBox))
        {
            return ((TextBox)titleElement).Text == expectedTitle;
        }
        else if (titleElement.GetType() == typeof(Container))
        {
            // Logic to verify title within a Container
            // This might involve recursively searching for a text element within the container
            return VerifyTitleInContainer((Container)titleElement, expectedTitle);
        }

        return false;
    }

    // Method to get the title element, considering the unstable name and other attributes
    private object GetTitleElement()
    {
        // Implement logic to find the element based on the most reliable attributes or a combination thereof
        // This could involve checking for elements with a tag of INPUT or DIV and then verifying their text content
    }

    // Method to verify title within a Container
    private bool VerifyTitleInContainer(Container container, string expectedTitle)
    {
        // Implement logic to find and verify the title within the container
    }
}

How Senior Engineers Fix It

Senior engineers fix this issue by:

  • Implementing dynamic element detection mechanisms that can adapt to the varying property types and unstable attributes
  • Using robust and reliable identifiers or combinations of attributes to locate the title element
  • Creating reusable and modular test steps that can be easily maintained and updated
  • Applying standardization and best practices in test automation to ensure efficiency and reliability

Why Juniors Miss It

Junior engineers might miss this due to:

  • Lack of experience with dynamic and adaptive automation strategies
  • Insufficient understanding of the complexities and variability in real-world applications
  • Overreliance on straightforward, screen-specific automation approaches
  • Inadequate knowledge of how to leverage the full capabilities of the automation tool (in this case, Tricentis Tosca) to handle complex scenarios.