When a young specialist fails something, he is engaged in self-digging and begins to think that he will fail at all. Since it is often common for people to see the root of evil in their surroundings - circumstances / superiors / colleagues - there is no time left to search for the causes. But, as it seems to me, both approaches are not completely correct.

At the beginning of a career, we tend to take on our own account all the failures in work, which ultimately will lead to demotivation and self-digging. Something similar happened to me in due time. Perhaps it was happening to you - or even happening now.

Therefore, I will simply tell my story of the change of specialty - I hope that it will serve someone with the missing impetus for action.

And who am I anyway?

Now I work as a tester in Yandex.Money. I am 23 years old, and by specialty I am “Computer Science-Economist” (and this is not “Computer Science” minus “Economist”).

She began to work from the first courses of the university, although it was rather a side job: a math tutor, an operator in the booking department of the ferry company. And before the last course of the university, she was hired by the Service Desk engineer at a large Japanese tourism corporation.

It was not the usual “first line of support,” which in general cases registers requests and sends them to responsible engineers. We administered an internal workflow system, set up workstations, a security system, understood network problems, requests related to office products, VPN, etc.

In general, such specialists are called “Shivs” among the people.

How to get to helpdesk after illusory university practice

While studying at the university, I tried my best to get new experience in order to find a decent job after graduation: I participated in scientific conferences (this quickly disappointed, because there is little science at such conferences, mostly retellings of existing works), I wrote scientific articles, freelancing , held a mandatory annual practice. In general, the classic "learn perfectly well - and you will have everything."

With practice in general is always an interesting story. When you enter a university, volunteers in the admissions committee tell about large companies with which the educational institution cooperates, about providing jobs. You are waiting for the summer in order to quickly begin to apply all your knowledge in practice, to get acquainted with real workflows and tasks, albeit simple ones. But in fact there are very few places to practice, and the university offers to work in the department in the summer, and even then not everyone, so you have to look for everything yourself.

I worked for one summer and had practice in the booking department of the ferry company. There has just completed the introduction of a new IP, which at that time was unstable. It was surprising that everyone was satisfied with the fact that the system crashes several times a day, and when you try to save something, errors get out, because the work became more complicated. I tried to describe the conditions under which I had errors, and referred it to the IT department. At that moment, it never occurred to me that testers are doing this.

A year later, I went to practice at the bank. Then it seemed to me something incredible, because the selection was serious. Several interviews, tests, many candidates. Before starting work, bank employees (recruiters, future managers, information security specialists) asked for a detailed plan and practice goals. I remember how then I told them something about “the description of key business processes in fashionable notations, the description of IT architecture, as recommended by TOGAF”.

On the first day of the practice, we (the trainees) put us in the head's office with scissors for outdated advertising booklets. We managed. In the following days we were given a more responsible job ... Alphabetically distribute the legal affairs of clients. The task is, of course, difficult, long, but I scored the names of all the clients in Excel, sorted it (application technology is the same), and then I just put the stacks of folders on the list.

Nobody expected that we could do it so quickly, so we had to invent some other task. In the end, I was put to work in the BIS (banking information system), I had experience in interacting with such systems at the university, it was interesting. A new analysis module was introduced in the bank, and I found errors that were then left as wishes for development.

Then I still did not know anything about testing in general and the existence of such a specialty in particular, but I was already engaged in all of this.

What happens if you do "as it is more logical"

The last course of the university was approaching, there was a lot of time and little experience, so I went to work as a Service Desk engineer.

In the first months of work, I immediately noticed that not everything went smoothly in the company's IT infrastructure. For example, because of the specifics of working at an international company, all engineers had a different schedule (to maintain offices in China or America, someone worked at night, and the next day after the night shift, he rested and was unavailable). IT staff were scattered around the world (operation - in St. Petersburg, IT director - in Copenhagen, development - in India and many more local sappers in all offices). For these reasons, it was sometimes difficult to find a quick solution or responsible for performing some tasks.

I took on several projects to improve and optimize processes, so I had to talk a lot with all the staff and managers, collect their wishes, write documentation and solve problems that arise. I also had occasion to draw interfaces, draw up clear and understandable TK for developers. Sometimes it was all very time consuming, so I began to write the code myself in order to quickly implement some kind of my own idea.

In addition to such tasks, I often did uploads and analysis of incidents. I wanted to understand where in operation the bottleneck, what knowledge is not enough, what kind of specialists. It so happens that everyone in the IT department is used to “extinguish fires” instead of preventing them. Along the way, I told colleagues about ITIL and ITSM, everyone liked very much in words, but few supported the changes.

