All professions are important: why should a tester be valued as much as a programmer?

Hello. My name is Ilya Kudinov, I am 27 years old and I am a tester.
All: Hello, Ilya!

We have already written a lot about how great we at Badoo are testing our products. And today I (suddenly!) Will talk about how cool to test AT ALL. And when I meet representatives of our profession who do not share this view, I always try to open their eyes to the truth. For example, this very article.

What will it be about? I will share my personal experience, tell you how the industry has evolved over the course of over six years, what I have been observing, and describe my vision of the career path of the tester. Sit back, the time has come ( unintelligible, crossed out ) entertaining stories ...
')

Disclaimer

Everything that I will write in this article is based on my personal perception, experience and information that I gathered at QA conferences and meetings. The article will be interesting for beginners and those who dream of working in IT, but have not yet decided on a profession. And mainly to those who believe that testing is not serious, boring and routine work.

If you disagree with me on something, welcome to the comments. I am always open to dialogue.

About me

My story as a tester began in 2011. By this time, I had already successfully left my studies at the Bauman Moscow State Technical University, I was in the army and worked as a courier technical specialist. After all these adventures, I was looking for a job as a programmer, because something in this area was able and I liked it. But due to the lack of higher education and, to put it mildly, a small formal work experience, a line of joyful employers did not line up behind me ( at least, this was the reason for my refusals ). Therefore, when I was offered “And let's work with us as a website tester, and if everything goes well, we will transfer you to programmers,” I gladly agreed. Spoiler: everything was fine, but I was never made a programmer.

