Automated testing is broken

Are you a product manager? Head over here.

Good software developers love writing unit tests (especially in the ruby community 😉 ). Unit tests provide a check and balance against code, enforcing not just functionality, but also separation of concerns and readability. Well-factored code and well-written unit tests are a sort of yin and yang of developer happiness (if you'll excuse the cultural appropriation).

But software developers hate writing functional tests. Almost by definition, functional tests encompass multiple concerns. They feel sloppy, and in some cases they're nondeterministic. They tend to run slowly with lots of overhead and complexity.

Most importantly: functional tests usually assert product requirements, as opposed to engineering requirements. A unit test might assert 'this service object returns an integer', while a functional test asserts 'a user can log in'.

Now, we're huge proponents of product-minded engineers, but this presents an ownership problem. The true owner of the requirement (the product manager) is not responsible for building, maintaining or running the test.

So you've got developers doing something they hate, to cover a requirement that they don't own. The result shouldn't surprise anyone: developers write the bare minimum of functional tests, covering some semblance of the product's requirements, and hack at them until they're green.

But there's a silver lining to this cloud. This problem has a simple solution: share ownership of product-level functional tests with the product owner.

In the past this wasn't possible (non-technical folks couldn't actually write, run or maintain tests), but with Parrot QA it is.

---