Testing: a clear career choice
This is a translation of the article .
Back in June, I read with great interest the article by John Stevenson, which discusses career growth for testers. At that time (and still) the article touched me lively, because similar issues began to be raised in my current company.
Translator's note: A small digression and a couple of words about that article. The article provides different statistics about testers - gender (75% of men, although, in my practice, I would say that the female gender prevails), the mode of development (coincides with this article) and the salary. I was very surprised by the latter, because if you believe it, testers on average get as many or more programmers and developers, which clearly differs from my experience (besides, the article focuses on less, although the numbers say the opposite) .
After some concerns about employee involvement, I (the head of the testers) and the rest of the heads of the functional part (software development, project management and technical development), engaged in conversations with all my people within our competencies. We have developed a set of questions aimed at obtaining a real picture: their current view of their careers and their role in the company.
')
Firstly, it was great, just going around and talking to everyone, and secondly, talking to all twenty testers gave me a pretty good idea of ​​where the problem areas lie.
John Stephenson writes in his article: “Yes, XXX was such an excellent tester, but he had to go to the developers to be able to develop in the company” and I heard this phrase in one form or another several times. In our case, this was a transition either to the developers or to the project managers. Both options were considered as the only real progress for the tester. // Translator's note: it is not entirely clear why the QA Engineer -> Senior QA Engineer -> Lead QA Engineer path is ignored. But I leave it to the conscience of the author.
It made me sad.
Then, when I studied the data better, it became clear that the majority of testers we recruited graduates a year or two ago are now interested in switching to developers, while testers with 3-5 years experience look to the managers.
So why do our testers with less than two years of experience want to go to the developers? Later it became obvious that the company is committed to frequent product releases; noticeable growth in test automation. We have always devoted a lot of time to automated testing, but now more than ever. The combination of a short preparation time and an emphasis on quick releases has resulted in our new testers doing mostly automated testing and stupid manual regression testing.
Perhaps the desire to change the field of activity is the result of a narrow view of the role of testing. When testers were asked about exploratory testing, some of them claimed that they made it every issue, but it was very boring and they just did the same thing again and again.
It was at that moment that I began to connect the dots. Probably the real problem was that even if they knew about the existence of other areas of testing, they do not understand what these areas really are. For example, in their eyes, exploratory testing == manual testing, so if their only opportunity to prove themselves as a tester was a regression testing run on predefined lists, it is not surprising that they wanted to leave the ship!
Therefore, perhaps the real problem is education. As a company, we have been working hard on more frequent releases over the past couple of years, and we encourage teams to adapt their working methods to more flexible conditions in order to be more effective. As a result, most of our team works at full capacity most of the time, which leaves no time for learning and development. There are of course some people who find time to learn something new, but we have to look in general - “time” is a barrier in this equation.
This was confirmed by many testers when they were asked if they had any progress in the learning process. Their frequent response was: "No, I have no time" or "There is no time during the day to do this."
As a direct result of this study, we are looking at how we can introduce time for preparation into projects. There are lessons that can be learned from Google removed 20% of the time and our own experience, so we are sure that we will be able to do something at home. Work on this continues.
But this alone will not solve the problem. How can you learn something if you don’t even know what it is - what you should learn. There is a certain thing in knowledge, within your role, but you do not know what it is. Maybe you consider yourself an experienced tester when, in fact, you simply are not aware of certain areas of your role. This may seem absurd, but imagine that you have had little contact with the company of testers, outside of your small team of testers or even the entire company. Then your idea of ​​your role will be significantly less, and cut off to the skills that you need daily. If we have taken the approach of software masters , then we have many students, very few apprentices, and even less masters. This means very few opportunities for mentoring.
This leads me to another significant difference between developers and testers, which I suspected for a long time, and which was confirmed by our data. The developer usually played computer as a child, learned computer better at school, continued to study in the field of information technology, and perhaps even received a degree at the university, all with the goal of becoming a developer. The desire to develop something is their passion and they, as a rule, are engaged in programming all their time (at least until marriage, children and the like).
Testers have no higher education in software testing, no testing classes at school, and I’m sure that no one had a burning desire for a child or teenager to become a software tester. It’s sad to know that a fair amount of testers (and me too) got this job before because they didn’t have enough knowledge or perseverance for developers. The skills needed for testing, such as curiosity, attention to detail, the ability to look at the big picture (as well as many others) are the features that I have always had, so that, fortunately, everything was all right.
However, I think that software testing is currently viewed as a bona fide career in its own right, and many companies now do not see this as an unfortunate development path.
But I want to say that without this burning desire to be a tester, a new tester has to learn from scratch all the skills that include the role of testing.
And this is the place where we made a mistake. In my company, developers and testers are treated on an equal footing, and indeed many skills are common. However, new testers may pay much more attention to explain the roles and skills they need.
In an attempt to open our testers' eyes and shed light on the skills that the role of testing covers, we have compiled a skills map. The card center is a set of basic skills in which each tester must have at least basic knowledge. After diverge from the center of the four quadrants. These quadrants define the directions that a person might take. He would still be a tester, but he could already determine what kind of tester he could take.
By explicitly viewing a set of basic skills, such as research testing, test methods, reporting problems, pair testing, test automation, intentional practice, providing feedback, etc., it becomes much easier for the tester to determine what he should focus on. It is very important that basic skills are learned, practiced and honed before thinking about specialized skills.
This scheme is used in personal development conversations between testers and their supervisor to help them find strengths and weaknesses and form a goal for further training.
We experienced it on several people, and we are still in the process of tuning and optimization. But this tool looks promising to help in career discussions.
It is hoped that some of the novice testers will look at the core skills section and identify several areas that they need to improve.
Of course, this is a long way and we do not claim that this scheme will answer all the questions, but this is only the beginning.
Back in June, I read with great interest the article by John Stevenson, which discusses career growth for testers. At that time (and still) the article touched me lively, because similar issues began to be raised in my current company.Translator's note: A small digression and a couple of words about that article. The article provides different statistics about testers - gender (75% of men, although, in my practice, I would say that the female gender prevails), the mode of development (coincides with this article) and the salary. I was very surprised by the latter, because if you believe it, testers on average get as many or more programmers and developers, which clearly differs from my experience (besides, the article focuses on less, although the numbers say the opposite) .
After some concerns about employee involvement, I (the head of the testers) and the rest of the heads of the functional part (software development, project management and technical development), engaged in conversations with all my people within our competencies. We have developed a set of questions aimed at obtaining a real picture: their current view of their careers and their role in the company.
')
Firstly, it was great, just going around and talking to everyone, and secondly, talking to all twenty testers gave me a pretty good idea of ​​where the problem areas lie.
John Stephenson writes in his article: “Yes, XXX was such an excellent tester, but he had to go to the developers to be able to develop in the company” and I heard this phrase in one form or another several times. In our case, this was a transition either to the developers or to the project managers. Both options were considered as the only real progress for the tester. // Translator's note: it is not entirely clear why the QA Engineer -> Senior QA Engineer -> Lead QA Engineer path is ignored. But I leave it to the conscience of the author.
It made me sad.
Then, when I studied the data better, it became clear that the majority of testers we recruited graduates a year or two ago are now interested in switching to developers, while testers with 3-5 years experience look to the managers.
So why do our testers with less than two years of experience want to go to the developers? Later it became obvious that the company is committed to frequent product releases; noticeable growth in test automation. We have always devoted a lot of time to automated testing, but now more than ever. The combination of a short preparation time and an emphasis on quick releases has resulted in our new testers doing mostly automated testing and stupid manual regression testing.
Manual testing == Research testing
Perhaps the desire to change the field of activity is the result of a narrow view of the role of testing. When testers were asked about exploratory testing, some of them claimed that they made it every issue, but it was very boring and they just did the same thing again and again.
It was at that moment that I began to connect the dots. Probably the real problem was that even if they knew about the existence of other areas of testing, they do not understand what these areas really are. For example, in their eyes, exploratory testing == manual testing, so if their only opportunity to prove themselves as a tester was a regression testing run on predefined lists, it is not surprising that they wanted to leave the ship!
Therefore, perhaps the real problem is education. As a company, we have been working hard on more frequent releases over the past couple of years, and we encourage teams to adapt their working methods to more flexible conditions in order to be more effective. As a result, most of our team works at full capacity most of the time, which leaves no time for learning and development. There are of course some people who find time to learn something new, but we have to look in general - “time” is a barrier in this equation.
This was confirmed by many testers when they were asked if they had any progress in the learning process. Their frequent response was: "No, I have no time" or "There is no time during the day to do this."
Knowing you don't know
As a direct result of this study, we are looking at how we can introduce time for preparation into projects. There are lessons that can be learned from Google removed 20% of the time and our own experience, so we are sure that we will be able to do something at home. Work on this continues.
But this alone will not solve the problem. How can you learn something if you don’t even know what it is - what you should learn. There is a certain thing in knowledge, within your role, but you do not know what it is. Maybe you consider yourself an experienced tester when, in fact, you simply are not aware of certain areas of your role. This may seem absurd, but imagine that you have had little contact with the company of testers, outside of your small team of testers or even the entire company. Then your idea of ​​your role will be significantly less, and cut off to the skills that you need daily. If we have taken the approach of software masters , then we have many students, very few apprentices, and even less masters. This means very few opportunities for mentoring.
This leads me to another significant difference between developers and testers, which I suspected for a long time, and which was confirmed by our data. The developer usually played computer as a child, learned computer better at school, continued to study in the field of information technology, and perhaps even received a degree at the university, all with the goal of becoming a developer. The desire to develop something is their passion and they, as a rule, are engaged in programming all their time (at least until marriage, children and the like).
Testers have no higher education in software testing, no testing classes at school, and I’m sure that no one had a burning desire for a child or teenager to become a software tester. It’s sad to know that a fair amount of testers (and me too) got this job before because they didn’t have enough knowledge or perseverance for developers. The skills needed for testing, such as curiosity, attention to detail, the ability to look at the big picture (as well as many others) are the features that I have always had, so that, fortunately, everything was all right.
However, I think that software testing is currently viewed as a bona fide career in its own right, and many companies now do not see this as an unfortunate development path.
But I want to say that without this burning desire to be a tester, a new tester has to learn from scratch all the skills that include the role of testing.
And this is the place where we made a mistake. In my company, developers and testers are treated on an equal footing, and indeed many skills are common. However, new testers may pay much more attention to explain the roles and skills they need.
Skill map
In an attempt to open our testers' eyes and shed light on the skills that the role of testing covers, we have compiled a skills map. The card center is a set of basic skills in which each tester must have at least basic knowledge. After diverge from the center of the four quadrants. These quadrants define the directions that a person might take. He would still be a tester, but he could already determine what kind of tester he could take.
By explicitly viewing a set of basic skills, such as research testing, test methods, reporting problems, pair testing, test automation, intentional practice, providing feedback, etc., it becomes much easier for the tester to determine what he should focus on. It is very important that basic skills are learned, practiced and honed before thinking about specialized skills.
This scheme is used in personal development conversations between testers and their supervisor to help them find strengths and weaknesses and form a goal for further training.
We experienced it on several people, and we are still in the process of tuning and optimization. But this tool looks promising to help in career discussions.
It is hoped that some of the novice testers will look at the core skills section and identify several areas that they need to improve.
Of course, this is a long way and we do not claim that this scheme will answer all the questions, but this is only the beginning.
Source: https://habr.com/ru/post/202868/
All Articles