Structuring a suite four teams share

The intermediate track showed you how to organise a suite by feature. That structure holds until about the point where a second team starts contributing. Then it breaks in a way that has nothing to do with folders.

Here is the failure I have watched happen twice.

A shared login command lives in support/commands.js. Four teams use it. The payments team needs it to accept a second argument. They add it. Two weeks later the accounts team's suite fails in a way nobody connects to that change, because the person who made it had no idea who else depended on it.

The real problem is not structure. It is that shared code had no owner and no contract.

So the senior question is not "which folders?" but "who owns what, and what may they change without asking?"

Three layers, with different ownership rules.

cypress/
  e2e/
    payments/          owned by the payments team
    accounts/          owned by the accounts team
    checkout/          owned by the checkout team
  support/
    core/              shared, changes need review from all teams
      commands/
      auth/
      api/
    payments/          team-local helpers, that team may change freely
    accounts/
  fixtures/
    core/
    payments/

Team folders are owned outright. A team changes anything inside theirs without consulting anyone.

support/core is shared infrastructure. Changing it can break every team, so it gets the strictest review. Most organisations enforce this with a CODEOWNERS file, which makes the ownership real rather than a convention in a wiki nobody reads.

Team-local support is the pressure valve. Without it, every helper gets pushed into core and core becomes a dumping ground.

Config inheritance. Cypress config is JavaScript, so it composes:

// cypress/config/base.js
module.exports = {
  e2e: {
    baseUrl: process.env.BASE_URL,
    supportFile: 'cypress/support/e2e.js',
    retries: { runMode: 2, openMode: 0 },
  },
};

// cypress/config/payments.js
const base = require('./base');
module.exports = defineConfig({
  ...base,
  e2e: { ...base.e2e, specPattern: 'cypress/e2e/payments/**/*.cy.js' },
});

Now a team can run only their own specs, which matters enormously for feedback speed. A payments engineer waiting 40 minutes for other teams' tests will stop running tests.

The decisions that actually matter, and these are the ones a senior is expected to make:

Decide what is core before people need it. Auth, API clients, data builders and selectors policy belong in core from day one. If they start in a team folder they get copied, and then you have four logins.

Version the shared layer, or at least announce changes. Some organisations publish core as an internal npm package precisely so it has a version number and a changelog. That is heavier, and it is the right answer above a certain size.

Write down the selector policy. Not the selectors, the policy: test IDs required, what the naming convention is, who adds them. Without this, four teams invent four conventions and cross-team tests become impossible.

One suite or several repositories? Monorepo keeps shared code actually shared and makes cross-team changes atomic. Separate repositories give teams independence and duplicate everything. For QA suites specifically, monorepo usually wins, because the shared layer is most of the value.

Remember this: at scale, structure is an ownership contract. Folders are just where you write it down.

Reference: Cypress configuration.