Exploring Testing on Z through Roman Army Operational Strategy
Undertaking testing projects as my first assignments in IBM Z DevOps was a daunting experience. The intricacies of this domain, especially for non-developer professionals, presented a formidable challenge. Yet, after years of grappling with acquiring domain knowledge and taking breaks to work on other projects, I stumbled upon a unique approach to unraveling the complexities of testing — drawing inspiration from the operations of the Roman army.
In this article, I explore basic z/OS testing through the lens of Roman military strategies. While the comparison may not be perfect, the Roman army analogy serves as a fitting and appropriate framework to enhance understanding of this complex concept. By drawing parallels between ancient strategies and modern methodologies, I aim to simplify the intricacies of z/OS testing and make it more accessible to all readers. This overview provides insight into technical complexities without relying on technical jargon.
Helpful terminology before moving on to the next section:
Since I am using Roman military strategy, I will provide a list of terminology that will be constantly mentioned throughout the rest of the article:
Roman Legion: The largest military unit of the Roman army, composed of Roman citizens serving as legionaries.
Auxiliary: Non-citizen troops attached to the citizen legions. They are friends and allies of Rome, supplying cavalry as well as infantry.
A century: Approximately 80 strong, the smallest functional unit of the Roman army.
A cohort: Approximately 480 strong, consisting of six centuries, the smallest functional unit of the Roman army. The 1st cohort is double strength.
A legion: Consists of 10 cohorts, therefore comprising about 5000–5500 troops, including non-combatant personnel.
Test Plan : Navigating Strategies and Objectives
A test plan is a comprehensive document that delineates the approach, objectives, scope, and resources for a software testing initiative. Functioning as a strategic guide, it maps out the testing process by outlining activities, schedules, and the responsibilities of the testing team.
Parallel : Test planning resembles the reconnaissance and scouting strategies employed by the Roman army, emphasizing the gathering of crucial intelligence and meticulous preparation for upcoming campaigns.
Just as scouts gather information about enemy territories, strengths, and vulnerabilities, test planning entails analyzing project requirements, identifying critical features, evaluating risks, and establishing testing scope and objectives.
Test Case: Crafting Battle Scenarios
A test case provides clear instructions and criteria for executing tests, ensuring that testers can systematically assess the readiness and effectiveness of the software under various scenarios. Each test case represents a carefully crafted scenario designed to evaluate a particular aspect of the application, akin to devising tactical maneuvers to overcome different challenges on the battlefield.
Parallel : A test case is comparable to the meticulous planning and preparation undertaken by Roman commanders before engaging in battle. They strategized and formulated battle plans to face adversaries with specific strengths, battle styles, and characteristics in engaging wars.
Furthermore, much like how a battle plan evolves based on feedback and outcomes from previous battles, test cases are refined and updated based on test results and feedback, continually improving the testing process.
Understanding Testing Methods and Approaches: Achieving Optimal Efficiency at Every Level
In software development, a variety of testing methods are utilized to maintain quality across the development lifecycle. The testing pyramid, highlighted in the illustration above, underscores early testing phases for efficient defect detection. Rectifying issues during unit testing, positioned at the pyramid’s base, is cost-effective. However, identifying problems at later stages can result in significant financial consequences for the company compared to earlier phases.
What is Unit Testing? A Smallest Operational Unit
In z/OS environments, unit testing focuses on scrutinizing individual components or modules of software written in languages such as COBOL, PL/I, or Assembler.
Parallel : The concept of unit testing resembles the drilling and training of a Roman century or an auxiliary cavalry unit conducting their own unit drill. Just as a century or cavalry unit comprises a cohesive group of soldiers trained to excel individually and collectively, mastering the use of weapons and working seamlessly as a unified entity, unit testing ensures each basic unit is defect-free before moving to the next stage of testing.
Unit testing verifies that each unit of code functions correctly in isolation and integrates smoothly with other units when combined into the larger system. By conducting thorough unit testing, developers can enhance the reliability and cohesion of the software, ensuring its reliable performance in real-world scenarios.
Integration Testing is A Cohort or Larger Operational Unit
Integration testing in z/OS is a software testing process that evaluates the interoperability between various software components or multiple programs comprising an application, databases, and middleware within the mainframe environment.
Parallel : A combined infantry and cavalry maneuver is essential to ensure seamless coordination and effectiveness in Roman army tactics on the battlefield. Effective communication between infantry and cavalry units, facilitated through visual signals and verbal commands, is crucial for coordinating maneuvers and responding to enemy threats, with the cavalry playing a key role in safeguarding the infantry. Commanders can evaluate adaptability and responsiveness through simulated battle scenarios and variations in battlefield conditions, identifying areas for improvement and optimizing the drill.
Integration testing ensures that different components of the system work together seamlessly. It involves testing the interactions and interfaces between these components to verify that they communicate effectively and produce the expected outcomes as a cohesive system.
Functional Testing: Executing Tasks with Accuracy and Efficiency
Functional testing assesses how well the software’s features function under different conditions, identifying any deviations from expected behavior and ensuring that the software performs reliably for end users.
Parallel : The commanders ensure that both infantry and cavalry units perform their duties effectively by conducting targeted drills and exercises. These exercises simulate various battlefield scenarios, including simulated cavalry aggression, to assess the readiness, proficiency, and ability of both infantry and cavalry to maintain formation, execute orders, and fulfill their respective roles with utmost proficiency on the battlefield.
Just as functional testing verifies that each function or feature of the software performs correctly according to specified requirements, assessing soldiers’ skills ensures they can effectively carry out their duties, whether it’s wielding a weapon, executing a combat maneuver, or providing support to their unit.
Regression Testing: Safeguarding Software Stability Amidst Change
Regression testing safeguards the integrity of the software by detecting and addressing any regressions or unintended side effects introduced during development.
Parallel : Imagine regression testing as ensuring the smooth operation of a newly designed siege machine or device without compromising the safety and efficiency of the siege engineers who operate it. Suppose a group of new cavalrymen joined the unit and updated weapons. In such a scenario, it’s crucial to assess if these changes would have any impact.
Just as an engineering unit meticulously tests the updated siege machines or introduces new devices to ensure they function as intended without posing risks to the operators, regression testing verifies that recent changes or additions to the software haven’t inadvertently introduced errors or disruptions to its existing functionality.
End-to-End Testing : Ensuring Readiness for Deployment
End-to-end (E2E) testing refers to the comprehensive evaluation of a software application from start to finish, covering all aspects of its functionality, user interactions, and system integrations. It aims to ensure that the entire system behaves as expected and meets the specified requirements, simulating real-world usage scenarios.
Parallel: In the context of the Roman army, E2E testing can be likened to inspecting the entire campaign of a legion, from the initial planning stages to the execution of battle strategies and the aftermath of engagements. Inspecting the entire legion’s campaign involves assessing every aspect of the military operation, from logistical planning and troop movements to battlefield tactics and post-battle analysis.
E2E testing, in software development, refers to the comprehensive evaluation of a software application from start to finish, covering all aspects of its functionality, user interactions, and system integrations. It aims to ensure that the entire system behaves as expected and meets the specified requirements, simulating real-world usage scenarios.
What is Shift Left Testing? A Proactive Vigilance in Preparation
Shift left testing is a testing philosophy in software development that emphasizes early and continuous testing throughout the development lifecycle. It advocates for initiating testing activities as early as possible, including during the initial stages of development, to ensure software robustness and resilience prior to deployment in the production environment.
Parallel : This proactive testing approach mirrors the rigorous training and preparation of Roman soldiers before engaging in battle. Roman commanders prioritized daily and thorough training to ensure soldiers’ progress and readiness for combat. Shift-left testing focuses on identifying and addressing issues early in the development process.
By detecting defects early, teams can prevent issues from escalating into larger problems and successfully launch high-quality software.
Middleware and Db2 in Testing : Logistical and Communication Network
CICS, Db2, and IMS are integral to z/OS systems and are essential for testing to validate data operations, transaction processing, application integration, performance, scalability, security, and compliance. Testing these middleware components ensures the reliability, stability, and security of z/OS systems and applications.
CICS, The Central Command Hub
CICS facilitates the development and execution of online applications, allowing users to interact with mainframe-based systems in real-time. It provides features for managing transactions, coordinating concurrent access to resources, and ensuring the integrity and security of data. It serves as a central hub for processing transactions, enabling organizations to deliver responsive and reliable online services to their users.
EXAMPLE : In the Roman army, CICS functions as the central command post, orchestrating communications and strategies across the battlefield. Testing with CICS is akin to ensuring that the dispatch of messengers from the command post to various units is swift and accurate, and that responses from the field are received promptly.
Db2, The Central Repository of Strategic Information
DB2 serves as the central repository for storing and managing structured relational data, enabling efficient data retrieval, manipulation, and analysis. When working with COBOL applications that interact with DB2 databases, testing ensures that the COBOL application interacts correctly with the DB2 database.
EXAMPLE : DB2 functions as the strategic intelligence hub of the Roman army, housing profiles for every legionary member. These profiles include detailed information such as ranks, names, hometowns, enlistment dates, and records of physical traits. This wealth of information provides invaluable insights for decision-making processes, enabling effective management and deployment of soldiers for various missions and assignments.
IMS, Logistical Operations Support
IMS serves as middleware, acting as an intermediary between applications and databases to enable communication and data management. It is a hierarchical database management system extensively used on mainframe systems for managing large volumes of data. IMS provides tools and utilities essential for generating, managing, and manipulating test data for testing IMS applications. In essence, IMS is like the logistical backbone of the Roman army, effectively managing the flow of information and resources to support operational needs.
EXAMPLE: I can imagine that the IMS database provides a framework for test data, representing the organizational structure of the Roman army. Each segment contains information about a specific unit or component of the army. The hierarchical structure of the database mirrors the hierarchical command structure of the Roman army, from the overall army down to individual soldiers and their equipment.
Test Environment: Simulating real-world-like conditions and scenarios
A test environment in Z is like a safe playground for testing mainframe applications. It’s separate from the real system, so developers and testers can try out new things without worrying about breaking anything important. Here, they can check if everything works as expected, if the performance is good, and if it’s secure. This helps them catch any problems before the software goes live.
EXAMPLE : The test environment can be compared to the mock battlegrounds and training facilities where Roman legions conducted drills and exercises to prepare for warfare. Just as these training grounds simulated real-world conditions and scenarios, which was not often easy as they often fought unfamiliar terrain, where they are not familiar with dessert of geography of the regions they are placed in.
The test environment provides a controlled setting for executing test cases and evaluating the performance and behavior of the application, allowing testers to validate functionality, assess compatibility, and identify potential issues before releasing the software to production.
Test Results: Reflecting on the Drill or Battle
Test results in software testing refer to the outcomes obtained from executing test cases on a software application. These results provide valuable insights into the functionality, performance, and quality of the software, helping testers identify defects, weaknesses, or areas for improvement.
EXAMPLE : Test results in software testing are akin to the outcomes of battles in the Roman army, with both holding significant importance in assessing performance and making improvements. Roman commanders, much like modern-day testers, were meticulous about analyzing and documenting battle results to glean insights for improvement. They scrutinized victories and defeats alike, identifying strengths and weaknesses in their strategies, tactics, and equipment.
Similarly, testers meticulously analyze test results to identify defects, weaknesses, or areas for improvement in the software. They document their findings thoroughly, providing detailed reports to stakeholders and development teams. These updates drive continuous improvement in the testing process and the overall quality of the software, ensuring that it meets the highest standards of functionality and reliability.
Conclusion
Testing in z/OS environments requires a nuanced approach to ensure the reliability, performance, and security of software systems. By drawing parallels between z/OS testing concepts and the operational strategies of the Roman army, I’ve outlined fundamental testing practices, including shift left testing and various testing types, and highlighted the operational role of middleware in z/OS testing.
From meticulous planning akin to reconnaissance to the proactive approach embodied by shift left testing, and the vigilant safeguarding of software integrity through regression testing, each aspect of z/OS testing plays a crucial role in software quality assurance. I hope this simplified explanation of the basics of testing, using the Roman army analogy, has helped viewers grasp the concepts and sparked interest in this topic!
Jin Leem is a UX and visual designer at IBM based in Research Triangle Park. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
