Holding hands with the thieves guild

testing, plagiarism, and corporate world
a movie still from Ocean's Eleven from 2001
Ocean's Eleven, 2001

Disclaimer: Some people in the portuguese tech scene might have some memory of it, but I personally prefer to keep some details of this story “redacted”. It wouldn’t necessarily be fair for me to publicly call out people involved, not having myself worked with the company involved, and also not having factual knowledge of how the issues were afterward treated behind closed doors or knowing of all the facts that are not already in the public domain. What follows is, of course, my personal view and take on “it”. Read on.

Some months ago a startup from my home country was accused of plagiarism by several people and a seemingly well-established designer.

“I’m not supposed to give my opinion on this but…”

If you looked at that time at the designs they used on their website: they indeed looked like a mildly edited mashup of the previous work of the accusing-designer. A few weeks after I even ran across another designer of which designs also looked different from the initially plagiarised designer, but seemed back then to me like yet another plagiarised “victim”, with the difference that it wasn’t caught “publicly”.

I’m not familiar with how the laws work in cases like this, but at one point the designer also mentioned a takedown notice would be “happening soon”. Furthermore, the company also did what many companies do (especially a few in my home country), and tried to deploy the old card:

“We’re sorry (that you found out), BUT, we can explain, in fact, we would love to explain, and have a call with you…”

So they didn’t at the time really show an apparent will to admit any wrong-doing anytime soon, which might make sense from a “corporate” point-of-view.

My guess is, some companies might throw this card around a lot to see if they can fool accusers or repair some “Public Relations” damage by being “smarter” (or smartasses) if for instance, they’re dealing with gullible accusers. I’m not sure, and frankly, I don’t care much, now again, I’m not the right one to jump to conclusions, or to judge, these matters should be taken by people who are experts and craftsman probably in Law and Copyright related matters.

But… this whole matter raised a few questions on my own, as a tester.

Can a tester be stupidly blamed for this issue?

Throughout my career, which hasn’t even reached a decade, I’ve seen testers being blamed in multiple, sometimes valid, and other times idiotic and stupid ways for problems. For example, a typical scenario can be:

“Something bad happened, so let’s blame the person we believe should have magically foreseen and “cristal-ball” predicted that our rushed or poorly managed project ended up being released with ludicrous bugs and 0-day problems”.

Plus the usual culprits, or the best ways to shoot oneself in the foot, adding more “smoke to the room”:

“Can you QA this, anyone?”… “Did it pass QA?”… “Good sir/madam, I shall only release once QA has given their approval!”

le sigh

Confusion reigns!

To tackle this blame question, I believe we need to talk again about confusion: The confusion that reigns currently in our craft.

On one side: “The industry” still doesn’t understand testing as an important support activity of “investigating and informing”, but not necessarily magically preventing or “sealing a good fate” on products. Likewise the industry still hasn’t caught on what’s the actual role of someone responsible on the other hand for quality assurance (who sets up processes for “quality” and makes sure (measures?) they’re being followed, which is profoundly different than testing on its own, and not that you can’t do both). From personal experience: Lack of “understanding” is an accelerator for idiotic claims and finger-pointing, and this is no different in the testing craft, on multiple levels, be it technical as well as interpersonal.

On the other side: I’ve seen the lack of testing evidence encompassed by both modern and oldish “cheerleading agile testing quality assurance” mantras that setup great testers for failure right from the start. For example: defining a test strategy around the belief that “documenting about testing” is in itself evidence of testing. I’ve seen time and time again the frailty of the “infinite test-cases state-of-mind” crumble before real and moderately complex testing problems. Alas, we end up being the ones to blame, with fair reason, since we’re not doing a valuable support job for our projects or churning out meaningful evidence of testing. This added to the fact that confusion reigns, indeed, it’s easy to start pointing fingers at testers for any problem and “un”-reason.

So… can we as testers be blamed? Maybe. Do we end up getting blamed? Surely. Did the testers of that company that seemingly plagiarised someone’s else work get unfair blame and maybe shame? Probably.

Should a tester try to find this type of issues (plagiarism)?

Our world is both simple and confusing. Like seen in present times with the automotive sector and the fake carbon emissions scandals: some get the blame, some don’t. And the bottom fish usually “gets it” more often.

So, shouldn’t a tester always fight to find “wrongdoing” made by someone else? Shouldn’t that tester ethically feel compelled to voice about these types of issues of plagiarism?

But with regards to plagiarism in projects, to be honest I don’t know what to think. I know plagiarism is wrongdoing, but what if the employers of the tester block the tester from investing time or attention in investigating points of plagiarism?

If “our” main mission is to support “our” projects, to its core, by hunting down with any means necessary the risks and bugs in a product, and relaying them back to people who matter - why wouldn’t we hunt down for plagiarism? Can we consider it a risk? A meaningful one at that? It certainly depends on the project’s moral code.

To think about what can be a meaningful and important “general” bug, I have to remind myself: to who does the value we’re trying to achieve with the project matters? Is it to some stakeholders? End-users? Are we stealing someone to create that value? Are we damaging someone to create that value? Are we damaging someone with the value itself (for example, software that exploits some people’s inclination towards addictive actions/behaviors)?

I know that as a tester, part of our story’s canon is “originality” of the product we’re building. And though we might often decrease its statute in our mental “importance ruler”, it’s still very much there next to the “seems to work” or “a potential user can indeed use this”… But plagiarism touches in its essence originality of work.

At the end of the day, blamed or not, I take it personally if I miss a meaningful and important bug. And my gut feeling tells me, with the ever-increasing state of the web, originality is as important nowadays as it has ever been. Purposely adopting a stance of not caring for it, is doing a disserve to my “users” as a tester.

If on the other hand, my “users” (or their “representatives”) dismiss originality as a meaningful problem, and in order to achieve they see no impediment in representing the work of others as its own, there’s not a lot I can do to change that, but I’m not tied, I can still take a stand for or against it.

In the end, maybe to efficiently spot and at the same fight against plagiarism within projects, one should have a dedicated kind of professional to help do this, that has on their belt the tools and knowledge I don’t have on my belt. What do you think?

Wrapping-up

How can a tester deal with stakeholders who ignore unlawful practices?

Leave of course! Just kidding. Not! If you can’t leave: Try to leave. I often joke every day around my peers: “Let’s go mates, off to change the world of the internet!”; The most attentive of them often reply “Change it for the better or the worst?

And I think that might just be the deal in this case. If I’m OK with something, props to me. But if it takes a toll on my moral code, then I’m better off elsewhere. Not everyone has a cunning and sharp tongue at “office politics”, and the rule of thumb is software developers and testers usually don’t have “it” to overnight change ingrained project-culture attitudes. With that said, we can try sometimes to stay and change something, but we have to consider: “for better or worse, do we want to get involved with this?”

There’s not a lot of sugar coating one can do in this: do we want to be software testers or developers for stakeholders or “high-level” user representatives who are, even if not overtly apparent, “outlaws”? Are we ready to face any consequences that come from it?