It all started very boring and mundane. I was the only tester for seven programmers. The developers wrote the code on local machines, dropped it on the test server, asked me to test it there, and then manually poured the code on the production ( I naively thought that everyone was doing it ). Something was poured on the prod without my knowledge ( “I forgot to say, I'm sorry!” ), Something was done right on the prod at the request of the management. In general, quiet horror.

A few weeks later I learned about the existence of version control systems. World turned upside down. Several people can work on the same code, and it will be COMFORTABLE! I buzzed all the ears to my boss and got SVN installed. Just a month after that, we started working in branches (!), Uploading changes to production with organized tested packs (!!), and even got some sort of release schedule (!!!). When I looked at it all, I started to get the feeling that development and testing is not a chaotic process, all of this can have some kind of organization. Read the Internet? What are you, I was young and hot, I was not up to it.

So, besides the tester, I also became a release engineer. The work has become more interesting and less clumsy. Due to the reduction in the level of chaos, I had more free time, and I began to wonder what kind of animal it was - “Automated testing”. I found information on the Internet about Selenium WebDriver just released, and my eyes went back to my forehead: can I force the program to PUSH BUTTONS ON THE SITE FOR YOU ??? Imagination painted an idyllic reality in which a person does not need to engage in regression testing ( no, I did not know this term at that moment ). And I immediately began to spend all my free time developing test cases. To be honest, they were written terribly, but they performed their function.

By the time I worked at the company for nine months. And I still received my initial salary of a manual tester ( believe me, she was not very impressive ). Insanely proud of my boss led me to the leadership - to beat promotion. I talked about the transition to the release system and my responsibilities in this area, showed my autotests, talked about how they reduce the time for routine work. And he showed that the number of errors falling on production over the past six months has fallen dramatically. I almost did not want to be a programmer!

But a representative of the management, with a bored look, looking at the fields I cultivated, said: "Yes, everything seemed to be fine without all this tinsel, it was in vain that time was wasting."

I did not expect such a blow. No figures were convinced by the management, for him the tester was a monkey clicking on the buttons and for a small fee reducing ( sometimes ) the number of fatals on the production. Nobody was going to consider anything more. You may consider this an overreaction, but I wrote the application for dismissal that evening.

I started looking for work again. Having lost faith in testing, I again began to look towards programming. I even managed to get an offer for the position of a junior C-developer in a brokerage firm ... And then they called me from Badoo.

I first heard about Badoo just a few months before - at the Alexey Rybak master class at DevConf 2012. The company then instantly stood up for me on a par with Google and Facebook. It seemed to me that Badoo is something incredibly cool, where I, a mere mortal, will never go. Therefore, I agreed to the interview solely for the sake of experience. I didn’t count on anything - I simply poured out to Ilya Ageev my whole frustration about what I wanted to achieve and what I was deprived of. A few days later I became a part of this company, which, by the way, with all my heart I still love to this day.

“And what about your desire to be a programmer?” - you ask. He is OK. In Badoo, I develop test automation and workflow optimization systems. And in my spare time I slowly develop computer games. This is my hobby, a thing for the soul. No, I don’t feel like going to work as a programmer.

About industry

In the first days of work at Badoo, I experienced a culture shock. And it's not about skating around the office on scooters and screaming developers. Well, not only in them. And also in the fact that they tried to organize, optimize and automate every step. I thought: “So this is how it should be!” - and with all my strength I tried to comply: I participated in the development of processes and means of testing, I tirelessly searched for places where something could be improved.

And then I started to go and talk about our decisions at conferences. I was afraid that for everyone everything will be obvious - after all, everyone around is testing as cool as we are in Badoo! But in fact ...

An impressive part of Russian companies, and especially the IT departments of large non-IT companies, saw the testing process in much the same way as my previous employers. Questions after reports put me at a standstill.
“How do you force developers to write tests?”
“How is it, can you postpone the release of features? Is that enough to find a bug? ”
“You write the autotest yourself? If you can program, why are you not a programmer? ”

The problem was primarily in the perception of the profession of testers in our country. I am ashamed to say that at that time I didn’t even like the word “tester” - I thought that it brings me closer to that image of a low-skilled employee that conservative businessmen imagine. I preferred the pretentious "QA-engineer".

Year after year, my colleagues and I tried to convey the same thought: a tester is not a wannabe programmer, a tester is a full-fledged specialty. It is not easier programming. It is not more difficult. It's just a completely different thing. It requires other skills. It requires high qualifications. And an experienced tester is no less valuable (and rare) shot than an experienced developer. The path of the tester does not end with the thoughtless clicking of buttons and following the instructions — it is just beginning with him.

And, fortunately, every year more and more people understood this. I prefer to find in this my modest contribution. Began to appear more and more vacancies for professional testers and automation, more and more tough specialists, the opinion of which listens to the entire domestic (and at the same time foreign) industry. And it is beautiful. I feel that domestic testing as a whole is going about the same way as I did in my early years.

About the path of the tester

Career tester - the history of the development of technical, personal and many other skills. As in any other profession, yes. Just want to say: I do not consider the movement from a manual tester to an automator through development. Automation skills are important and useful for any tester, but these are only variations of the position, not a direct evolution. So let's get started.

• Level 0. Not a tester. At this level is any user of the software. It would seem that if this is not a tester, then why did I add it here? And then, that all these people can do some of the work of the tester. They can find bugs. Not on purpose, they did not try, it just happened. It was such a person, in fact, that they expected to see in the post of tester at my first place of work. And any specialist starts with this. Here are just some bugs cause irritation and anger at the developers, and some - the righteous anger and the desire to make sure that in our world there are no more bugs. From the last and beginner testers are born.
  
• Level 1. Almost tester. A person who has been entrusted with the work of a tester and who is trying to do it. Do not just use the application, but persistently uses it. Sometimes it even presses the same button several times. He still does not possess any skills, there is no system in his actions - there is only a desire to find a bug. Either not to be fired from work, or out of innate hatred of imperfections - you can't tell right away.
  
• Level 2. Tester. Understands what he does. Maybe I read a couple of books about the basics of testing. Taking on each new task, it can build a plan of its actions (or read the documentation and follow it). The goal is gradually shifting from “finding some kind of bug” to “controlling the quality of the product”. At about this level I was on my best days at a previous job.
  
• Level 3. Advanced tester. Really understands what he is doing. He knows the project perfectly well and can analyze the effect of certain changes on him. It can assess how much the tested functionality corresponds to the rest of the project, not only in terms of quality, but also in terms of UX and other important things. It can not only find bugs, but also prevent errors in the planning and design of a particular functionality.
• Level 4. Initiative tester. He does not just work in an organized environment and processes - he tries to improve them. The goal of "quality control" is transformed into "quality assurance". Development and development of optimization and automation tools, endless ideas about improving the workflow - all this beauty begins somewhere here.
  
• Level 5. Professional tester. Shamelessly and shamelessly dispose of myself at this level. Understanding the technologies used in the project allows you to make decisions and develop a test plan, not only by describing the problem, but also by solving it. Sometimes, for the detection of errors, reading the code and the list of changes is more than enough. The tester begins to see the communications linking the project, which he had never suspected before.
  
• Level 6. Guru tester. As you can see, the qualifications of the previous levels are strongly tied to the project. Moving to another company, and even more so to another technology stack, an ordinary tester loses some of his professionalism. It will have to recover. The guru testers look at things from a higher point. They can quickly deal with any system, find both explicit and hidden connections between components due to their experience and understanding of the work of IT systems (and IT specialists). Magical people. Here I would like that.
  

But wait, it's all about self-testing! Does the tester not have the opportunity at the expense of its development to become a leader? Of course it does. But this requires a whole range of other qualities and skills that he may not have. Not every good tester can be a good test manager. However, I firmly believe that every good test manager must be a good tester.

About the skills of a good tester

“Probably, it is enough to read a dozen well-known books from famous testers!” Nah, I never agree at all.

Professional literature can help you quickly learn the lessons that testers receive in the first months of their careers. But without real testing experience, book knowledge is virtually useless. The real world is very different from the ideal, which is described in most books.

But those are the defining qualities that I see:

• Love to test. Yes, for testing in general. There is no need to consider testing as a side occupation in IT, do not dream of escaping to a development or management - you should first of all enjoy work. “This generally applies to any specialty, thank you, cap!” - you will say and you will be right. However, this does not make this item less significant.
• Love for the project. You will not be happy for the quality of the project, which you do not care. Even if you do your job regularly ( you need to earn money somehow ), you will close your eyes to the flaws seen outside your component ( “Not my business, and indeed the problem is on your side” ). You will not suggest improvements and take the initiative ( “If you water the d ** but cologne, it will smell like g ** but under the cologne!” ).
• Knowledge of the project. Very beautiful button! Just as it is written in TK! And she does everything that is required of her, a great button! It is a pity that it looks not at all like all the other buttons on the site, breaks six critical features and calls Satan in the user profile. But how was I to know about it ?!
• Understanding of technology project. No, you do not need to be able to rewrite the entire project yourself from scratch, only better. But at least in general terms, to understand how HOW that what you are testing works is simply necessary. This allows you to find non-obvious bugs, make code substitutions for playing back various cases and see additional dependencies within the project.
• Maintaining a balance between quality and speed. Quality is not absolute. Each unit of time that the tester spends behind a task theoretically approximates its quality to the asymptote at 100%. At what point do you need to stop? It all depends on the project. If airplanes with hundreds of passengers fly on your software, you shouldn’t regret testing for another hour or two. And if you are developing a project with several releases a week and the ability to deliver patches to users in seconds, you can stop earlier. No, I do not encourage the release of production bugs - just the speed of the project is sometimes more important. You can read this quality as "The ability to navigate the priorities of the business . "

At the same time, I see the following attributes that are often attributed to quality testers:

• Perfectionism. Hating bugs and inconsistencies is good. To dwell on it is bad. The speed of testing will suffer, and the manager’s demands to release the untested functionality will be depressing. Aircraft software testers, don't listen to me, be perfectionists! You are welcome.
• Love for bureaucracy. Ah, test documentation. So much has already been said and written about it, I myself will sooner or later get to this topic. Now I will confine myself to saying that effective testing happens even without detailed comprehensive test documentation, subject to the availability of sensible technical documentation. Honestly!
• The joy of finding a bug. No, praising yourself for the clever case that broke the system is normal. Love yourself too. But this is not an end in itself - no need to hope for a mistake in every task that you find, no need to sneer at the developers who missed the bug, and feel superior when you find an inaccuracy in the component that your colleague has already tested. It is much better to rejoice in the fact that the task left for production without errors and on time. This is your real achievement, even if you have never rediscovered the task.

In conclusion…

I love my job. This includes everything — my own responsibilities, my project, and my dearest colleagues. I know a lot of testers who have the same feelings. But I know many others who are unhappy in their position, whether through their own fault or the fault of their leaders - it does not matter. And I also know people who want to work in IT, but do not want to go to testing, because they consider this work unworthy and uninteresting. If at least one of these people through my article can become happier and more successful in their own eyes, I wrote all this for good reason.