Hi, I'm Jonathan Castro—a computer science graduate from Northern Illinois University. This summer, I had the incredible opportunity to join Broadcom as a Next-Gen Mainframer on the AAM Team in the Lisle office. It has been an amazing learning experience—one that gave me hands-on exposure to real-world cybersecurity challenges. This project not only helped me sharpen my technical skills, but also allowed me to collaborate with incredible people and deepen my understanding of industry best practices in an agile environment.
My Project: Automating R_FACTOR Testing
Ever heard of Multi-Factor Authentication (MFA)? It’s essential for modern security—requiring users to verify their identity using multiple factors. This significantly reduces the risk of unauthorized access. In fact, MFA can prevent 99.2% of account compromise attacks just by requiring two or more types of evidence:
-
Something you know (e.g., password)
-
Something you have (e.g., a device)
-
Something you are (e.g., fingerprint)
On the mainframe, security is enforced through External Security Managers (ESMs). The three primary ESMs are:
-
RACF (Resource Access Control Facility) – owned by IBM
-
ACF2 – (Access Control Facility 2) – owned by Broadcom
-
Top Secret – owned by Broadcom
All three use R_FACTOR calls during MFA tag validation. These calls help determine if a user is MFA-authorized, retrieve their configured factors, and validate them.
My summer project focused on automating the testing of R_FACTOR calls using Cucumber, a Behavior-Driven Development (BDD) framework. The goal was to detect bugs and vulnerabilities in AAM code by implementing automated feature tests.
How It Works
We created 12 Cucumber features—two for each of the six (SETU, GETU, SETF, GETF, GETP, and GETC) R_FACTOR calls:
Here’s how the test pipeline works:
-
Java is used for the logic behind each test step, including setting input variables.
-
FreeMarker Template Language (FTL) dynamically generates Assembler and JCL files based on those inputs.
-
These files are submitted to the mainframe for execution.
-
A REXX utility then verifies that the output is correct.
If a test fails (e.g., due to mismatched return codes), Cucumber logs the failure and moves on. We intentionally introduced test errors to compare how they behave across RACF, ACF2, and Top Secret. By simply specifying the ESM to use, these tests can now run on all three—making it easy to compare their behavior side by side.
Wait... What’s Cucumber?
You might be thinking: “Cucumber? Like the fruit?” Not quite.
In software development, Cucumber is a testing framework that follows Behavior-Driven Development (BDD) principles. It uses a language called Gherkin, which lets you write test cases in plain English. This makes it easy to describe how software is supposed to behave—even for non-developers.
Once a Scenario Outline is written, tests can be created in seconds just by adding a line in the Examples section. Here’s how a feature file is structured:
Figure 1. Set User Request Cucumber Feature on IntelliJ
Anatomy of a Cucumber Feature File
1. Annotation
Figure 2. Annotation in Cucumber feature
Annotations link each feature to its corresponding test case in the codebase. This allows selective test execution, enabling targeted testing, efficient debugging, and CI/CD integration.
2. Feature
Figure 3. Feature section in Cucumber feature
Describes the high-level goal or purpose of the test. For example: validating the SETU (Set User) request.
3. Background
Figure 4. Background section in Cucumber feature
Defines shared steps that run before each test scenario. For example, setting environment variables such as high-level qualifiers, test systems, and login credentials.
4. Scenario Outline
Figure 5. Scenario Outline section in Cucumber feature
A reusable template that defines the structure of a test. You can plug in different values using the Examples section.
5. Examples
Figure 6. Examples section in Cucumber feature
A table containing rows of test data. Each row runs the Scenario Outline once with that specific combination of values—enabling fast, scalable testing.
Why Use Cucumber?
Here are a few reasons why Cucumber was ideal for this project:
Figure 7. Cucumber Report Generated for Tests
What I Learned
This project was incredibly rewarding and packed with learning opportunities. Here are a few key takeaways:
-
Debugging. Before this experience, I knew what debugging meant but lacked practical experience. During the project, I ran into issues like null variables and used IntelliJ’s debugger to investigate and fix problems—giving me real confidence in my debugging skills.
-
Agile Development. Although I studied Agile in college, I didn’t truly understand it until I experienced it at Broadcom. Daily stand-ups and frequent demos helped me see the value of fast feedback and iterative progress.
-
Cucumber Framework. I had never heard of Cucumber before this experience. Now, I can confidently write Cucumber feature files, implement step definitions in Java, and explain how BDD can improve the development process.
-
Assembler, Java, and REXX. While I had some prior exposure to these languages, I wasn’t confident using them. After this summer, I’ve gained a deeper understanding of assembler code, can write Java functions for testing, and use REXX to automate mainframe tasks.
-
Mainframe Tools. Before this summer, I had minimal knowledge of ISPF and TSO. By the end of the project, I felt comfortable using them to view datasets, check job outputs, and more.
Conclusion
My summer at Broadcom was everything I hoped it would be—challenging, educational, and fun. If you ever get the opportunity to spend a summer here, enjoy it, because the time will fly by.
A huge thank you to everyone who supported me throughout the summer: Chandan Venkatesh (my manager), James Broadhurst and John Mathunny (my project mentors), Samuel Wells (my buddy), and the entire AAM Team for their kindness, guidance, and encouragement.
This summer was a highlight in my career journey, and I’m excited to carry these lessons into whatever comes next.