Is it as easy for a tester to “enter IT” as they say?
You’ve probably heard this fact: by choosing the profession of a tester, everyone can easily “enter IT” and quickly get used to technologies. In practice, everything turns out to be different. Sometimes newbies do not consider how many different tasks a specialist can take on, in addition to testing. This is where the first difficulties begin.
QA Engineer at NIX and Speaker NIXMultiConf Sergei Mogilevsky is sure: no difficulties will prevent you from successfully starting in this profession with a great desire to learn. The field of QA is complex, but interesting. More details in the expert column for what exactly.
In recent years, it so happened that those who want to start a career in IT are looking for directions that do not require lengthy preparation and too specific knowledge. Often the choice falls on QA. But is the profession of a tester really that simple? I think yes and no.
Why the QA profession is good for a start in IT
A specialist in charge of quality control of an IT product will need basic skills – attentiveness, perseverance and understanding of the features of the application under test. All this is the basis, which in the process of work is complemented by the ability to use specific auxiliary tools (bug tracking systems, messengers, etc.). When the whole set of skills is formed, you can try yourself for a QA position. In the modern IT world, this will not be enough for a confident entry into the profession. To pass for a QA trainee, you need to know the theory and fundamentals of the subject area, practice with several applications, and learn common approaches to testing. These are all non-trivial things. However, they are easier to learn than some kind of programming, design patterns, or management fundamentals.
And I assure you: here you will not get bored even at the start, no matter how primitive the tasks may seem. This is only a first impression and is often deceiving. If you sincerely want to become a tester and are ready to put maximum effort into it, then quickly see in practice how versatile this profession is. There is always room to grow in this direction, but challenges are essential.
The ideal scenario for a beginner is after a couple of months of preparation to find and get a dream offer in a team of professionals and already see yourself in a warm and cozy office as a promising QA. But this path is accessible to few. Even if everything turned out so positively for someone, this does not mean that testing is an easy job.
QA community today: what to do and where to grow
When embarking on the QA path, it is important to understand that from the first job of a tester in his life, a specialist does not become a pure engineer, he is only a tester (remember the division into testing, QA, QC, and that’s all). A diverse world of a new profession opens before him, which he is just beginning to master. This is where the first difficulties appear. However, having coped with each of them, the beginner gets an excellent profit.
We have to develop systems thinking. Not everyone has a well-pumped “muscle” of systems thinking by nature. This is a skill that can and should be developed. With this kind of thinking, QA looks at the project more broadly, comes up with more correct and optimal methods of testing and test cases. Conventionally, when a young specialist looks at a feature, he sees only it and nothing else around. The maximum is a few close obvious dependencies. This skill is most evident when QA is faced with the challenge of planning testing for a large-scale project. If a specialist does not know how to view the project as a whole system with all internal dependencies and interconnections, it is highly likely that the team will not build a testing strategy in an optimal way.
If QA has set itself a goal at any cost to understand the feature and find the right approach to testing it, in the process of its development the worldview becomes broader, experience allows to find new useful test cases in the same features that it tested before, and work efficiency increases significantly. As a result, the QA engineer has more opportunities to deal with other tasks and reveal himself to the lead from the other side.
What happens in reality? Personally, at the very beginning of my career, I had a situation that I was one of the first to start a new project. I was given the opportunity to write test cases for a couple of modules in the system, and then I had to leave the project due to unforeseen rotations. A few years later, I returned to the same team, but this time in the role of a temporary reinforcement of the composition. What test cases do you think I came across in the manual regression run? Right, my own! Only humor turned out to be that I noticed this only when I discussed with a colleague the narrowness and ill-conceivedness of such checks.
It turned out that over the past months, no one got around to updating or checking these test cases. In general, everyone checked the functionality. But with a more pumped “muscle” of systems thinking, in literally five minutes I realized what I could not notice as a beginner. The checks, which then seemed almost perfect, were in fact superficial and poorly thought out.
Communicate a lot. QA is not only testing, but also the regular collection of information, documentation, building well-coordinated communication in the team (and sometimes the tester is attracted by marketers and IA to meetings with the client), as well as effective work processes. A specialist who knows how to quickly obtain the necessary information and correctly distribute it in tasks for teammates or share it with a customer is a pro worth its weight in gold. Such a person is the greatest asset for the team. A young specialist does not always understand what questions, to whom specifically and when it is better to ask, to whom to share the results of work and what to do with feedback. But once he has learned it, this skill has a positive effect on the awareness and awareness of the entire team. Thus, the project is progressing. The tester’s sociability, like all other team members, helps not to miss the moments that are important for the entire project and stay on the cutting edge of the IT sphere.
Now I am in a project where initially there was a very big communication problem for me. It was not only the QA team that experienced difficulties, but each team solved this problem in its own way. In this case, the lesson for me was not the decision process, but the result. My QA team worked quietly all year and it seemed that everything was absolutely perfect: tests are being written, tickets are closed, bugs are found. In general, a complete Feng Shui. And then came the local apocalypse. Suddenly, it turned out that neither the development team, nor the managers from the customer’s side had absolutely NO idea about what the QA team was doing. That is, something seems to be done, but what, how, when and why are questions that only QA engineers can answer, and then not everyone and not all questions. Analyzing the situation, it became clear to me that all our testers almost never discuss their tasks and actions with anyone except their closest colleagues. The problem was solved with the introduction of permanent reports and calls every couple of weeks to share testing news with the customer. Gradually, all team members clarified for themselves why constant high-quality communication is needed and how to set it up effectively. But that’s a completely different story 🙂
It is necessary to constantly master technical skills. Update and replenish the existing toolkit – a must-have for a QA engineer. It is difficult to overestimate how quickly and efficiently work can be done if the right tool is chosen for it. From the examples on the surface, automated web UI testing in Angular is much easier if you use tools like Protractor. At the same time, the work will be much more difficult if you use Selenium. In this case, it doesn’t quite fit. The ability to quickly choose the right tool and study it, if it has not yet been mastered, is a difficult, but every time an unusual and interesting task that always develops a specialist.
QA engineer and tester: what’s the difference?
Paradoxically, in practice, the main tasks of a tester differ from those of a QA engineer. The tester runs tests, verifies and verifies the actual result against the expected. The QA engineer has a lot of tasks to maintain the quality of the product. Communication with a team or a customer, planning testing work, generating specific project documentation and many other tasks. But if we treat such work as a long development process, then most of the skills come to the tester with experience. He participates in team activities, gradually gets access to more and more interesting tasks and strengthens his expertise. Little by little, a novice tester is approaching the proud title of a real QA.
Experience gained. New skills have appeared in stock. What’s next? You can always think of a different approach to testing something that has been tested a hundred times already, and find something that can be optimized.
For many, this sounds unusual and causes little resistance. Don’t be nervous 🙂 An ideal QA is a specialist who perceives each new task as a challenge and is eager to overcome it with the help of the existing toolset. Faced with an unfamiliar task, the tester will say: “I can’t do that. Find someone who knows how “, and the engineer will simply answer:” Let me figure it out and explain how I can solve this problem. ” And then he can also immediately say what he needs to further understand.
There are several specialists in my team who gradually began to share and support this approach. And exactly at the moment when they accepted the new rules of the game, when the fear of failure does not exist, and the next task is always an exciting and feasible challenge – they began to get more pleasure from their work and constant respect from their colleagues. These guys get new, “incomprehensible” tasks and in them they find constant growth for themselves.
What activities are available with the mindset described above? Yes, any! There are practically no restrictions. You can take on any task and learn something new from it. For example, the same types of testing, in addition to simple manual testing, are a treasure trove of interesting tasks of varying complexity:
automation of functional checks;
performance;
security;
accessibility and much more.
Among other activities, I can single out the following:
delving into the application code to find new options for checks or cut off duplicate ones;
applying new test design techniques to existing tests;
building new testing pipelines.
The list goes on. For their interests and skills, each specialist will find something useful for professional growth. To get access to more and more new activities, say “Yes” more often and less – “I can’t.” A cool engineer can do everything. And in everything that I am not yet familiar with, I am always ready to figure it out and do it myself.
The only limitation may be the project situation, the team, etc. But, as they say, he who seeks will always find. In the case of QA, this means that, with a strong desire, a specialist interested in personal development will always willingly take on new tasks and try to prove himself in other interesting tasks from an unusual perspective. I checked this on my own experience and can see it from my colleagues.
Personally, I would like everyone who conquers the QA profession to clearly understand: this is not only about testing. A variety of activities in this direction is suitable for almost everyone who is ready to be assiduous and attentive at the start. You just need to change the mindset a little so that the tester allows himself to become an engineer. Then dozens of new career opportunities instantly open up in front of him.
