Test Engineer, Test Automation Engineer, Test Architect, Quality Assurance, Quality Control and now comes the SDET – WTF! What is Software Testing, a pool of confusing glossary? As if Test Strategy, Approach, Plan, Method, Technique, Types, Levels, etc. wasn’t enough for the Tech-world. Recently my LinkedIn feed is flooded with recruiters wanting to hire this new-test-engineer-who-knows-development, leaving me more confused with my actual role as ‘Test Engineer’!
SDET, expands to Software Development Engineer in Test OR Software Design Engineer in Test. Don’t get confused. In simple terms – the SDET is a tester and also a developer. Haha! Confused? I too felt the same. No one is crystal clear about the SDET role – I guess not even an SDET himself/herself 🙂 a fancy word adopted by Microsoft and every one going Gaga over it!
A Tester who knows development. An automation engineer involved throughout the development cycle. A Tester who develops Automation framework after studying the Software Design. A developer who can test. A developer who writes automation scripts. A developer who can test the actual code white-box. An architect who develops a generic automation framework. A Software Design architect who is focused on testability. A developer who knows how to test software. A Test architect who can understand software design. Blah Blah Blah!!
What is SDET?
Software Tester – tests the software. Software developer – develops the software. SDET, who can participate in development of the application and also in testing of the software developed. SDET are often involved in developing the quality code which is useful in automation of test cases or designing the testing framework which can be used as a testing tool. As you might have guessed – they are highly skilled resource with development as well as testing skills. You can think of it as a Test Automation resource with extended responsibilities.
In short – SDET is not a manual tester. SDET is not an Automation tester. SDET is not a developer. SDET is an engineer who know programming and software design concepts, who can code to test a software and is involved throughout the software design & development phases to keep a check on software testability and quality. It originated from Microsoft and currently many organizations are demanding such SDET professionals. This is a unique skill set which makes SDET a very unique role with high demand in present software industry.
Some say the shift is just to attract engineering talent. The popular myth is ‘There is no career in Software Testing’, resulting in shortage of skilled workforce opting for testing technology. Everyone wants to be a developer first. The result – let’s call it SDET, developer + tester 😉 cool, right?
SDET is just an automation tester with strong manual testing concepts so that he/she can write code along with the test cases necessary to maintain product quality?
Many manager don’t know what they need and have shifted their focus to automation testing without understanding how & when it should be implemented. The result – We want SDETs no matter the actual requirement.
Since Automation testing cannot ever replace the need for Manual testing, and organizations are not willing to hire two different type of testers – let’s hire SDETs.
What about Test Independence?
The level of quality and confidence only comes if you know the product, the components, and especially, the code within it. You‘ve got to code – and you’ve got to know how to do it right. Think of it this way: You can’t test something you don’t understand. It’s like building a car if you can’t drive. But what about the concept of Test team independence?
SDET and Software Testing
- SDET doesn’t mean software testing is going away. It just means that we are moving from pure manual testing to a more technical nature of testing a software. SDET is not just a test specialist with development-level programming skills, but a professional who can develop testing tools and frameworks to assist manual testing process?
- Creating a new yet-another job title is not helpful for team coherence or their perceived job responsibility. Yes, they might be doing a slightly different job but eventually a tester’s role is to find defects and maintain quality.
- Should SDET be aware of all Software Testing concepts? Or knowledge of programming and how to test is enough? After all, Software Testing is not just a technology, it’s a mindset. You can either build or you can break. There is a significant context switch between the mindset. Getting a balanced SDET to do both can be a tough job in itself.
- It’s useless – hiring a programmer specifically to test, creating useless automated tests that did not find defects. That’s true – we seldom see automated tests identifying as many defects as manual testing.
Last but not the least, everyone is thinking about Automation. Hire an automation expert and we are safe. But have you ever taken a ‘Manual vs. Automation’ defects retrospective of your last 5 projects? I bet Manual will beat Automation hands-down. Automation can cover just a percentage of Software Testing (like regression), for everything else you need a hard-core tester 😉 But if this trend continues – there will be a day when most of the SDETs know more about programming and scripting than testing, i.e. in a few years we will have an overload of people writing scripts who don’t know about the basics of testing.
There are more open questions surrounding SDET than the answers. If you are an SDET, please help us in clarifying some of the doubts. And if you are not, let’s think of it as a Test engineer who knows programming and can aid in Software testing process by developing tools, frameworks, utilities and reviewing the software design from test perspective.