Post

Cory House
@housecor.com

Situation: You have a separate QA team or SDET embedded with your team. When should QA / SDET test a new feature? 3 options: 1. Before merge, in an ephemeral environment, or by pairing with dev 2. After merge in QA/UAT/staging environment 3. In prod My take? Prefer 1. 1/2

0 reposts10 likes

David Osolkowski
@qid.wadny.com

Now you can end up with two new problems: 1 it delays merging leading to lots more open merges and unmerged work, 2 unless you constantly rebase all those branches you’re not testing what you get when it’s merged and problems start appearing downstream.

Cory House
@housecor.com

Why 1? It shifts quality left. Or, consider 3, since prod testing is the only way to truly prove it works. Use feature flags to hide until QA approves. But avoid 2 - It leads to batching releases which inhibits continuous delivery.

andi0b
@sagdas.net

I disagree, this would mean that trunk based development doesn't work. But it does. It has it's limits, but also a lot of benefits. btw: trunk based doesn't mean no feature branches, they are "allowed" if they make sense, but not required trunkbaseddevelopment.com

andi0b
@sagdas.net

In tbd testing is usually done after merging (2), because many changes are just one commit to trunk (which I consider as "merged"). Those changes go to a test/qa/staging environment and can be tested there. Either one env, one per qa engineer, or even more.

andi0b
@sagdas.net

Depends on the merging/release strategy. It must be done in a way that the change can be excluded for the next release/prod deploy, if QA doesn't accept it. Trunk based can work really well even for bigger teams, as long as QA finds most issues and release cycles are long enough (>=2 weeks).

Bao Huynh
@bhuynh.dev

Before merge of course, so that bugs can be detected and fixed before merging. I imagine it'd be a bit frustrating to merge the PR first then having to make another PR only to fix small typos found during QA The QA env can be made to use any branch, whereas only main branch makes to production

Mads
@madsva.bsky.social

My take: Option 1: When the PR is created before merge. Setup a "fresh" env. Every time! The problem with option 2: for some reason those environments tend to "drift" and be "out-of-sync" with prod. Option 3: if you have really really good test coverage and ff, then this is a good alternative.