I am a Software Development Engineer in Test with 10+ years of experience building scalable test automation frameworks across UI, API, and performance layers.
My passion is to deliver the highest quality experiences possible to end-users through shift-left testing, cross-role collaboration, and applying QA best practices at each step of the software development life cycle.
Remember...
"If it is not tested, it is not working!"
| Layer | Tools |
|---|---|
| UI Automation | Playwright (TypeScript), Selenium WebDriver (C#) |
| API Testing | Postman, ReadyAPI, HttpClient (C#), k6 (JavaScript) |
| Frameworks | Node.js, .NET |
| CI/CD | Azure DevOps, GitHub Actions, Argo CD |
| Design Patterns | Page Object Model, Custom Fixtures, Layered Architecture |
| Repo | What it demonstrates | CI |
|---|---|---|
| demo-playwright-typescript | End-to-end UI tests with custom fixture extensions and page object model |  |
| demo-rest-api-tests-csharp | Functional API tests covering full CRUD, auth, and error scenarios |  |
| demo-rest-api-tests-javascript | k6 load and performance tests with ramp stages and threshold enforcement |  |
| demo-selenium-webdriver-csharp | Selenium WebDriver framework with runners, wrappers, and xUnit | — |
How do you approach building automation frameworks from scratch?
I start by understanding the application under test, the existing tech stack, the CI/CD pipeline, and what testing (if any) is already in place.
From there, I work with product and engineering to identify the highest-risk functional areas, which become the first automated scenarios. This helps establish early credibility and ROI.
Once priorities are set, I select the language and tooling that best fit the tech stack and the team's skill set. The test framework is built to be understandable, maintainable, and extensible from day one. Tests are wired into CI/CD workflows so that every deployment is validated from the beginning and not as an afterthought.
What is your strategy for deciding which test cases to automate vs. leave manual?
I ask, "Will the effort to automate this test give more than it takes?" This question gets to one of the main points of test automation, which is that not every test should be automated.
Good candidates for automation are test scenarios that are repeatable, provide meaningful coverage, and have the potential to catch real bugs in production.
If the quality signal was poor prior to a release and you recommended a delay, how would you handle pressure to release anyway?
My job in that moment is to make sure decision-makers have a complete, honest picture of quality. I document all outstanding issues, communicate the risks clearly, and ensure that information is visible to stakeholders before any go/no-go decision. After that, it's a leadership call.
📍 Oklahoma, USA | LinkedIn