Giving testing its time back.
A repetitive regression process became a framework one tester could run in about two hours.
~3 weeks → ~2 hours
Regression testing time
One tester
Running the automated process
Python + Selenium
Framework I built and maintained
The problem I worked on
At the California Franchise Tax Board, I worked on testing for SWIFT, Secure Web Internet File Transfer, within the SDT release process. The work involved validating actual workflows and making sure a change did not break something that already worked.
The regression process had taken roughly three weeks. My goal was to automate the repetitive work while keeping the coverage meaningful enough to support release decisions.
What I built
I stood up and maintained a Python and Selenium automation framework. I used it to run end-to-end workflows, including authentication and security validation, and to make the regression process repeatable.
The result was a process that could run in about two hours with one tester. That gave the team a much faster way to check a release and spend time investigating failures instead of repeating every action by hand.
The work around the code
The framework was only part of my responsibility. I also reviewed code and test cases, helped triage release-blocking issues, and kept coverage aligned with deployment timelines.
One of the clearest examples of the communication side was leading twice-weekly meetings. Some people wanted technical detail, while others needed to understand timing. I learned to start with the overall picture and go deeper where it was useful.
What this taught me
Automation needs to fit the way a team actually works. A faster test run matters when people can understand the results, investigate the problems, and use the information to make a decision.
This work gave me direct experience connecting software development, testing, troubleshooting, and communication in a real release process.