At the nascent stage of the IT industry, testers were hired in the company without much knowledge; it was enough to know English, and everything else was taught on the job. Over the years, the situation in the profession, as well as in the entire industry, has changed radically. The stereotype that a tester is the most accessible profession in IT and a kind of “springboard” before transitioning to developers is no longer relevant. But several aspects of the work are still debated in the community.
Test documentation is always necessary and helps in work.
The pace of development in today’s world is so fast that maintaining up-to-date documentation is impossible. Many QAs step on these “rakes” – they spend a lot of time writing documentation that almost immediately becomes obsolete and does not become beneficial in any way. But there are exceptions – it depends on the field. If we talk, for example, about the field of medicine, then the availability of documentation is regulated at the legislative level, and there is nowhere without it. In other cases, documentation is only a disadvantage — it takes time and effort and does not add benefit.
Knowledge of programming languages is not required for QA.
This opinion is shared among QA beginners who come to work after the courses and think it is unnecessary to know at least one programming language. This stereotype continues the misconception that programming is, they say, a complicated thing, and testing is nothing complicated, just “pressing buttons.” Of course, this is not the case. Sooner or later, any QA still needs to understand programming because it’s impossible to test something if you don’t know how it works. The tester constantly contacts programmers, but it will be difficult for him to advance beyond the position of a junior specialist if he does not know at least the basic development principles.
What you need to know depends on the direction in which the specialist plans to develop further. If he is going to remain a manual tester, he will need a general understanding of programming principles, not a specific language. If you plan to switch to automation, load testing, and become a leader, you need at least one programming language, which is essential to learn well and constantly write code.
Learn more: Magento 2 Quick Start: Magento 2 Installation with Composer
Why should ice be able to program? There are companies in which manual testers without knowledge of programming languages are appointed as leaders. But sooner or later, any product reaches the stage when automation is needed, and the team begins looking for an automatic. Two problems arise: firstly, there is no one to interview with the automatic, and secondly, even if he is found and hired, the lead manual worker cannot be a full-fledged manager for him because he does not understand precisely what the automatized does.
Automation will replace manual testing. Or vice versa.
It is the most heated discussion in the QA community, in which two myths are hidden simultaneously. The first is that manual testing is dying and will soon disappear altogether. The second, the opposite — automation cannot replace manual workers. Both statements are not entirely factual, and the truth lies in between. On the one hand, it is difficult without automation, and at some point in product development, it is simply impossible. Projects never shrink, they continuously develop and grow, and the more features a product has, the more time it takes to test them. There comes a time when the team starts releasing one part a week, and at the same time, for one new feature, another hundred such elements must be checked so that they do not “break” during the release process. The amount of time required for testing is growing at a tremendous rate.
Why was it initially thought that manual workers are better than automatizes? Because the time of manual workers is cheaper. Where you take one automatized to the team, you can hire from two to four “manual” testers (depending on the grade). And they will perform more – such an opinion existed before. But now it doesn’t work. The time of the automatic does not grow so much when the number of functions in the project increases. But in the case of manuals, time increases in proportion to the project’s growth. Each new feature is a plus conditional unit of manual time. Therefore, it is more profitable to hire one automatist than four manual workers.
Learn more: Customer journey map: a look at the product from the target audience
But there is another side to this question. Manual testing cannot disappear completely because it is impossible to automate everything, and it is not advisable to automate everything. Some projects, for example, are mostly built on Google Analytics. They create Google analytics dashboards in their admin and add internal analytics to them. Google services are third-party (external sources of information), and the team cannot influence their set of functions in any way, but at the same time, it is very dependent on them. You can automate the testing of such a project, but with any change of functions on the part of Google, you will have to correct all the tests constantly. At the same time, much time is spent on support, and it is more appropriate to use manual testing here.
“Automation” and “manuals” are different teams that must work separately.
We often see this vision among leaders and automation from outsourcing companies. What does it look like? Once per sprint, the manuals come to the automation team, bringing the finished documentation and all the test cases and inspections they want to do. Automatizers do these tests during the sprint, while not always independently checking them for correctness, and then give them back to the manuals for checking. What is the problem here? Automatizers in such a system do not know the project’s essence and the business value it brings. They test functionality without understanding why it is needed in the context of the entire product. But this slows down both the professional development of the testers and the project as a whole.
How should it be arranged? One general team, plus a General QA specialist, covers automation and manual testing tasks. As a rule, this is a team with two to three developers to one QA. They have features that they develop and cover the entire testing cycle. This approach is common in small cross-functional teams in product IT and is very effective. Any team member can bring additional value not only through the performance of their duties but also with new ideas and visions, and this will not happen without product knowledge.
Technical academic education is mandatory for QA.
If you look at jobs for QA, you will hardly find a single one that does not require an academic education in a technical field. Ukrainian companies often add the exact requirements that create products and services for Western customers. There are two reasons for this approach. First, academic education in foreign universities is organized fundamentally differently. The presence of an American or European diploma gives at least minimal guarantees that the specialist is knowledgeable in theoretical issues, and companies pay attention to this.
The second reason is that many QA professionals enter the industry after completing courses. Their expertise is limited to the QA area, and a basic understanding of networks or HTTP work, for example, is often missing. At the same time, the tester must work on a web project which will be difficult for him without understanding the principles of the Internet. However, in Ukrainian realities, a diploma in higher technical education does not guarantee much, and the company looks at the skills and readiness to grow, develop and engage in self-education.
Learn more: Manual QA in Magento 2 for Beginners: start your journey to a professional
If a programmer works, for example, on a project related to banking, then an academic education in finance will be more beneficial to him than a technical one. And all the necessary professional skills and knowledge can be obtained in courses, from numerous books on testing, and most importantly – in practice, learning in the process and exchanging experience and expertise with colleagues.