4 ms·

There's a little bit of an insane assumption in this pitch that PMs should be writing tests because they are the ones that "care a about quality." With my engi

There's a little bit of an insane assumption in this pitch that PMs should be writing tests because they are the ones that "care a about quality." With my engineering hat on, I hate this idea because the message that devs don't care about quality (but PMs do) is not how I want to operate. With my PM hat on, I hate this because having the PM do test automation has got to be the lowest value activity you can ask the PM to do. That is, whatever the PM doesn't get to do because he's writing tests is almost certainly more valuable. So yeah this pitch is nuts. If your system makes it easy to define tests with no code, awesome and that should be useful by the teams that do testing today. Weird that it isn't their angle.

theptip 5y ago
A problem with having engineers own the tests is that if the engineer misunderstands how the feature is supposed to work, then both the code and tests will be wrong, but because they are consistently wrong the tests will be green. So the product owner still needs to do ad hoc testing to verify that things work as expected. I like the “three amigos” approach from BDD as a solution here. The product owner writes the initial acceptance criteria, ie specifies the product. Then sits down with an engineer and tester to edit the ACs into sensible Gherkin so they can be executed as tests. The tester goes off and builds the tests (implementing the Gherkin steps) and the developer builds the feature. At the end you bring them together and if the tests pass, you are quite confident that you met the requirements. (If the error is not obvious you all huddle and figure out where the misunderstanding was). The important thing here is that everyone gets together and makes sure they share an understanding of the feature. You could skip the Gherkin and write the tests some other way. But having the product owner think through the process of specifying the acceptance criteria cleanly is a good exercise, I think. Now I don’t think that means they need to own the tests… but there is a case for it not being the engineer that’s implementing the feature, for sure.
- musingsole 5y ago
  > The important thing here is that everyone gets together and makes sure they share an understanding of the feature So true. Communication is everything, but because it's hard it gets short circuited everywhere. Where I work, devs write their own tests. It's as terrible as you can imagine while still having a successful product. I once suggested we split to a designer/verifier model...and got the weirdest blank stares. I honestly think it's because no one I work with wants to talk to each other.

theptip 5y ago

A problem with having engineers own the tests is that if the engineer misunderstands how the feature is supposed to work, then both the code and tests will be wrong, but because they are consistently wrong the tests will be green. So the product owner still needs to do ad hoc testing to verify that things work as expected. I like the “three amigos” approach from BDD as a solution here. The product owner writes the initial acceptance criteria, ie specifies the product. Then sits down with an engineer and tester to edit the ACs into sensible Gherkin so they can be executed as tests. The tester goes off and builds the tests (implementing the Gherkin steps) and the developer builds the feature. At the end you bring them together and if the tests pass, you are quite confident that you met the requirements. (If the error is not obvious you all huddle and figure out where the misunderstanding was). The important thing here is that everyone gets together and makes sure they share an understanding of the feature. You could skip the Gherkin and write the tests some other way. But having the product owner think through the process of specifying the acceptance criteria cleanly is a good exercise, I think. Now I don’t think that means they need to own the tests… but there is a case for it not being the engineer that’s implementing the feature, for sure.

musingsole 5y ago
> The important thing here is that everyone gets together and makes sure they share an understanding of the feature So true. Communication is everything, but because it's hard it gets short circuited everywhere. Where I work, devs write their own tests. It's as terrible as you can imagine while still having a successful product. I once suggested we split to a designer/verifier model...and got the weirdest blank stares. I honestly think it's because no one I work with wants to talk to each other.