Software testing: how to explain to a manager that 2 x 2 = 4?

A simple but sudden question almost puzzled: “Why should testers test, not analysts, developers or users?” I will try to quickly justify, but most likely, outside help will be needed, such wording requires multilateral analysis and coverage, and despite many years of ownership of the topic, it may take some time to think.

Facts, arguments, opinions

Let's start with general education: tester - a role in the IT team. Not the most, say, high position in rank and salary, but requiring special knowledge and skills.
')
1. If the manager does not understand the benefits of role-sharing, then he and his team are not mature methodologically. RUP, MSF methodologies allow analysts, but not developers, to combine the role of a tester. Extreme techniques go further - there you can combine almost all the roles.
2. If a leader tries to combine roles, then this is due to savings or due to a lack of understanding of psychology. Savings - most often from poverty or greed.

Psychology

Here the person's psychotype is important:

1. Developers are creators.
2. Testers are destroyers. The effectiveness of testing, other things being equal, is higher for those who intentionally break the system.

A little about efficiency:

1. A professional is always more effective than a subcontractor or wagon. Axiom.
2. Sometimes a good IT professional can show results better than some tester. But the cost of such a resource may be much higher than the cost of attracting a tester. For example, Joel Spolsky also wrote in his blog that for this money you can attract three testers.
3. Exception: for small projects, small teams, or for agile development, it is efficient to use generalists, because project time is short, and communication costs in the form of exponential growth from the number of project participants — as described by F. Brooks — have not been canceled.

Examples from life:

1. "Rake" ( jarg .) = The human factor. It is treated using automatic tools.
2. "Soiled eye". Man bothers to check repeatedly. Testers should be resistant to routine, repetitive operations. In order not to completely rely on a person, formalization is used — drawing up test plans, test scenarios (test cases), test checks — so that people do not forget and invent, but perform strict verification steps.

Let's look from the side of resources and tools:

1. Manual testing - there are many options for combining.
2. Automated testing, especially - load. Knowledge of instrumentation, languages, protocols, techniques is required - and this requires specialization.

Survey results

We look at the results of the survey - we rejoice / weep / improve the process / hire testers - choose at will :) victor435.habrahabr.ru/blog/45899

My opinion is that there is no panacea, all arguments become meaningful in certain conditions, with a sufficient level of team maturity, formalization of processes, readiness to change the development process, ability to implement tools, etc.

What can you add, habra people? Examples? Objections?

Disclaimer The article reflects my personal opinion. Your opinion is very important for the formulation of clear formulations and the search for truth in the role-based distribution during testing. Sincerely, Victor