Software testing: how to explain to the manager that 2 x 2 = 4?
A simple but sudden question almost perplexed: “Why should testers and not analysts, developers, or users test?” I’ll try to quickly substantiate, but most likely, I need outside help, such formulations require multilateral analysis and coverage, and, Despite many years of ownership of the topic, it may take time to think.
Let's start with the general education: the tester is a role in the IT team. Not the most, say, a high position in terms of rank and salary, but requiring special knowledge and skills.
1. If the leader does not understand the benefits of role sharing, then he and his team have not matured 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 economy or because of a lack of understanding of psychology. Savings - most often from poverty or from greed.
The psychotype of a person is important here:
1. Developers are creators.
2. Testers are destroyers. Other things being equal, testing efficiency is higher for someone who intentionally breaks the system.
1. A professional is always more effective than a subcontractor or station wagon. Axiom.
2. Sometimes a good IT professional can show results better than any tester. But the cost of such a resource can be much higher than the cost of attracting a tester. For example, Joel Spolsky wrote on his blog that three testers can be attracted for this money.
3. Exception: for small projects, small teams or for agile-development - it is efficient to use generalists, because project time is small, and communication costs in the form of exponential growth of the number of project participants — as described by F. Brooks — have not been canceled.
1. "Rake" ( jarg .) = The human factor. It is treated using automatic means.
2. "The frozen eye." A person is bored with checking repeatedly. Testers must be resistant to routine, repetitive operations. In order not to completely rely on a person, they use formalization - drawing up test plans, test cases (test cases), test checks - so that a person does not forget or invent, but performs strict verification steps.
1. Manual testing - there are many options for combining.
2. Automated testing, especially stress testing. Knowledge of tools, languages, protocols, techniques is required - and this requires specialization.
We look at the results of the survey - we rejoice / cry / improve the process / we hire testers - choose at will :) victor435.habrahabr.ru/blog/45899
My opinion is that there is no panacea, all arguments become significant in certain conditions, with a sufficient level of team maturity, formalization of processes , willingness to change the development process, the ability to implement tools, etc.
Disclaimer The article reflects my personal opinion. Your opinion is very important for the formulation of clear language and the search for truth in the role distribution during testing. Sincerely, Victor
Facts, arguments, opinions
Let's start with the general education: the tester is a role in the IT team. Not the most, say, a high position in terms of rank and salary, but requiring special knowledge and skills.
1. If the leader does not understand the benefits of role sharing, then he and his team have not matured 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 economy or because of a lack of understanding of psychology. Savings - most often from poverty or from greed.
Psychology
The psychotype of a person is important here:
1. Developers are creators.
2. Testers are destroyers. Other things being equal, testing efficiency is higher for someone who intentionally breaks the system.
A little about efficiency:
1. A professional is always more effective than a subcontractor or station wagon. Axiom.
2. Sometimes a good IT professional can show results better than any tester. But the cost of such a resource can be much higher than the cost of attracting a tester. For example, Joel Spolsky wrote on his blog that three testers can be attracted for this money.
3. Exception: for small projects, small teams or for agile-development - it is efficient to use generalists, because project time is small, and communication costs in the form of exponential growth of the number of project participants — as described by F. Brooks — have not been canceled.
Life examples:
1. "Rake" ( jarg .) = The human factor. It is treated using automatic means.
2. "The frozen eye." A person is bored with checking repeatedly. Testers must be resistant to routine, repetitive operations. In order not to completely rely on a person, they use formalization - drawing up test plans, test cases (test cases), test checks - so that a person does not forget or invent, but performs 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 stress testing. Knowledge of tools, languages, protocols, techniques is required - and this requires specialization.
Survey results
We look at the results of the survey - we rejoice / cry / improve the process / we hire testers - choose at will :) victor435.habrahabr.ru/blog/45899
My opinion is that there is no panacea, all arguments become significant in certain conditions, with a sufficient level of team maturity, formalization of processes , willingness to change the development process, the ability to implement tools, etc.
What can you add, habralyudi? Examples? Objections?
Disclaimer The article reflects my personal opinion. Your opinion is very important for the formulation of clear language and the search for truth in the role distribution during testing. Sincerely, Victor