Breaking Things (and Building Better Tests): My Hackathon Experience

I recently participated in the Breaking Things Hackathon hosted by Hashnode and sponsored by Bug0, and I can confidently say—it was one of the most fun and exciting hackathons I’ve joined.

What made this experience even more special for me was how closely the theme aligned with what I already do in my day‑to‑day work: Playwright‑based UI automation with emerging AI capabilities. The hackathon felt like the perfect playground to experiment, learn, and push boundaries—without the usual production pressure.

My Background: Playwright at Work

At work, Playwright is a core part of our UI automation strategy. Our framework follows a traditional and well‑structured approach:

• Page Object Model (POM)

• Explicitly defining every UI element

• Carefully crafted custom workflows

• Reusable utilities, helpers, and shared components

This approach is powerful and scalable—but it also comes with very real, everyday challenges.

On a daily basis, a lot of time goes into:

• Finding each UI element on the page

• Experimenting with XPaths or selectors

• Making sure elements are present and clickable

• Debugging flaky locators

• Managing inheritance, class extensions, and POM structure

• Constantly updating tests when the UI changes

While this is part of being an SDET, it often means spending more time maintaining tests than actually testing features or flows.

That’s why experimenting with Passmark during the hackathon felt like a breath of fresh air.

Discovering Passmark: Simple, Fast, and Powerful

Using Passmark completely changed how I thought about writing automated tests.

For the first time, I didn’t have to worry about:

• Defining every locator manually

• Maintaining complex POM hierarchies

• Inheriting base classes or managing extensions

• Updating selectors for minor UI changes

Instead, I could focus purely on user flows and behavior.

What Stood Out Immediately

1. Readable Test Definitions

The tests were incredibly easy to read—clear enough that even someone without a coding background could follow what the test was doing.

2. Minimal Setup, Maximum Productivity

Most things just worked. I didn’t need lengthy setup or boilerplate code to get started.

3. Speed and Efficiency

In a short amount of time, I wrote close to 30 regression tests—something that would normally take much longer in a traditional Playwright + POM framework.

4. Stability and Self‑Healing

The tests were not only fast to create but also stable and resilient. The self‑healing capabilities significantly reduced flakiness and maintenance effort.

5. Cross‑Browser Testing Made Easy

I was also able to execute tests across multiple browsers seamlessly, without extra configuration headaches.

You can find the project I worked on during the hackathon here:
GitHub Repo: https://github.com/Hema-Nambi/passmark-project

A Short Technical Deep Dive: Traditional Playwright vs Playwright with Passmark

To put this experience in context, here’s a quick technical comparison based on my everyday work as an SDET.

Traditional Playwright + POM (What I Use at Work)

In my regular workflow, writing UI automation involves:

• Creating Page Object classes for every screen

• Defining each locator carefully (XPath, CSS, text, etc.)

• Ensuring elements are visible, clickable, and stable

• Handling dynamic UI changes manually

• Managing inheritance, base classes, and common utilities

• Refactoring tests when locators or flows evolve

This approach is powerful and scalable, but it comes with a high maintenance cost, especially as applications grow and UIs change frequently.

Playwright with Passmark (Hackathon Experience)

With Passmark, the experience was fundamentally different.

• I didn’t have to manually define or maintain locators

• No constant tweaking of XPaths or selectors

• No need to strictly follow POM, class inheritance, or complex extensions

• Focus shifted from how to interact with the UI to what user behavior to validate

• Self‑healing reduced flakiness when UI changes occurred

• Test intent was clear and readable without deep framework knowledge

Technically, this meant:

• Faster test creation

• Fewer framework‑level concerns

• Lower maintenance overhead

• Easier onboarding for people without strong coding backgrounds

Why This Matters in Real Test Suites

From a QA and automation perspective, this approach:

• Accelerates regression coverage

• Reduces time spent debugging locator issues

• Improves test reliability

• Makes automation more accessible across teams

Writing nearly 30 regression tests quickly and confidently during the hackathon wouldn’t have been possible for me in the same timeframe using a traditional POM‑heavy setup.

Why This Hackathon Was Special

This hackathon wasn’t just about building something—it was about breaking assumptions around how automation has to be done.

It challenged a few long‑held beliefs:

• Automation doesn’t have to be complex to be powerful

• Tests don’t need to be hard to read to be reliable

• AI can genuinely amplify a tester’s productivity

I truly enjoyed every part of the experience—from experimenting with a new approach to seeing meaningful results quickly.

Gratitude and Looking Ahead

A big thank you to Hashnode for organizing and hosting such a well‑run hackathon, and to Bug0 for sponsoring and encouraging innovation in the testing space.

Hackathons like this:

• Encourage learning by doing

• Help testers explore modern tools

• Create a supportive environment for experimentation

I’d love to see more hackathons like this, especially those focused on testing, automation, and AI‑driven quality engineering.

Final Thoughts

The Breaking Things hackathon reminded me why I love being in tech—the joy of learning, experimenting with new tools, and simplifying complex problems.

If you’re a tester, SDET, or automation engineer who hasn’t explored AI‑assisted testing yet, this experience showed me that it’s absolutely worth trying.

Here’s to more breaking, building, and learning
— Hema