There is no way back: personal tester experience
I want to talk about the work of a tester from an atypical perspective, which is unlikely to be shown in educational institutions or professional literature. Becoming a professional in this field, you inevitably begin to live with concepts embedded in the very foundation of testing. And it is very differently reflected in the arrangement of life. How exactly it occurs at me, under a cat.
I have been testing in one form or another for more than 10 years.
The path to IT, like many others, I began with developing "for myself." I always had a million ideas to write, and in this way I gradually developed. I liked to understand the details of the projects and make them fault-tolerant, and even then it was more or less all the same what language to write: I could algorithmize, and google the syntax was the question of the week.
Somewhere in 2005, I met a man who literally opened the testing industry for me. Already then, it seemed to me that its ideology fully corresponded to my inner aspirations. The man eventually went from an ordinary tester to a technical director, and even then he called me to work for him. But for various reasons, I got into this industry only a year later, after joining Smartbear (Automated QA Corporation at the time), whose test-testing tool TestComplete is known, perhaps, to all testers. True, I got not on TestComplete itself, but on another product, Automated Build Studio - as a matter of fact, immediately into automation. By the way, I literally fell in love with his GUI-approach to automation, even wrote an analog for myself when I left the company.
Subsequently, I managed to work on both foreign customers and Russian ones. And at the moment I am automating testing in a Russian completely remote company (I’ll still dwell on the work format).
During the time spent in the profession, I realized that testing is not just a job, but also a peculiar lifestyle that affects all aspects of your life. As a tester, you just can not live otherwise.
This approach has both positive and negative sides.
')
The search for complex tasks is not only an addiction, but also an inevitability.
No matter how much you study, in any instrument, in any technology there is always one who knows more than you. And if you conditionally “go on track” of a simple project, you will be constantly reminded of this difference of knowledge. There will be criticism from all sides, which could have been done differently or even better.
The only way to avoid this is to search for more complex tasks, where there are no obvious solutions, but there are sleepless nights in search of problems.
For example, on one of the latest projects I was faced with developing libraries for the Robot Framework in conjunction with Jython. Specifically, in that case it was possible to use a third-party library to work with the database, and it seemed to be working, but not working. I spent three nights so that, as a result, while reading the code of the library itself, I would find an error in the documentation that incorrectly indicated the types and number of input values. It was a victory and a real buzz from her achievement! And I like these moments. It is much more interesting than the “track” of a typical project.
However, the pursuit of complex tasks somewhat limits the range of possible employers. It is further limited by wild testing of the frontend, by employers without a distinct TK for testing or having some vague idea of ​​who the automator is. I met those who, by inviting them to autotest, set manual tasks or connect testers to support. There are still quite a few who save on the purchase of normal tools, offering to work almost in Google Docs. And we must be prepared for the fact that the market of potentially interesting employers is already what you think.
At the current place of work, my technical duties include a technical interview of testers who come to work for us. During the conversation, I never ask a question about the availability of higher education, because I am sure: it absolutely does not guarantee the presence of logical thinking. Maybe my interlocutor has a doctorate, but not a foot in the tooth in testing.
Frankly, I generally think that a tester needs to be born. This requires natural attentiveness, perseverance and some special tester streak, when you can randomly get into one of three erroneous documents out of 1000 documents. True, not everyone shares this opinion.
The important thing is that even with this vein, you need a good technical base, which you can hardly get by completing two-week online courses. It is difficult to say what provided the technical basis in my case. In the 90s I did not have access to the Internet, the same literature did not exist in libraries, so I learned from FIDO (I still remember my points - 2: 5022 / 5.102 and 2: 5022 / 123.222). And it is the testing base that I owe to the International Software Testing Qualifications Board (ISTQB) certification. It seems that nothing is better yet.
However, quite rarely I meet knowledge on ISTQB from candidates for vacancies. Moreover, sometimes it seems to me that people are not interested in the industry at all. At the interviews I have a question about the conference: does the candidate attend any QA events? And the traditional answer is negative. For me, this is an indicator of the seriousness and interest of the candidate himself, and at the same time the companies for which he worked. Participation in events like SQA Days, where I will go in the near future, costs money. And any "Sharashkin office" will not spend them on their employees. From his own pocket only the one who is really interested will pay.
Each project in testing forced me to learn new technologies. Above, I talked about my “heroic battle” with Jython, but after coming to that project, I did not know either the Robot Framework or, in fact, Jython itself (not even Python, which has a lot of things for the Robot Framework). Now, perhaps, I understand the robot best of all in the company, because the testing base prompted the approach, and the experience of developing in different languages ​​and testing previous projects made it possible to quickly switch to a new stack.
In addition, experience allows you to properly distribute the effort. I noticed that newbies pay a lot of attention to negative testing - how to break something. Apparently, they have stereotypes about the profession. In most cases, their negative testing is unimportant and unnecessary (that is, waste of resources is unjustified, unless the project implies the need for such testing). Only with experience comes an understanding of what is needed and what is not, with such a formulation of the problem.
By the way, I have a whole list of questions at the interviews whose task is to reveal the practical experience of the candidates.
Alas, the world is imperfect.
In development, this is expressed in the fact that there is a demand for testers. If the developers wrote great code, we would be left without work. With us, the gibbering does not disappear anywhere, but we cover it with tests.
Testers themselves, by the way, are also not sinless. Whichever project you get, sometimes you also have to write crutches. And nothing can be done about it - these are sometimes the conditions of a business.
Developers with a fine mental organization that I have encountered in past work have sometimes found it very hard to deal with bugs in their code, information about which appeared in the system. From their point of view, this is apparently something like a public announcement of their mistakes. And the more actively you report bugs, the more your colleagues hate you. As a result, in the office, of course, you have a certain number of good acquaintances, but about a third of the team starts to avoid you, and you feel it. For me, this is extremely unpleasant.
This is a natural consequence of the previous remark. When you made yourself in the office quite “detractors” with a fine mental organization, it becomes not very pleasant to walk around such a room. Therefore, for myself, I have already made a choice in favor of the remote. In this format, unprofessional relationships fade away — no sidelong glances. Perhaps, of course, I just do not come across such characters now. But there are few chances for such a collision. We, for example, call up via video link only within the QA-department. With developers, on which I can hang a bug, I communicate only in the text, without any emotions. And even if these emotions are, it’s much easier to experience them in the text than when a person passes by several times a day.
And I can eat normal homemade food, equip a workplace as I want. I can sit in the heat in one T-shirt (remembering video calls) or even change my working hours so that in the middle of the day I go to the field and watch the fall begin or nature wakes up from hibernation. And the most important advantage of the remote is time saving. I live near the regional center. We only have IT there. And if I work in an office in the center, then I’ll have to get to the workplace for an hour one way, and on Fridays everything is one and a half. And this is the time that you just lose: it is not paid, it is not wasted. Plus the risk of getting into an accident and consumables on the car. With remote these costs and risks simply do not arise.
It seems to me that, by my own will, I will not go to work in the office. The only thing I sometimes lack is personal contact. But in general, this question is solved.
Unfortunately or fortunately, testing is a lifestyle. I can not speak for everyone, but this is how it happens for me.
Testing begins with project requirements. Actually, his task is to make sure that the product meets these requirements. Looking for days and fixing problems in someone else's software, you start doing something similar in your life. I always live with the feeling that everything must meet the requirements. To be a tester is to live by the rules. And if someone or something goes beyond the scope of these rules (laws or their own norms formulated in the head), this causes some cognitive dissonance in me. I urgently try to fix the bug or at least declare it. At the same time, surrounding people very often suffer from the fact that you constantly tell them about the wrong actions.
By the way, all this does not contribute to the elimination of the very lack of personal communication.
Above I talked mostly about projects and relationships with the team. But work, even remote, consists not only of these moments. And here a lot depends on the project that you got into.
First, there is a banal material support. For example, a comfortable chair in which I am sitting now, as well as a 24-inch monitor, were purchased at the expense of the employer. Plus all sorts of sports and other bonuses.
Secondly, there is a banal self-realization. For example, in one of the projects in which I participated (testing the customer’s project by outsourcing), I was the only one of the outsourcers of this company who were invited to interview employees for this project in the office and were invited to corporate events. Is it real in a company for which testers are faceless cogs of a mechanism? I doubt it.
One way or another, I like my job. And when I manage to solve complex problems in an interesting project, I feel real satisfaction. However, developing in this field, you should be prepared for the fact that approaches to work will affect all aspects of life. And if you turn into a tester once with all the cockroaches, there will be no way back.
The author of the article: Vladimir Vasyaev, Leading Specialist in Automated Software Testing
PS We publish our articles on several sites Runet. Subscribe to our pages on the VK , FB or Telegram channel to learn about all of our publications and other news from Maxilect.
A little bit about yourself
I have been testing in one form or another for more than 10 years.
The path to IT, like many others, I began with developing "for myself." I always had a million ideas to write, and in this way I gradually developed. I liked to understand the details of the projects and make them fault-tolerant, and even then it was more or less all the same what language to write: I could algorithmize, and google the syntax was the question of the week.
Somewhere in 2005, I met a man who literally opened the testing industry for me. Already then, it seemed to me that its ideology fully corresponded to my inner aspirations. The man eventually went from an ordinary tester to a technical director, and even then he called me to work for him. But for various reasons, I got into this industry only a year later, after joining Smartbear (Automated QA Corporation at the time), whose test-testing tool TestComplete is known, perhaps, to all testers. True, I got not on TestComplete itself, but on another product, Automated Build Studio - as a matter of fact, immediately into automation. By the way, I literally fell in love with his GUI-approach to automation, even wrote an analog for myself when I left the company.
Subsequently, I managed to work on both foreign customers and Russian ones. And at the moment I am automating testing in a Russian completely remote company (I’ll still dwell on the work format).
During the time spent in the profession, I realized that testing is not just a job, but also a peculiar lifestyle that affects all aspects of your life. As a tester, you just can not live otherwise.
This approach has both positive and negative sides.
')
The simpler the task, the worse you feel.
The search for complex tasks is not only an addiction, but also an inevitability.
No matter how much you study, in any instrument, in any technology there is always one who knows more than you. And if you conditionally “go on track” of a simple project, you will be constantly reminded of this difference of knowledge. There will be criticism from all sides, which could have been done differently or even better.
The only way to avoid this is to search for more complex tasks, where there are no obvious solutions, but there are sleepless nights in search of problems.
For example, on one of the latest projects I was faced with developing libraries for the Robot Framework in conjunction with Jython. Specifically, in that case it was possible to use a third-party library to work with the database, and it seemed to be working, but not working. I spent three nights so that, as a result, while reading the code of the library itself, I would find an error in the documentation that incorrectly indicated the types and number of input values. It was a victory and a real buzz from her achievement! And I like these moments. It is much more interesting than the “track” of a typical project.
However, the pursuit of complex tasks somewhat limits the range of possible employers. It is further limited by wild testing of the frontend, by employers without a distinct TK for testing or having some vague idea of ​​who the automator is. I met those who, by inviting them to autotest, set manual tasks or connect testers to support. There are still quite a few who save on the purchase of normal tools, offering to work almost in Google Docs. And we must be prepared for the fact that the market of potentially interesting employers is already what you think.
Higher education is not the same as employment. Important technical base and interest in the profession
At the current place of work, my technical duties include a technical interview of testers who come to work for us. During the conversation, I never ask a question about the availability of higher education, because I am sure: it absolutely does not guarantee the presence of logical thinking. Maybe my interlocutor has a doctorate, but not a foot in the tooth in testing.
Frankly, I generally think that a tester needs to be born. This requires natural attentiveness, perseverance and some special tester streak, when you can randomly get into one of three erroneous documents out of 1000 documents. True, not everyone shares this opinion.
The important thing is that even with this vein, you need a good technical base, which you can hardly get by completing two-week online courses. It is difficult to say what provided the technical basis in my case. In the 90s I did not have access to the Internet, the same literature did not exist in libraries, so I learned from FIDO (I still remember my points - 2: 5022 / 5.102 and 2: 5022 / 123.222). And it is the testing base that I owe to the International Software Testing Qualifications Board (ISTQB) certification. It seems that nothing is better yet.
However, quite rarely I meet knowledge on ISTQB from candidates for vacancies. Moreover, sometimes it seems to me that people are not interested in the industry at all. At the interviews I have a question about the conference: does the candidate attend any QA events? And the traditional answer is negative. For me, this is an indicator of the seriousness and interest of the candidate himself, and at the same time the companies for which he worked. Participation in events like SQA Days, where I will go in the near future, costs money. And any "Sharashkin office" will not spend them on their employees. From his own pocket only the one who is really interested will pay.
No experience anywhere
Each project in testing forced me to learn new technologies. Above, I talked about my “heroic battle” with Jython, but after coming to that project, I did not know either the Robot Framework or, in fact, Jython itself (not even Python, which has a lot of things for the Robot Framework). Now, perhaps, I understand the robot best of all in the company, because the testing base prompted the approach, and the experience of developing in different languages ​​and testing previous projects made it possible to quickly switch to a new stack.
In addition, experience allows you to properly distribute the effort. I noticed that newbies pay a lot of attention to negative testing - how to break something. Apparently, they have stereotypes about the profession. In most cases, their negative testing is unimportant and unnecessary (that is, waste of resources is unjustified, unless the project implies the need for such testing). Only with experience comes an understanding of what is needed and what is not, with such a formulation of the problem.
By the way, I have a whole list of questions at the interviews whose task is to reveal the practical experience of the candidates.
All people are stupid. It causes pain, but gives work
Alas, the world is imperfect.
In development, this is expressed in the fact that there is a demand for testers. If the developers wrote great code, we would be left without work. With us, the gibbering does not disappear anywhere, but we cover it with tests.
Testers themselves, by the way, are also not sinless. Whichever project you get, sometimes you also have to write crutches. And nothing can be done about it - these are sometimes the conditions of a business.
The better you are as a tester, the more you hate
Developers with a fine mental organization that I have encountered in past work have sometimes found it very hard to deal with bugs in their code, information about which appeared in the system. From their point of view, this is apparently something like a public announcement of their mistakes. And the more actively you report bugs, the more your colleagues hate you. As a result, in the office, of course, you have a certain number of good acquaintances, but about a third of the team starts to avoid you, and you feel it. For me, this is extremely unpleasant.
It’s easier to be a tester
This is a natural consequence of the previous remark. When you made yourself in the office quite “detractors” with a fine mental organization, it becomes not very pleasant to walk around such a room. Therefore, for myself, I have already made a choice in favor of the remote. In this format, unprofessional relationships fade away — no sidelong glances. Perhaps, of course, I just do not come across such characters now. But there are few chances for such a collision. We, for example, call up via video link only within the QA-department. With developers, on which I can hang a bug, I communicate only in the text, without any emotions. And even if these emotions are, it’s much easier to experience them in the text than when a person passes by several times a day.
And I can eat normal homemade food, equip a workplace as I want. I can sit in the heat in one T-shirt (remembering video calls) or even change my working hours so that in the middle of the day I go to the field and watch the fall begin or nature wakes up from hibernation. And the most important advantage of the remote is time saving. I live near the regional center. We only have IT there. And if I work in an office in the center, then I’ll have to get to the workplace for an hour one way, and on Fridays everything is one and a half. And this is the time that you just lose: it is not paid, it is not wasted. Plus the risk of getting into an accident and consumables on the car. With remote these costs and risks simply do not arise.
It seems to me that, by my own will, I will not go to work in the office. The only thing I sometimes lack is personal contact. But in general, this question is solved.
Professional deformation affects relationships with friends
Unfortunately or fortunately, testing is a lifestyle. I can not speak for everyone, but this is how it happens for me.
Testing begins with project requirements. Actually, his task is to make sure that the product meets these requirements. Looking for days and fixing problems in someone else's software, you start doing something similar in your life. I always live with the feeling that everything must meet the requirements. To be a tester is to live by the rules. And if someone or something goes beyond the scope of these rules (laws or their own norms formulated in the head), this causes some cognitive dissonance in me. I urgently try to fix the bug or at least declare it. At the same time, surrounding people very often suffer from the fact that you constantly tell them about the wrong actions.
By the way, all this does not contribute to the elimination of the very lack of personal communication.
Overall workflow comfort means more than it seems at first glance.
Above I talked mostly about projects and relationships with the team. But work, even remote, consists not only of these moments. And here a lot depends on the project that you got into.
First, there is a banal material support. For example, a comfortable chair in which I am sitting now, as well as a 24-inch monitor, were purchased at the expense of the employer. Plus all sorts of sports and other bonuses.
Secondly, there is a banal self-realization. For example, in one of the projects in which I participated (testing the customer’s project by outsourcing), I was the only one of the outsourcers of this company who were invited to interview employees for this project in the office and were invited to corporate events. Is it real in a company for which testers are faceless cogs of a mechanism? I doubt it.
One way or another, I like my job. And when I manage to solve complex problems in an interesting project, I feel real satisfaction. However, developing in this field, you should be prepared for the fact that approaches to work will affect all aspects of life. And if you turn into a tester once with all the cockroaches, there will be no way back.
The author of the article: Vladimir Vasyaev, Leading Specialist in Automated Software Testing
PS We publish our articles on several sites Runet. Subscribe to our pages on the VK , FB or Telegram channel to learn about all of our publications and other news from Maxilect.
Source: https://habr.com/ru/post/428876/
All Articles