Tester - more than a profession
During my work in the field of testing, I had my own special opinion about this area, starting from the position of junior tester (junior tester) to the head of the test manager. And, in general, this opinion is quite critical with a share of love and adoration for this wonderful profession.
')
I was never going to become a tester - I was more attracted to development. From school, I wrote programs that were already tested by my classmates and then classmates: I was interested in solving problems and reviving things, and I dealt with the problems and bugs I was having after they were reported to me by users. I attributed to the version a minor tsiferka, and ... and in some balance between functionality and quality, the program remained forever, giving way to new projects and programs.
Looking ahead, I will say that partly in this lies the key to successful project management - in finding a balance between the costs of product development and its quality. Any product is similar to a biological organism, in the formation of which not one person, but many participate directly or indirectly. In the formation of a good product should involve all stakeholders, and each of them should make a significant contribution to the common cause. But, to my surprise, testers occupy a special niche in this regard: firstly, they are a link in the process, and secondly, they are the only engineers who have the right to veto the release of a product version.
I found out about all this in my first place as a tester with unquenched developer ambitions. First of all, I was fascinated by the opportunity to gain access to product management, a power I did not count on. It was great, something special, above writing the next functionality. Secondly, due to the peculiarities of the profession, testers have a greater understanding of the processes and goals of the product, partly transmitting business goals to developers, and the result of developers to managers. Unfortunately, in the world and, especially, in Russia, the idea of ​​the role of the tester is very messy, and its value is greatly underestimated. And those companies that are still in the trend, try to develop areas of testing and quality management, although they set somewhat overestimated goals: “to find all the errors, to minimize the cost of development through testing.”
This article, primarily written in explanation of communication with various companies, is the quintessence of the answers to their questions. Secondly, it is addressed to novice testers and those people who want to learn more about testing from the point of view of domestic cuisine. Thirdly, it is based solely on my (subjective) experience.
Android SDK includes a wonderful tool called MonkeyRunner, which allows you to automate the process of testing Android applications ideally without source code, without special knowledge of programming languages ​​(only a general understanding of scripting languages ​​is enough) and, most importantly, to imitate any behavior of a real user. The result is a kind of scripting monkey that pokes, prints, reads the application. The most that can be “outsourced” to the machine. For me, this understanding of testing in the order of things. But, to my surprise, when I was looking for work for the first time after my first job as a tester, it turned out that there is a strange division in the market (to this day!) Into “manual” and “automatic” testers, moreover, the ladder grades are altogether so mixed and stretched that you wonder. Not to mention the fact that from company to company the same positions imply different duties, especially for senior positions.
My duties included: drawing up a test design, test cases, testing strategies (if it was a project assigned to me), reporting bugs, checking documentation, and creating test documentation. This was taken for granted by me, although it was somewhat surprising that the Western colleagues had shared these responsibilities. In the market, it turned out that it is quite commonplace that design is written using CTE / UML (at best) Test Lead / Senior Tester / Test Designer. Test cases (a variety of strategies for checking boundaries, interface testing, load, bench cases) - Senior Testers. And, finally, there are the lowest positions of "performers" - Tester. In some companies and departments, their number can reach up to 20 or more people! In other words, there were monkeys on the project staff, at best, with computer user skills and some kind of product.
In fact, this is ... somewhat wrong. Because the tester is not a monkey. If this is not the case, then either you, as a company, produce different products in a short time, without further support and quality, banishing formal smoke tests, or, more likely, your manager / architect is a ram.
The cost of testing automation does not pay off immediately.
For those familiar with the theory of testing (of which, as practice shows, not so much), it is quite obvious that the need for automation strongly depends on the specifics of the project (its timing, support, repeatability, etc.). In some cases it is much more preferable to do smoke tests and user beta testing and perform acceptance through the product owner, rather than complicate the processes. There should also be a clear understanding of product acceptance: high-level and low-level. In the first case, within the project, it is possible to define the roles and accept the product to the owner of the product; In the case when testing is nevertheless required separately, it is much simpler and more efficient to have the product life cycle of a person and a management team set up by the management or a team of engineers capable of independently covering the product deployment and testing tasks, i.e. people who know a priori area, tools and methods, and not a herd of monkeys, which are hung on the developers or one project manager.
Because of the hodgepodge of monkeys in the profession of testers, there are enough people who are far from the engineering field and sometimes do not even have a corresponding technical education. This is really sad and sad, because today there are really not enough qualified resources on the market of testers - competent experts prefer to go into development (in the best case, close to the topic analytics), and those that remain have little understanding of the software life cycle, testing and programming languages.
In my opinion, any tester should have technical knowledge, confident possession and at least basic skills of administration of application programs and popular operating systems. In addition, the tester should have at least a basic understanding of programming languages, be able to read the code at least at an intuitive level, and also quickly adapt to new languages ​​and programs / environments. In general, the main features of a tester are flexibility and learning. Therefore, having experience in programming and a general understanding of scripting languages ​​and high-level languages, a person will be able to learn and adapt without any problems. Ideally, knowledge of the scripting language and the fundamentals of the development language on which the project is based is required.
From all this it follows that the tester must be able to work with the code. Although, ideally, a good process should be executed according to the black box model. Nevertheless, the tester should not be afraid to look into it, in this Pandora's box, and help the developer with the problem. That is, to be like a fish in water in the system is not only a bugtracker, but also control of code versions, and be able to conduct a review of the code.
Despite the fact that in the overwhelming majority of cases, I hear the opinion that the process of reviewing code, debugging and unit testing is the prerogative of developers, I will dare to say that this is the wrong approach. The problem comes from the lack of qualifications of testers and inadequate software lifecycle management. Perhaps this approach works well in small TDD projects, but the main strength and ability to provide high quality products is to break the spheres of influence, responsibility, ensure the principle of separability (dissimilarity). This will make the development process more transparent, traceable and will compensate for the "effect of blurred eyes »Developers, to avoid" tricks "on their part.
During almost every interview for the position of the test manager, you can hear a question about how the applicant is going to build the testing process and what metrics from the project he is going to shoot, what metrics he will use in relation to himself. In fact, there are a lot of options for metrics - quantitative and qualitative - but they will not have much sense until they are in the project of effectiveness in a team. In a team in the broad sense of the word, i.e., both within the department / testing team, and when interacting with a team of developers and customers from the business.
In practice, this means that it is useless to consider the number of developed tests (this is a progress metric), found bugs (in the worst case) as an indicator of the effectiveness of the testing team, even the rate of regressions, even synthetic metrics on the project (using the criteria of importance and workability), not to mention about idiotic (but still applicable for the KSLOC \ hour testing team). For a project manager, it may be a good CPI / SPI metric as a project KPI, which can be based on all metrics marked and compiled by the test manager. That is, a fairly abstract and high-level assessment, depending on the effort and the result. But provided that the teams work as a single organism.
For testers, this means that they are the binder, the driving wheel of the process that will make the software workable and meet the requirements. In the process of testing, this means both the testing itself, and the provision of a test of repeatability, documentation, possible problems and solutions to the problem (if it is visible from the testing side, if there is a lack of qualification), as well as re-testing of testing (VoV). In other words, the task of testing is both reproducing and re-checking all possible states, and (in the necessary and sufficient case) covering the complete test strategy and test plan (at least what is indicated in Quality Gates), removing the bugs and resolving them. through software developers and specifications. That is, from the moment of checking and detecting a bug, the responsibility on it is not “transferred” to the developer, but is accompanied by a tester until his permission. Roughly speaking, the tester is responsible for the bugs, and the developer is responsible for the features.
Here we come to the key differences between the tester and the developer, which in my article are very close and similar. Nevertheless, in terms of work style, developers are usually either perfectionists or “feature designers” (who like to code for the sake of code, functionality, and algorithms); Testers, on the other hand, are either pedants or automatizers (aspiring to automate automation). Therefore, in the project, the tester knows how to do it correctly, and the developer knows how.
Based on this, I repeat that the main thing is the result, which depends on a single team, and not only on the metrics in one progress, say, design development. And where the process sags more - the problem lies there, and real metrics fall there, which already in the context of a working synergistic project makes sense. It is possible that the long development of tests is not the fault of the designer, but the fault of the analyst, who transposed the requirements, is too difficult.
In the V-model of software development, it is clearly seen that the tester participates at all stages of the life cycle.
The similarity of the developer and tester, the blurred boundaries of the area with good qualifications - the main indicator of interest in the work of the tester. Of course, it can be argued that involvement in the product and its quality in the case of testing the black box is a motivational factor, but in my opinion, the person who came to the technical, engineering field did it consciously, with a desire to develop and work on himself. Therefore, the ability to expand your horizons, influence the quality of the product (even small things), be active, and also veto the release of a product from a tester, in my opinion, more weighty arguments for the profession. And if so, a good tester is not a monkey, but a research engineer, a connoisseur who participates at almost all stages of the life cycle of (as opposed to the roles of analysts, designers, developers, and technical writers), responsible for the quality of the product (not process, this is QA, so by “product quality” we mean compliance with the stated and approved requirements and standards, checklists and others), then to raise the quality of the product and develop yourself as a specialist, the test engineer must take an active position. He knows how to improve the product. He knows what is “good enough”, and how his product or process, so to do, to initiate the movement of both the developer engineer and other teams and even companies. For example, in any projects there are moments of downtime, which may be acceptable by management. Usually at this time, employees solve personal problems or engage in self-education. In relation to the work, the developer can do refactoring, study the algorithms and transfer to their projects. And what should the tester do? Learn new testing tools? It does nothing without the initial package from the developers / analysts. In fact, he can do the automation of his activities or the improvement of the products he uses, even if he is far from infrastructure and devops.
The last and strangest topic, in my opinion, is a very vague idea about testing (even about theory, not to mention practice). In many companies, the testing departments do not live up to expectations, in some even they have discredited themselves and function on a small part of their potential effectiveness for a number of factors. The problem stems from both the lack of school and the incompetence of management. The situation is very deplorable in industries remote from IT, even where “money is not a problem” - there tasks are set according to the principle “to improve the quality of the product”. Even in IT companies, where there is a general idea of ​​the processes, there are a number of problems associated with fixing on certain roles or tools, although I repeat that this approach is poorly applicable to testing.
In one of the large investment banks in which I had an interview, there was a similar requirement for the test manager's position: “to improve the quality and reduce the marriage”. Any problem can be solved. Although under the cover of tasks lies the coordination of departments for a number of different products, drawing up test plans, organizing testing, working with developers, drawing up a database of cases, and so on. In fact, it is logical to take responsibility for the quality of the products in the company to some “quality director”, it’s QA Director, and not just the head of the testing department. However, the matter here rests on the powers that are not in this position, and in the absence of a group that was not planned at all (which could help this and that). That is, the company needs a person orchestra without a team. The answer here is simple: management is looking for keywords, and considering quality in the abbreviation QA as a panacea for all problems, although it lies in the sphere of strategic top management and the processes that need to be descended from above with the appropriate powers and resources.
Ideally, quality management (QA) and testing are two non-overlapping entities .
The problem is systemic, since it is quite good when HR is searched for keywords like “load testing”, “functional”. But when the review process does not focus on testing skills, not on the candidate’s activity and flexibility, but on a specific tool, this is already a problem, especially when there is no mention of testing (there is ape), and not the fact that the required tool is more effective than who knows the applicant. The problem is that knowledge of a minor nuance or an instrument, the development of which will take several hours, is put at the forefront, above knowledge of programming languages ​​or theory. In one of the interviews, it was funny enough to answer the questions: “name some book on testing” and, answering about Sam Kaner, hear: “we don’t know anything like that, but did you read anything about the bug's life cycle?”. It would be funny if it were not so sad. It is sad when HR reports a refusal due to the lack of experience of the candidate, although it’s a matter of incorrect emphasis.
Finding a good tester is a big problem, because a tester is, ideally, a person who solves technical problems related to software development, a kind of problem solver. In addition to technical skills, it is very important for such a person to have attentiveness, an inquiring mind, to be active and to be able to communicate a thought and defend their point of view at any level. In some way, testers are researchers from the software development world. Therefore, in the hands of a tester an easily recognizable symbol - a magnifying glass (lens), observing the bugs. It characterizes the work of the tester as well as possible: it is used both for its intended purpose to detect defects and to “burn holes”, it can be used to make fire and even having a whole lens system, to observe the stars. The main thing is to be able to do it.
A tester is more than a profession. This is an image of a proactive life and the desire to make this life better for all by feasible and effective means. The objectives of the tester in relation to the product are closest to the goals of the business and the strategic goal of the company in relation to this product, and at the same time deep inside the company in the role of researcher. And if so, then its main qualities are energy, knowledge and flexibility. But at the same time, the work of the tester is not universal knowledge and responsibility for the quality of the product and the quality of services. Testing has boundaries: on the one hand, limited by the project and the requirements in it (the project management and the established program life cycle), and on the other, the processes for which QA is responsible. But the difference between QA and testing is a completely different matter.
')
As an introduction
I was never going to become a tester - I was more attracted to development. From school, I wrote programs that were already tested by my classmates and then classmates: I was interested in solving problems and reviving things, and I dealt with the problems and bugs I was having after they were reported to me by users. I attributed to the version a minor tsiferka, and ... and in some balance between functionality and quality, the program remained forever, giving way to new projects and programs.
Looking ahead, I will say that partly in this lies the key to successful project management - in finding a balance between the costs of product development and its quality. Any product is similar to a biological organism, in the formation of which not one person, but many participate directly or indirectly. In the formation of a good product should involve all stakeholders, and each of them should make a significant contribution to the common cause. But, to my surprise, testers occupy a special niche in this regard: firstly, they are a link in the process, and secondly, they are the only engineers who have the right to veto the release of a product version.
I found out about all this in my first place as a tester with unquenched developer ambitions. First of all, I was fascinated by the opportunity to gain access to product management, a power I did not count on. It was great, something special, above writing the next functionality. Secondly, due to the peculiarities of the profession, testers have a greater understanding of the processes and goals of the product, partly transmitting business goals to developers, and the result of developers to managers. Unfortunately, in the world and, especially, in Russia, the idea of ​​the role of the tester is very messy, and its value is greatly underestimated. And those companies that are still in the trend, try to develop areas of testing and quality management, although they set somewhat overestimated goals: “to find all the errors, to minimize the cost of development through testing.”
This article, primarily written in explanation of communication with various companies, is the quintessence of the answers to their questions. Secondly, it is addressed to novice testers and those people who want to learn more about testing from the point of view of domestic cuisine. Thirdly, it is based solely on my (subjective) experience.
Thesis number 1: Tester - not a monkey
Android SDK includes a wonderful tool called MonkeyRunner, which allows you to automate the process of testing Android applications ideally without source code, without special knowledge of programming languages ​​(only a general understanding of scripting languages ​​is enough) and, most importantly, to imitate any behavior of a real user. The result is a kind of scripting monkey that pokes, prints, reads the application. The most that can be “outsourced” to the machine. For me, this understanding of testing in the order of things. But, to my surprise, when I was looking for work for the first time after my first job as a tester, it turned out that there is a strange division in the market (to this day!) Into “manual” and “automatic” testers, moreover, the ladder grades are altogether so mixed and stretched that you wonder. Not to mention the fact that from company to company the same positions imply different duties, especially for senior positions.
My duties included: drawing up a test design, test cases, testing strategies (if it was a project assigned to me), reporting bugs, checking documentation, and creating test documentation. This was taken for granted by me, although it was somewhat surprising that the Western colleagues had shared these responsibilities. In the market, it turned out that it is quite commonplace that design is written using CTE / UML (at best) Test Lead / Senior Tester / Test Designer. Test cases (a variety of strategies for checking boundaries, interface testing, load, bench cases) - Senior Testers. And, finally, there are the lowest positions of "performers" - Tester. In some companies and departments, their number can reach up to 20 or more people! In other words, there were monkeys on the project staff, at best, with computer user skills and some kind of product.
In fact, this is ... somewhat wrong. Because the tester is not a monkey. If this is not the case, then either you, as a company, produce different products in a short time, without further support and quality, banishing formal smoke tests, or, more likely, your manager / architect is a ram.
The cost of testing automation does not pay off immediately.
For those familiar with the theory of testing (of which, as practice shows, not so much), it is quite obvious that the need for automation strongly depends on the specifics of the project (its timing, support, repeatability, etc.). In some cases it is much more preferable to do smoke tests and user beta testing and perform acceptance through the product owner, rather than complicate the processes. There should also be a clear understanding of product acceptance: high-level and low-level. In the first case, within the project, it is possible to define the roles and accept the product to the owner of the product; In the case when testing is nevertheless required separately, it is much simpler and more efficient to have the product life cycle of a person and a management team set up by the management or a team of engineers capable of independently covering the product deployment and testing tasks, i.e. people who know a priori area, tools and methods, and not a herd of monkeys, which are hung on the developers or one project manager.
Remark # 1
Surprisingly, this simple thesis is often deliberately violated. For example, for outsourcing companies, this is a good way to get additional FTEs. In terms of business, it is simply more profitable to sell more, something that has a low cost. In the experience of my work at Auriga, where the corresponding resources in the amount of tens of people were provided for hourly rates to customers, this is not an isolated case. Moreover, such a plan well covers the goals of project staffing for the client at minimal cost. Despite the fact that the load on the project manager increases significantly, with proper guidance, let it be to create a “forge of personnel” at the expense of the project, linking personnel to the company (training and skill growth) at a relatively higher price to buy a specialist from the market, and subsequent resale, staff rotation for more demanding projects.
Another reason for this strategy is the possibility of buying non-target personnel for the client. So it turns out that the requirements for personnel of your employers or clients are sometimes short-sighted (which will be discussed below), and the possibility of buying fictitious personnel is less expensive for the company (in terms of money and time). Say, the purchase of such “monkeys” for a project with the parameter “20 years of experience” (but perhaps being a very mediocre specialist). This is especially relevant in the Junior / Standard / Senior grade system of many companies, especially outside of Russia, where the experience requirements and realities are slightly different.
The next, and, in my opinion, the main reason is the risks. Setting tasks on a project for testing is covering certain functionality and actions. Often, processes can be automated, especially with regard to regular activities, regression testing, i.e., during the testing process, create a farm, process and infrastructure, often scalable, portable and portable to other products and projects with minimal costs. Reduction of “direct” work on a project for a tester leads to the following two consequences:
Therefore, this first thesis should be considered as a problem from a strategic perspective for any company, a problem of the role of testing and building up engineering processes. Its permission, competent graduation and the use of purely engineering personnel, is a sign of competent leadership and long-term planning in companies.
Another reason for this strategy is the possibility of buying non-target personnel for the client. So it turns out that the requirements for personnel of your employers or clients are sometimes short-sighted (which will be discussed below), and the possibility of buying fictitious personnel is less expensive for the company (in terms of money and time). Say, the purchase of such “monkeys” for a project with the parameter “20 years of experience” (but perhaps being a very mediocre specialist). This is especially relevant in the Junior / Standard / Senior grade system of many companies, especially outside of Russia, where the experience requirements and realities are slightly different.
The next, and, in my opinion, the main reason is the risks. Setting tasks on a project for testing is covering certain functionality and actions. Often, processes can be automated, especially with regard to regular activities, regression testing, i.e., during the testing process, create a farm, process and infrastructure, often scalable, portable and portable to other products and projects with minimal costs. Reduction of “direct” work on a project for a tester leads to the following two consequences:
- The tester becomes an automation tester, or he receives new areas of responsibility and new workload. In this case, its market price and demand for it grow, which causes the risk of its withdrawal or increase in salary claims, and this can be a big problem in one project and the inability to scale and rotate in the company.
- The risk of moving the system to the customer or outsourcing. In the case of an outsourcing company, this is the risk of losing FTE up to the loss of the project. Such risks are rarely included in project risk plans, although they are indirectly managed through the company's mission and the pressure of top management.
Therefore, this first thesis should be considered as a problem from a strategic perspective for any company, a problem of the role of testing and building up engineering processes. Its permission, competent graduation and the use of purely engineering personnel, is a sign of competent leadership and long-term planning in companies.
Thesis number 2: Tester is an engineering profession
Because of the hodgepodge of monkeys in the profession of testers, there are enough people who are far from the engineering field and sometimes do not even have a corresponding technical education. This is really sad and sad, because today there are really not enough qualified resources on the market of testers - competent experts prefer to go into development (in the best case, close to the topic analytics), and those that remain have little understanding of the software life cycle, testing and programming languages.
In my opinion, any tester should have technical knowledge, confident possession and at least basic skills of administration of application programs and popular operating systems. In addition, the tester should have at least a basic understanding of programming languages, be able to read the code at least at an intuitive level, and also quickly adapt to new languages ​​and programs / environments. In general, the main features of a tester are flexibility and learning. Therefore, having experience in programming and a general understanding of scripting languages ​​and high-level languages, a person will be able to learn and adapt without any problems. Ideally, knowledge of the scripting language and the fundamentals of the development language on which the project is based is required.
From all this it follows that the tester must be able to work with the code. Although, ideally, a good process should be executed according to the black box model. Nevertheless, the tester should not be afraid to look into it, in this Pandora's box, and help the developer with the problem. That is, to be like a fish in water in the system is not only a bugtracker, but also control of code versions, and be able to conduct a review of the code.
Despite the fact that in the overwhelming majority of cases, I hear the opinion that the process of reviewing code, debugging and unit testing is the prerogative of developers, I will dare to say that this is the wrong approach. The problem comes from the lack of qualifications of testers and inadequate software lifecycle management. Perhaps this approach works well in small TDD projects, but the main strength and ability to provide high quality products is to break the spheres of influence, responsibility, ensure the principle of separability (dissimilarity). This will make the development process more transparent, traceable and will compensate for the "effect of blurred eyes »Developers, to avoid" tricks "on their part.
Remark # 2
In the company Liebherr Aerospace rigidly lined up the processes and roles in the company. Strict adherence to industry-specific iterative models. However, the engineering wing, engineering positions are called for all the same - Software Engineer. The emphasis is on the fact that the employee in the company is first and foremost a specialist, software engineer. Hence, the employee must understand the engineering processes, the process of development, testing, circuit design, etc. Nevertheless, among engineers there is a mandatory division into a specialization: in Test, in Development, in Requirements, etc.
As the company follows rigidly engineering processes in order to maintain the highest quality, each part of the process is divided into independent participants. In practice, this means that each level of requirements is written by a separate person (group), design by others, code is written by third, unit testing by fourth, functional testing by fifth, and so on. At the same time, in order not to let “get bored” and “get bogged down” in the routine, people in the project are trying to rotate in function, and quite possibly, even on one project, the engineer will, in different iterations, cover different duties as far as possible. different stages of software development.
The fact that each of the stages and types of development and testing should cover different people follows from the requirements of international standards, such as DO-178B (for aviation), EN 50128 (for railway transport) or GOST R IEC 60880 (for nuclear power plants), and provides, ultimately, the highest fault tolerance at the process level, including in terms of software testing.
As the company follows rigidly engineering processes in order to maintain the highest quality, each part of the process is divided into independent participants. In practice, this means that each level of requirements is written by a separate person (group), design by others, code is written by third, unit testing by fourth, functional testing by fifth, and so on. At the same time, in order not to let “get bored” and “get bogged down” in the routine, people in the project are trying to rotate in function, and quite possibly, even on one project, the engineer will, in different iterations, cover different duties as far as possible. different stages of software development.
The fact that each of the stages and types of development and testing should cover different people follows from the requirements of international standards, such as DO-178B (for aviation), EN 50128 (for railway transport) or GOST R IEC 60880 (for nuclear power plants), and provides, ultimately, the highest fault tolerance at the process level, including in terms of software testing.
Thesis number 3: Metrics - nonsense, if there is no work in a team
During almost every interview for the position of the test manager, you can hear a question about how the applicant is going to build the testing process and what metrics from the project he is going to shoot, what metrics he will use in relation to himself. In fact, there are a lot of options for metrics - quantitative and qualitative - but they will not have much sense until they are in the project of effectiveness in a team. In a team in the broad sense of the word, i.e., both within the department / testing team, and when interacting with a team of developers and customers from the business.
In practice, this means that it is useless to consider the number of developed tests (this is a progress metric), found bugs (in the worst case) as an indicator of the effectiveness of the testing team, even the rate of regressions, even synthetic metrics on the project (using the criteria of importance and workability), not to mention about idiotic (but still applicable for the KSLOC \ hour testing team). For a project manager, it may be a good CPI / SPI metric as a project KPI, which can be based on all metrics marked and compiled by the test manager. That is, a fairly abstract and high-level assessment, depending on the effort and the result. But provided that the teams work as a single organism.
For testers, this means that they are the binder, the driving wheel of the process that will make the software workable and meet the requirements. In the process of testing, this means both the testing itself, and the provision of a test of repeatability, documentation, possible problems and solutions to the problem (if it is visible from the testing side, if there is a lack of qualification), as well as re-testing of testing (VoV). In other words, the task of testing is both reproducing and re-checking all possible states, and (in the necessary and sufficient case) covering the complete test strategy and test plan (at least what is indicated in Quality Gates), removing the bugs and resolving them. through software developers and specifications. That is, from the moment of checking and detecting a bug, the responsibility on it is not “transferred” to the developer, but is accompanied by a tester until his permission. Roughly speaking, the tester is responsible for the bugs, and the developer is responsible for the features.
Here we come to the key differences between the tester and the developer, which in my article are very close and similar. Nevertheless, in terms of work style, developers are usually either perfectionists or “feature designers” (who like to code for the sake of code, functionality, and algorithms); Testers, on the other hand, are either pedants or automatizers (aspiring to automate automation). Therefore, in the project, the tester knows how to do it correctly, and the developer knows how.
Based on this, I repeat that the main thing is the result, which depends on a single team, and not only on the metrics in one progress, say, design development. And where the process sags more - the problem lies there, and real metrics fall there, which already in the context of a working synergistic project makes sense. It is possible that the long development of tests is not the fault of the designer, but the fault of the analyst, who transposed the requirements, is too difficult.
Remake number 3
Despite the fact that the model I described speaks about the unity and interconnectedness of all stages of the processes, today testers are more correct to classify the developers of the tests themselves (stressing knowledge and knowledge of testing methodologies) and devops of engineers serving the infrastructure. The segregation of functions has its advantages with a sufficiently large project size and good funding, when infrastructure development, support and testing can be spread between engineers, ideally, between expert experts. The important point is that the test engineer is first and foremost an engineer, a developer in testing, who is able to use various tools to solve the problem. And only secondarily - an expert in a particular tool and program. Connoisseurs of toolkit, framework capabilities should be correctly classified as individual engineers, tool engineers.
Thesis number 4: Tester - the center of the software development process
In the V-model of software development, it is clearly seen that the tester participates at all stages of the life cycle.
The similarity of the developer and tester, the blurred boundaries of the area with good qualifications - the main indicator of interest in the work of the tester. Of course, it can be argued that involvement in the product and its quality in the case of testing the black box is a motivational factor, but in my opinion, the person who came to the technical, engineering field did it consciously, with a desire to develop and work on himself. Therefore, the ability to expand your horizons, influence the quality of the product (even small things), be active, and also veto the release of a product from a tester, in my opinion, more weighty arguments for the profession. And if so, a good tester is not a monkey, but a research engineer, a connoisseur who participates at almost all stages of the life cycle of (as opposed to the roles of analysts, designers, developers, and technical writers), responsible for the quality of the product (not process, this is QA, so by “product quality” we mean compliance with the stated and approved requirements and standards, checklists and others), then to raise the quality of the product and develop yourself as a specialist, the test engineer must take an active position. He knows how to improve the product. He knows what is “good enough”, and how his product or process, so to do, to initiate the movement of both the developer engineer and other teams and even companies. For example, in any projects there are moments of downtime, which may be acceptable by management. Usually at this time, employees solve personal problems or engage in self-education. In relation to the work, the developer can do refactoring, study the algorithms and transfer to their projects. And what should the tester do? Learn new testing tools? It does nothing without the initial package from the developers / analysts. In fact, he can do the automation of his activities or the improvement of the products he uses, even if he is far from infrastructure and devops.
Remake number 3
In Liebherr Aerospace, a hard process sharply limited the use of any tools and severely formalized the development and testing process, i.e. there wasn’t much room for automation - even intervention into the bugtracker was forbidden. Nevertheless, such a process as the preparation of documentation was automated during such periods, albeit using non-prohibited VBA for MS Office. And for the revision code process, static code analyzers could be improved. They did not quite meet the standards on the project and generated extra messages that were not filtered even by elementary grep. However, in order to reduce the time for manual review of the code, as part of the idle time, we worked for the future, improving a third-party product, such as a static analyzer, preparing a set of cases for it to implement the checks we need.
Thesis â„–5: Testing is not a place for fixing on keywords
The last and strangest topic, in my opinion, is a very vague idea about testing (even about theory, not to mention practice). In many companies, the testing departments do not live up to expectations, in some even they have discredited themselves and function on a small part of their potential effectiveness for a number of factors. The problem stems from both the lack of school and the incompetence of management. The situation is very deplorable in industries remote from IT, even where “money is not a problem” - there tasks are set according to the principle “to improve the quality of the product”. Even in IT companies, where there is a general idea of ​​the processes, there are a number of problems associated with fixing on certain roles or tools, although I repeat that this approach is poorly applicable to testing.
In one of the large investment banks in which I had an interview, there was a similar requirement for the test manager's position: “to improve the quality and reduce the marriage”. Any problem can be solved. Although under the cover of tasks lies the coordination of departments for a number of different products, drawing up test plans, organizing testing, working with developers, drawing up a database of cases, and so on. In fact, it is logical to take responsibility for the quality of the products in the company to some “quality director”, it’s QA Director, and not just the head of the testing department. However, the matter here rests on the powers that are not in this position, and in the absence of a group that was not planned at all (which could help this and that). That is, the company needs a person orchestra without a team. The answer here is simple: management is looking for keywords, and considering quality in the abbreviation QA as a panacea for all problems, although it lies in the sphere of strategic top management and the processes that need to be descended from above with the appropriate powers and resources.
Ideally, quality management (QA) and testing are two non-overlapping entities .
The problem is systemic, since it is quite good when HR is searched for keywords like “load testing”, “functional”. But when the review process does not focus on testing skills, not on the candidate’s activity and flexibility, but on a specific tool, this is already a problem, especially when there is no mention of testing (there is ape), and not the fact that the required tool is more effective than who knows the applicant. The problem is that knowledge of a minor nuance or an instrument, the development of which will take several hours, is put at the forefront, above knowledge of programming languages ​​or theory. In one of the interviews, it was funny enough to answer the questions: “name some book on testing” and, answering about Sam Kaner, hear: “we don’t know anything like that, but did you read anything about the bug's life cycle?”. It would be funny if it were not so sad. It is sad when HR reports a refusal due to the lack of experience of the candidate, although it’s a matter of incorrect emphasis.
Finding a good tester is a big problem, because a tester is, ideally, a person who solves technical problems related to software development, a kind of problem solver. In addition to technical skills, it is very important for such a person to have attentiveness, an inquiring mind, to be active and to be able to communicate a thought and defend their point of view at any level. In some way, testers are researchers from the software development world. Therefore, in the hands of a tester an easily recognizable symbol - a magnifying glass (lens), observing the bugs. It characterizes the work of the tester as well as possible: it is used both for its intended purpose to detect defects and to “burn holes”, it can be used to make fire and even having a whole lens system, to observe the stars. The main thing is to be able to do it.
Remark # 5
At Intel, an approach dominates the way in which tools are selected from the preferences of the employees on the project. This means that, in general, it does not matter what tool and language to choose to solve the problem, the main thing is to solve it. The coexistence of three different test engineers writing in three different languages ​​is quite acceptable, if the problem is solved, solved efficiently and the support costs are reasonable and the process is documented. In addition, many of the tools used are free, open-source or proprietary. Today there is a huge number of tools with which it is possible to solve various tasks, and the choice of tools should not limit the capabilities of the engineer. However, if the task really requires using a tool other than freely available, then with a clear understanding and justification, you can buy it and use it.Again, this is in line with business goals - not to hammer nails with a microscope, not to work efficiently, squeezing the maximum out of the tools, if the qualification of engineers allows to do with “small losses”. A good alternative is to participate in open source projects and invest in them for later use for their own needs. This approach kills two birds with one stone (their needs) and tasks and creates tools for the whole society in free use.
Instead of conclusions
A tester is more than a profession. This is an image of a proactive life and the desire to make this life better for all by feasible and effective means. The objectives of the tester in relation to the product are closest to the goals of the business and the strategic goal of the company in relation to this product, and at the same time deep inside the company in the role of researcher. And if so, then its main qualities are energy, knowledge and flexibility. But at the same time, the work of the tester is not universal knowledge and responsibility for the quality of the product and the quality of services. Testing has boundaries: on the one hand, limited by the project and the requirements in it (the project management and the established program life cycle), and on the other, the processes for which QA is responsible. But the difference between QA and testing is a completely different matter.
Source: https://habr.com/ru/post/221447/
All Articles