About testers owning the requirements or the product

In a way this blog post is related with the previous two( see here and here), regarding the problem of testers being underrated.

It’s related because a solution to the problem of unrated testers, is, for some, to encourage the idea that testers should own the requirements. But there’s more to this, it’s not enough for them to encourage the owning of requirements/product, but also the following two ideas are being enforced:

– to present the idea of “automation testing” as a holy grail of testing. And that this “automation testing” is a byproduct of Continuous Integration or Continuous Delivery(no, I am not against CI or CD, just to be clear);

– testers to be the right hand of Product Owner’s(PO) or a extension of the PO’s role.

So is this ok? I think not, I think there are some flaws in how things are being associated. Flaws which show a lack of understanding regarding what testing is.

The testers should not own the requirements. If they own the requirements they have to be the BA or PO or… . Testers must find relevant information regarding requirements, information that if it is not known at the proper time, will be problematic for the product/project/delivery/team. If the tester wants to own the requirements, then he/she is no longer a tester but a BA/PO/…The tester has that special mindset that is different from all team members, he/she must always be thinking where negative/unwanted/bad things can happen. If he/she owns the requirements then he/she will try to protect them; when actually the tester has to dissect and analyze them from all the angles, to challenge their status quo.

Just think about basic stuff regarding security testing, and the mindset to do it. The tester must use all models/techniques available to knock down/find bad stuff, not to own a thing which will never be complete. Why? Because “We always know more than we can say, and we will always say more than we can write down”(1) -And you want to limit the tester to owning the requirements? I hope not.

A tester has the same importance as a BA, PO, Programmer, PM, Team Lead,UX,etc. The tester must be the bridge between useful information and all members/colleagues/clients,  which need that information.

The testers do not drive the delivery, they are, as James Bach says, “light of the car in the night” – this is the correct metaphor – but this means those lights do not own the car….

I think (I could be wrong), a lot of testers want to be the gatekeeper because of a bad self image, but also of the bad image testing/testers have nowadays. I understand where that bad image is coming from, when their work is reduced to test cases, number of test cases and automation of test cases.


(1) Dave Snowden, “Rendering Knowledge”, http://cognitive-edge.com/blog/rendering-knowledge/

Leave a Reply

Your email address will not be published. Required fields are marked *