Browse Month: December 2014

Dark side of a Software Development Engineer in Test (SDET)

A lot of people have an opinion that a software development engineer in the test is a more difficult, more responsible, more skilled position than that of an automation QA engineer who is actually just a ‘tester’. It’s because the SDET is almost a software developer: he deeply knows programming languages, design patterns, algorithms. He can create a high-quality, maintainable, and performant code. He creates tools for automated testing, writes his own frameworks – such kind of work is more complicated and, therefore, should be better-paying. That’s why many automation test engineers like to name themselves an SDET, alluding to their high skills and value.

Sure, everything said above is true, if and only if the SDET also has a deep knowledge of software testing methodologies and APPLIES it to his work. Unfortunately, in real life you can see the following situation:

There are two QA teams on a project – manual testers and automation testers (who proudly consider themselves SDETs). The manual team creates a set of test cases and passes them to the auto-team for automation. The automation team develops its own framework, converts the test cases to automated ones, writes test scripts, and runs them.

As you can see, there are two different roles: 1 – the team of highly skilled manual testers who write test cases and are responsible for the product quality, 2 – high skilled developers who convert manual test cases to automated scripts. Obviously, the manual test cases and the programming code will be much qualitative in terms of an architecture and design.

But, there are also some cons:

When the automation team receives manual test cases as an input and produces automated scripts as an output only, it means that the team is not responsible for the product quality. It’s because they cannot be responsible for the product test coverage, test strategy, or test design quality – they do not do this. And it also means that the AUTO-TEAM is the only one in the project who IS NOT RESPONSIBLE FOR THE PRODUCT QUALITY!!! And therefore it is not motivated to give the product of high quality. Their goal is tons of test reports marked ‘passed’.

Simple example. Assume there is a defect found in the production branch.

Customer: why has it happened and who is responsible for that?
Manual QA: I created a fine test case that covers everything you need, including the found defect. Then I passed the test case to the automation team. They converted the test case and ran it.
Automation QA: I covered all the requirements and all are reports are green (all the tests are passed).
Customer: But there is a defect!
Manual QA: If you run my test cases manually, you will catch the defect.
Automation QA: Our tools cannot catch such kind of bugs and It’s not my fault that the manual QA did not foresee that and did not provide a more suitable scenario. All my scripts exactly repeat the test cases, every single step.

To avoid a problem similar to the one described above, the SDET must have and apply his/her knowledge of manual software testing. He must be at the heart of the software development process as the customer’s advocate. In addition, he must be responsible for the product quality. So, any SDET must have a very deep knowledge of manual testing and preferably some working experience in this position. Sure, now he does pure automation and writes the code like a developer but he also must take part in the development of the test strategy, create his own test plans and test cases and be responsible for his part of the work.

If you hear someone calling himself an SDET, whereas this function is limited to the development of testing tools, you should know that this person must have come to the software testing from the development field (or always dreamt to be a developer but lacks qualification) and has an insufficient knowledge of software testing and reluctance to study it.

So, make your own conclusions but note that everything written above is only my personal opinion.