Month: November 2018

Testers, testing, automation, tool(s), continuous integration

Automation for a tester (a good one) should not be guided by the Continuous Integration(CI). I expect that tester to do the job regardless if he/she will use some tools. To do/use whatever ingenious tool( or approach with tool) he/she considers fit, and not to be limited by CI and Continuous Delivery(CD). For that tester, when he/she  thinks about automation (actually “tools” is the right word), he/she should not have in mind only gherkin/ranorex/ui automation….In fact, when the tester will notice that these kind of tools are promoted/enforced he/she should be skeptical. Yes, if the tester can make use of them because it’s applicable, then why not, but they should not be caught in a trap with these tools and see nothing else beyond them.

Regarding CI and “automated testing”(checking is the right word not testing, semantics matter(1)), just to be clear, they are useful but they are not “the path, the way and the truth”.

Let’s do a small exercise: Can you imagine a situation in your product/project where 12 things are related? By 12 I mean persons, requirements, things in source code. Regarding a person, from anthropology, we know that he/she has multiple identities and he/she shifts between them(2). If we have 12 dots, this means the number of possible links is 12(12-1)/2=66. But the number of possible patterns is: 2 at the power of 66=4,700 quadrillion patterns(3). At this level, we no longer speak about deduction, induction, but abduction.  Now think again at CI with the automated checks and number of test cases written and executed…something is not ok, right? Somehow I begin to see the cons of blindly believing in CI/CD.

(1) James Bach, Michael Bolton, “Testing and Checking Refined, https://www.satisfice.com/blog/archives/856

(2) Dave Snowden, “The landscape of management: Creating the context for understanding social complexity”, https://www.researchgate.net/publication/228449006_The_landscape_of_management_Creating_the_context_for_understanding_social_complexity

(3)”The problem of connecting the dots”, https://sensing-ontologies.com/the-problem-of-connecting-the-dots/

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/