The heartbreaking reason they don’t buy into dedicated testers

Every time someone proudly states that, at the company they work for, testing is integrated into the programmer’s job, I can hardly avoid a grimace on my face.
Neither can I refrain from asking questions, which usually leads to the following conclusions.

Even though they might be familiar with a lot of definitely good practices (such as TDD and BDD) and a checking mindset —or, in other words, a “verifying that the system does what is expected to do” mindset—, they don’t really get what a genuine testing mindset implies.
So, it usually turns out that, at their company, nobody is in charge of investigating how/where/when a system might fail.
Yet, they don’t buy into dedicated testers.

Even though they apparently agree that, while building a software product, a lot of skills are required —hence nobody can do everything—, they get upset if someone says that all those programmers who lack a testing mindset may not be the best option to perform real (exploratory) testing.
Yet, they still don’t buy into dedicated testers.

What’s more, even though they might be working as Agile consultants —hence allegedly trying to foster collaboration instead of a blaming culture—, they may end up candidly admitting their underlying credo: “the role of tester encourages bad behaviour”.
This is actually why they don’t buy into dedicated testers.

How interesting and how heartbreaking this view is!
I would rather say that it might be the culture of the organization, and their misconceptions about testing, which encourages bad behaviour.

Nevertheless, some professionals —especially those ones who, while promoting change, are worryingly at ease with talking about testing in spite of their lack of knowledge of this discipline— won’t easily change their mind…
Which is ironic, isn’t it?

#ThisIsASeriousLackOfTestingMindset