3 ms·

> When I've worked for organizations without QA teams, I introduce the concept of "sniff tests". This is a short (typically 1 hour) test session where anybody i

> When I've worked for organizations without QA teams, I introduce the concept of "sniff tests". This is a short (typically 1 hour) test session where anybody in the company / department is encouraged to come and bash on the new feature. We call those bug-bashes where we work, and they're also typically very productive in terms of defects discovered! It's especially useful since during development of small features, it's usually just us programmers testing stuff out, which may not actually reflect how the end users will use our software.

steveBK123 3y ago
A good QA person is basically a personification of all the edge cases of your actual production users. Our good QA person knew how human users used our app better than the dev or product team. It was generally a competition between QA & L2 support as to who actually understood the app best. The problem with devs testing their own & other devs code is that we test what we expect to work in the way we expect the user to use it. This completely misses all sorts of implementation error and edge cases. Of course the dev tests the happy path they coded.. that's what they thought users would do, and what they thought users wanted! Doesn't mean devs were right, and frequently they are not..
- justinator 3y ago
  This dude gets it.
- fatnoah 3y ago
  > It was generally a competition between QA & L2 support as to who actually understood the app best. So true!
  - steveBK123 3y ago
    And to clarify specifically because those who haven't experienced don't understand it... The uses of your app as intended by the authoring developers never matches the uses of your app out in the wild in the hands of human users. Over time, power users develop workflows that may go unknown by dev/product/management and are only well understood by QA / L2 support. The older the app, the more the divergence
danny_taco 3y ago
Maybe we work in the same company. I'd like to add that usually the engineer responsible for the feature being bug-bashed is also responsible of refining the document where everyone writes the bugs they find since a lot are duplicates, existing bugs, or not bugs at all. The output is then translated into Jira to be tackled before (or after) a release, depending on the severity of the bugs found.

steveBK123 3y ago

A good QA person is basically a personification of all the edge cases of your actual production users. Our good QA person knew how human users used our app better than the dev or product team. It was generally a competition between QA & L2 support as to who actually understood the app best. The problem with devs testing their own & other devs code is that we test what we expect to work in the way we expect the user to use it. This completely misses all sorts of implementation error and edge cases. Of course the dev tests the happy path they coded.. that's what they thought users would do, and what they thought users wanted! Doesn't mean devs were right, and frequently they are not..

justinator 3y ago
This dude gets it.
fatnoah 3y ago
> It was generally a competition between QA & L2 support as to who actually understood the app best. So true!
- steveBK123 3y ago
  And to clarify specifically because those who haven't experienced don't understand it... The uses of your app as intended by the authoring developers never matches the uses of your app out in the wild in the hands of human users. Over time, power users develop workflows that may go unknown by dev/product/management and are only well understood by QA / L2 support. The older the app, the more the divergence

danny_taco 3y ago

Maybe we work in the same company. I'd like to add that usually the engineer responsible for the feature being bug-bashed is also responsible of refining the document where everyone writes the bugs they find since a lot are duplicates, existing bugs, or not bugs at all. The output is then translated into Jira to be tackled before (or after) a release, depending on the severity of the bugs found.