Jump to navigation Jump to main content

How We Test at Hexis: Our Integrated Approach to Quality

How We Test at Hexis: Our Integrated Approach to Quality

At Hexis, delivering high-quality software isn’t just a goal — it’s part of our DNA. In today’s fast-paced development environment, moving fast can sometimes clash with maintaining reliability. So, how do we strike the right balance?

The answer isn’t a single tool or technique, but a deeply integrated testing culture that combines human expertise with smart automation.

In this post, we’ll take you behind the scenes of our testing strategy — showing how we blend the irreplaceable insight of manual testing with the precision and speed of automation, using Behavior-Driven Development (BDD) and Playwright to build a testing framework that’s effective, maintainable, and truly collaborative.

Our Foundation: A People-First Approach to Quality

Before writing a single line of test code, we start with people.

We believe that the most valuable insights come from human intuition and a deep understanding of the user experience. Our QA and development teams are driven by curiosity — and that’s where quality begins.

Manual testing remains a cornerstone of our approach, particularly for:

  • Exploratory Testing: Our testers are empowered to go off-script, uncovering unexpected issues and edge cases that rigid test scripts often miss.
  • User Experience (UX) Evaluation: We constantly assess whether our applications feel intuitive and solve real user problems — something only a human can truly judge.
  • Ad-hoc Testing: When new features ship or issues arise, we can quickly validate changes without the overhead of automation setup.

However, as our projects grew, we needed to scale. That meant finding a way to amplify our efforts without losing the human touch.

Scaling Our Efforts with Playwright and BDD

To handle growing complexity, we needed a testing framework that was fast, reliable, and easy to maintain, while keeping everyone — developers, QAs, and product owners — aligned.This led us to combine Playwright with a Behavior-Driven Development (BDD) philosophy.

Here’s what this approach brought us:

  • Greater Efficiency: We automated repetitive regression tests, freeing our team to focus on higher-value exploratory work.
  • Stronger Collaboration: Thanks to plain-language (Gherkin) tests, our product team can read and contribute to scenarios — bridging the gap between business intent and implementation.
  • Living Documentation: Our test suite reflects how the app truly behaves, evolving alongside the product.

Beyond Playwright: A Broader Approach to Automated Testing

Playwright is powerful, but we see it as part of a larger picture. A sustainable automation strategy depends on balance, structure, and discipline.

Here are a few key principles we follow:

  1. Follow the Testing Pyramid: Prioritize fast, independent unit tests, then integration tests, and finally critical end-to-end tests. This ensures quick feedback with fewer dependencies. (We use Bun for high-speed unit testing.)
  2. Define a Clear Automation Strategy: Focus on the areas that bring the most value. Don’t automate everything — automate what matters.
  3. Integrate with CI/CD: Automated testing is baked into our CI/CD pipeline, catching issues before they ever reach production.
  4. Prioritize Maintainability: Clear, modular, and well-documented tests ensure long-term stability as the codebase grows.
  5. Stay Flexible: Tools evolve. Playwright works well for us today, but we continually reassess our stack to keep improving.

Our Testing Strategy in Practice

A tool is only as strong as the strategy behind it. At Hexis, we build our process on three key pillars:

  • A Balanced Test Portfolio:

    We follow the testing pyramid — fast unit tests (with Bun) form the base, supported by integration tests and a select suite of Playwright end-to-end tests.

  • Deep CI/CD Integration:

    Quality isn’t a separate phase — it’s built into every commit. Each change triggers our full test suite, delivering immediate feedback.

  • Maintainability as a Principle:

    We treat test code with the same discipline as production code — clean, modular, and easy to update.

A Glimpse into Our BDD Test Suite

Behavior-Driven Development is the glue that connects our teams.

We define behavior from the user’s perspective using Gherkin syntax with Cucumber, keeping tests readable and meaningful for everyone.

Example: Gherkin Feature File

Feature: Calculator Operations

  Scenario: Add two numbers
    Given I am on the calculator page
    When I enter "2" and "3"
    And I click the addition button
    Then I should see the result as "5"

Here’s how we bring that to life in our codebase.

1. Our Blueprint: The Page Object Model (POM)

We keep selectors and logic organized through the Page Object Model, separating the how from the what.

class CalculatorPage {
  constructor(page) {
    this.page = page;
    this.baseUrl = '[https://calculatorapp.com](https://calculatorapp.com)';
    this.resultDisplay = '#result-display';
    this.addButton = '#addition-button';
    // ... other selectors
  }

  async navigateTo() {
    await this.page.goto(this.baseUrl);
  }

  async enterNumber(number) {
    for (const digit of String(number)) {
      await this.page.click(`#button-${digit}`);
    }
  }

  async clickAdd() {
    await this.page.click(this.addButton);
  }

  async getResult() {
    return this.page.textContent(this.resultDisplay);
  }
}

module.exports = { CalculatorPage };

2. Our Translator: BDD Step Definitions

Step definitions are the bridge between our Gherkin scenarios and our Playwright code. They use our Page Objects to execute the actions described in plain language.

const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('@playwright/test');
const { CalculatorPage } = require('./calculatorPage');

Given('I am on the calculator page', async function () {
  const calculatorPage = new CalculatorPage(this.page);
  await calculatorPage.navigateTo();
});

When('I enter "{string}" and "{string}"', async function (num1, num2) {
  const calculatorPage = new CalculatorPage(this.page);
  await calculatorPage.enterNumber(num1);
  await calculatorPage.clickAdd();
  await calculatorPage.enterNumber(num2);
});

Then('I should see the result as "{string}"', async function (expectedResult) {
  const calculatorPage = new CalculatorPage(this.page);
  const result = await calculatorPage.getResult();
  expect(result).toBe(expectedResult);
});

3. Our Story: Feature Files

These files are the heart of our BDD process. They serve as living documentation, ensuring that our technical implementation is always aligned with our business requirements.

Feature: Calculator Operations

  Scenario: Add two numbers
    Given I am on the calculator page
    When I enter "2" and "3"
    And I click the addition button
    Then I should see the result as "5"

  Scenario: Subtract two numbers
    Given I am on the calculator page
    When I enter "7" and "3"
    And I click the subtraction button
    Then I should see the result as "4"

Conclusion: Quality is a Shared Responsibility

At Hexis, our testing framework does more than find bugs — it aligns our entire team around a shared goal: building quality into every step of development.

By combining human insight with BDD-driven automation, we ship features quickly and confidently — without ever compromising on reliability.

Quality isn’t an afterthought. It’s part of how we work.

Like what you read?

Spread the knowledge and share this post

More blog posts

->
->
Jump to: