The Quality Management division at Godel consists of two departments – QA Engineers and SDETs. While all IT people understand what QAs do, questions arise about the abbreviation SDET. We talked to Sr. SDET Aliaksei Lahvinenka about how SDETs differ from Automation QA, their functions in teams and what Godel projects they work on.
Who are SDETs? What do they do?
SDETs are Software Development Engineers in Test, who work with testing. This is a very broad concept – many companies understand it differently, so the question is very relevant. To explain in simple terms, at Godel we mean by this abbreviation technical specialists who write code that tests other code.
In our understanding, SDET is part of the Quality Management process, which is 70% occupied with writing code for testing, and 30% with manual activities. SDETs are more technical people than QAs, they work more with the code part of the application than with the visual and functional parts. In essence, an SDET is an engineer who does everything possible to simplify the work of manual testers and, together with the entire team, is responsible for the quality of the product.
You can often see the position of Automation QA in job descriptions – the difference from SDET is not always obvious. What do you think is the difference between them?
Initially, these were different names for the same concept. But after some time, it evolved into separate things. In quite an opposition to the name, the Automation QA began to be called a specialist who writes code (some specific type of automated test) and is not very involved in the rest of the process. SDET should be more involved in the team’s processes. His or her main task is to simplify and speed up testing, research and investigate problems. SDET is expected to be more automated. This does not necessarily have to be one type of test or tangible testing. For example, automatic preparation of test data is also a part of the process.
Let’s look at SDET in practice. What do your tasks look like on a project?
It all depends on the team and the role of the SDET. Let’s say there is a development team and a testing team on the project, which consists of QAs and SDETs. In such a stack, the main job of the SDET is to study the problems of manual testing, find problem areas and create automation, with the help of which they can be fixed. In the standard version, this can be writing tests that will greatly simplify the work of the manual team, preparing test data, non-functional testing.
If we talk about the SDET as the only member of the QM team, then they becomes the main actor or actress and the most important person in quality assurance. They must create a story himself or herself, come up with a scenario, find vulnerable or recurring places within the framework of writing scenarios. If this specialist is a member of the customer’s team, there may be a combination of the previous two options.
The SDET conducts an in-depth study of the problems. If the specialist works on the customer’s side, they first need to prepare a presentation of the problems, prove that they exist, show what they are, and how they can be solved.
What projects are SDETs working on at Godel?
SDETs are involved in almost all projects – that might be my personal experience, but I can’t remember one where there were only QAs. As a rule, teams have only SDETs or SDETs + QAs. If we talk about business zones and technologies, then again, SDETs are involved in all areas. We work mostly with JavaScript and .NET, there is also Java. We work with both mobile and web applications. There are purely back-end applications where there is nothing functional to test. SDETs are in demand everywhere!
What does it take to become an SDET? What skills do you need to have? Tell us your story.
Any member of the QM team should be inquisitive. It is important to love to explore – sometimes we come to something without understanding anything about the system at all – for this, you need to understand it, and look for ways to interact with it. It is important to have a technical mindset since you must work a lot with code. You should also be sociable and communicative. Unlike developers, SDETs must communicate a lot and find out things from other specialists. English is a must in our work: we find out a lot of details, and communicate with different teams. In my opinion, any relevant education – not necessarily higher – will help prepare a person to think more technically, so it certainly will not hurt.
I studied at university in a technical speciality, we had a lot of non-development subjects: we touched on the topic of application security, deeply immersed ourselves in their network part, and logic was a very important aspect. Initially, I planned to become a developer, but while studying at university I noticed that I was more interested in understanding problems than just writing code. Being students, we had a lot of tasks to fix errors. When I saw an ad for testing courses, I decided to give it a try. At first, manual testing seemed boring to me, but at the same time, looking for problems and proposing solutions was very interesting. Since I had a good technical background, I was offered an internship in Automation QA.
I worked in this position for some time – as I explained above, I didn’t really care why I was doing something: they gave me a task – I sat and automated. After a while, I began to wonder why I was doing something, and what was the benefit. I gradually came to SDET in my understanding: you don’t just need to sit down and write code, it is important to understand where it needs to be written, and where you can get by with other methods.
So, it is not necessary to start as a manual tester to grow into an SDET?
In our division, this is a normal practice – some QAs later become SDETs. It is important to understand what suits you best. It is not necessary to start with manual testing – it is quite a long path, and the more responsibilities you have, the less time you have for training. Sometimes it makes sense to start with SDET right away. But in any case, it is worth understanding that for an SDET internship, you need to know both technical and manual QA parts. We expect that a person understands what testing is and how it happens.
What advice would you give to a newbie? What skills should be improved to become a high-level professional?
The main advice is not to be afraid to ask questions. There are no questions that should not be asked, there are problems that arise after you do not ask a question. We always have support for young employees – it does not happen that newcomers are left alone on a project. In any case, senior employees look after them. We have a very friendly team, we always support new colleagues, and we make sure that everything is fine with their projects. Self-confidence, communication skills – and everything will work out!