So it took a little over a year, because of the work on the enthusiasm of the tasks, more and more flew in, there was no time left for my mini-projects. Due to incorrectly aligned processes, the number of tasks did not decrease at all. There was a sense of turbulent, but useless activity.

At this time, major security incidents occurred in the company, and personal customer data leaked to the network. The Japanese are very strict with this, the company received a warning from the government, and the next such incident could lead to the closure of the company. I became an engineer in the information security group, and the company had to implement different information security systems.

It so happened that the new profile specialists decided not to hire and the load on the new tasks lay on the available staff. And in order to make it even more interesting, there was also no clear idea of ​​specific expectations and tasks. I didn’t have enough experience to stop at something and get down to business: here you read the description of the system, specify the details of the vendors, but in fact you get two absolutely identical solutions that differ in name and price. And, of course, subtle technical features of the implementation, which are understandable to the very lack of specialized specialists.

Long trampling on the spot, lack of results, led to the idea that IT is not mine. Totally.

Sometimes you just need to take and throw

Most of my friends are also from IT, system administrators, developers, IT consulting specialists. Communicating with friends, I realized that in other areas everything is arranged quite differently than in operation.

Development projects almost always derive from the strategic goals of a company or a company's mission to users. They are tied to marketing, in contrast to the operation, the development can not have time to implement in time what has already been announced to the press. In addition, development is an expensive pleasure, and therefore more attention is paid to it. In general, I wanted to "team A".

It seemed impossible to become a developer in a short time, although I wrote code in different languages, but mostly to solve applied problems — without using frameworks and conventions. I wanted to leave work faster, and all the courses “Become Java Junior Developer for 9 hours” didn’t inspire confidence. The developer must know the algorithms, frameworks, patterns, features of languages. If you are a developer in the Agile team, you often act as a system architect, and for this you need experience.

My friend advised me to go in testing, and I decided to try. I read a couple of books on testing, I looked at well-known QA engineers, as well as Yandex.Money and Mail.ru courses. I was impressed by two completely different approaches: some teach you administration, technical features of what you have to work with, the basic language of IT, others teach general concepts, analysis, test design, planning, coverage, optimization.

It was all in words, but I wanted more practice testing web services. Therefore, for preparation, I decided to write my small web application in Java (thanks to the StackOverFlow resource), with several “handles” and a database, and then test this application according to the “rules”. This experience helped me to learn more about the features of the architecture of web services and infrastructure, as well as about working tools. I use this knowledge every day when testing or preparing test environments.

Now I am a tester

About seven months have already passed, as I am a satisfied tester. Before me is always a list of tasks, prioritized by the project manager, arising from common goals. I know where the product and the team are moving, I see the results of our work.

I check the internal tool for support staff - "Contact Center". As Timur already wrote in the previous article , the tester in the team deals with both the backend and the frontend tasks. In addition, I write autotests, help users of the tool with emerging issues and difficulties, participate in the creation of technical solutions.

At work, you need to interact with developers, so I learn a lot of the subtleties of development. And also I get experience in organizing and controlling work, because many things (bugs, for example) first of all pass through our department:

• testers first set up new features on test environments (by the way, administration skills are very helpful here);

  
  
• find pitfalls and periodically give valuable instructions that need to be considered when deploying an application in production.

University applied skills help me to look at systems from different angles, and therefore, to check their quality more effectively.

Unsolicited Tips

If we talk about tips, which, based on my experience, I can give to young professionals, I would highlight the following:

1. If it seems that the work does not suit you - most likely it is. Do not be afraid to change your occupation, it is better to try early than to realize that you have been engaged in "not your" business for many years. For you, no one will do a better life.

   
   

2. Treat every task as a great opportunity to gain new experience. Even if it seems that now this experience is useless, and the task is boring and uninteresting, you do not know what will happen in the future.

   
   
3. Do not try to mindlessly pull the strap, but control your contribution to the work and the returns from it. If something is wrong, then it is a reason to review the activity or even change it before it is too late.

By the way, I want to share a small list of references, which at one time really helped me quickly get involved in the work of a tester:

• "A Practitioner's Guide to Software Test Design," Lee Copeland;

  
  

• "Foundation Level Syllabus", ISTQB;

  
  
• Java For Testers, Alan Richardson.