The title is a bit clickbait-y, right? But I can't help but directly addressing something from UKStar Conference and a talk I was not at, summarized in a tweet:
If a developer tells me something cannot be fixed (and that is a lie), there are other developers to pick up that lie. And if they all lie on that together, I need a third party developer to find a way to turn that misconception into a learning of how it is possible to do after all. I don't have to be able to do it myself, but I need to understand when *impossible* is *unacceptable*. And that isn't technical, that is understanding the business domain.
If a developer tells me something is done when it isn't, the best lie detector isn't going and reading the code. Surely, the code might give me hints of completely missing implementation or bunch of todo-tags, but trying out the functionality reveals often that and *more*. Why would we otherwise keep finding bugs when we patiently go through the flows that have been peer reviewed in pull requests?
Back in the days, I had a developer who intentionally left severe issues in the code he handed to testing to "see if we notice". Well, we did.
And in general, I'm happy to realize that is as close to systematic lying I feel I have needed to come to.
Conflicting belief systems are not a lie. And testers are not a lie detector, we have enough work on us without even hinting on the idea that we would intentionally be fooling each other.
There's better reasons to be a little technical than a lying developer fallacy.
As a tester, the services I provide are not panacea for all things wrong with the world. I provide information, usually with primary emphasis on the product we are building with an empirical emphasis. Being an all around lie detector in a world does not strike me as the job I signed up for. Only some of the lies are my specialty, and I would claim that me being "technical" isn't the core type of lie (I prefer illusion) that I'm out to detect."Should testers be more technical?" "Yes." "Why?" "Because otherwise we [developers] lie to you. A lot." Perfect 👌 #UKSTARconf— Hannah Mason (@Sparrowsgo) February 28, 2017
If a developer tells me something cannot be fixed (and that is a lie), there are other developers to pick up that lie. And if they all lie on that together, I need a third party developer to find a way to turn that misconception into a learning of how it is possible to do after all. I don't have to be able to do it myself, but I need to understand when *impossible* is *unacceptable*. And that isn't technical, that is understanding the business domain.
If a developer tells me something is done when it isn't, the best lie detector isn't going and reading the code. Surely, the code might give me hints of completely missing implementation or bunch of todo-tags, but trying out the functionality reveals often that and *more*. Why would we otherwise keep finding bugs when we patiently go through the flows that have been peer reviewed in pull requests?
Back in the days, I had a developer who intentionally left severe issues in the code he handed to testing to "see if we notice". Well, we did.
And in general, I'm happy to realize that is as close to systematic lying I feel I have needed to come to.
Conflicting belief systems are not a lie. And testers are not a lie detector, we have enough work on us without even hinting on the idea that we would intentionally be fooling each other.
There's better reasons to be a little technical than a lying developer fallacy.
