I build practical software and test automation projects focused on application support, quality engineering, troubleshooting, and maintainable delivery workflows. I am developing my skills for Application Support, QA Automation, Software Testing, and junior Software Engineering roles.

A Spring Boot support-ticket application demonstrating Java 17, Spring MVC, Thymeleaf, H2, validation, SQL troubleshooting, unit and integration testing, GitHub Actions, Agile documentation, and upgrade planning.

A standalone TypeScript and Playwright framework with 42 traceable browser scenarios, Page Objects, reusable fixtures, unique test-data factories, HTML and Allure reports, failure evidence, and CI that starts and tests the Java application.

Java · Spring Boot · Maven · SQL · H2 · Node.js · TypeScript · Playwright · GitHub Actions · Azure DevOps concepts

• Diagnosing application behavior across the UI, service, and persistence layers
• Designing maintainable automated regression coverage
• Documenting test strategy, defects, support procedures, and delivery controls
• Building reproducible CI workflows with useful failure evidence

• Role: Integration contributor on a course team building a Python system for evaluating AI models, datasets, and repositories.
• My contribution: Opened PR #17 to bring the team's frontend/backend integration branch together for review, including the FastAPI evaluation endpoint, AWS Lambda handler, DynamoDB writer, and model-evaluation dependencies.
• How work was divided: Teammates owned the evaluation engine, resource handlers, metrics, and deployment pieces; I helped surface the combined integration branch through the pull-request workflow.
• Technologies: Python, FastAPI, Pydantic, AWS Lambda, DynamoDB, Hugging Face tooling, GitHub pull requests.
• Testing and review: The repository documents a 24-test suite with coverage across classification, handlers, metrics, logging, and errors. The open integration PR also taught me to keep generated files and unrelated commits out of reviewable changes.
• Outcome and lesson: The team produced an eight-metric evaluator with NDJSON output. I learned that integration PRs need narrow scope, clear ownership, clean commit history, and verification evidence—not only working code.

• Role: API contributor working through ticket-based branches in a two-person course repository.
• My contribution: Updated the C# weather-forecast endpoint from seven to eleven returned days and synchronized the ticket branch with main in merged PR #14.
• How work was divided: Work was tracked as small tickets and completed on separate branches before integration into the shared default branch.
• Technologies: C#, ASP.NET Core minimal APIs, Swagger/OpenAPI, static HTML, Git and GitHub.
• Testing and review: Endpoint behavior could be checked through Swagger, the browser, curl, or Postman; the branch was updated against main before merge.
• Outcome and lesson: The change shipped through a merged PR. I learned to keep API behavior changes tied to a specific ticket and to reconcile the shared branch before integration.

• Role: Early-stage team contributor practicing shared-repository workflow.
• My contribution: Used a personal feature branch and completed merged PR #5 during repository setup.
• How work was divided: Five contributors worked through individual branches in a shared Python repository.
• Technologies: Python, Git branching, and GitHub pull requests.
• Testing and review: This initial PR exercised branch synchronization and merge review rather than delivering a production feature.
• Outcome and lesson: The experience established the team workflow and showed me why descriptive PR titles, meaningful diffs, and explicit test evidence matter. I now apply those practices in newer projects.

Explore the pinned repositories below for source code, architecture, test coverage, screenshots, and setup instructions.