We often talking about gatekeeping in testing as a problem in the sense that testers shouldn’t be the ones that decide when something goes out to production. But “gatekeeping” can also be used in the sense of excluding others. In fan communities you might hear “you aren’t a real Marvel fan if you’ve only seen the movies”. In software dev, a common example is “you aren’t a real web developer if you only know vanilla Javascript” or “you aren’t a real developer if your github commit history isn’t all green.”
I’ve become somewhat jaded with the testing discourse online in part because I think testers, as a community, tend to be guilty of this as well, albeit less explicitly. When the idea for this post first came to mind, it wasn’t until I saw few recent viral moments on twitter about gatekeeping developers that I made the connection.
Probably the most obvious example is the consistent myth that there is a “tester’s mindset” that precludes developers from being able to test their own code. This is what enables a “gatekeeper to production” role to develop in the first place, and creates bottlenecks as multiple developers funnel every ticket through limited testing people on a team.
Plenty of ink has already been spilt on why this false dichotomy is detrimental. But, we do it in more subtle ways as well.
Testers of all stripes, famously and annoyingly, love to debate terminology. Take the “testing vs checking” question. Some well-known testers feel very strongly that these need to be differentiated, and that it is detrimental to the craft of testing if we aren’t careful about which we use. I understand the historic contexts that led to a need for that distinction (for one, it was a reaction against “let’s just automate everything”). But never once have I seen the value of making that distinction when talking to a developer on a project. The only people who do are testers talking to other testers about testing, and failing to make that distinction can be flagged as a sign that you aren’t a real tester.
In that same category I would add much of tester jargon and debates: “oracles”, “heuristics”, whether a tool is a test tool or not, testing vs QA (“but you can’t assure anything”, the real testers say). I once saw a conference speaker refer to the work of “Jerry” (no last name) several times before someone in the crowd had to stop them and ask “who’s Jerry?” (Are you a real tester if you haven’t read any Gerald Weinberg?)
Again, these are subtle definitions and debates that can be interesting to testers talking to testers about testing. We run into problems, however, when we expect that every person who tests should already know, understand, or care about them. They are almost never interesting to a product team talking about testing an application.
So, yes: put all of those on the list of things I no longer care about as a tester. I’ve written about that before. More importantly, put them on the list of things I don’t expect anybody else to care about either. They’re not prerequisites to being a good tester nor being able to test. Plenty of testers do good work outside the twitter-sphere and conference circuit. We should not be using these inside-baseball details as shibboleths to filter out the real testers and exclude those who would be allies.
Top comments (0)