Are you ready to be the next level Test Automation Engineer - Software Developer In Test (SDET)
Kushan Shalindra Amarasiri
Head of Quality Engineering at Social Catfish
Test automation has evolved during the past years and it is at the stage of climax. There are so many tools that have evolved into the market, which caters multiple magnitudes of applications. There are test automation tools for Web, Desktop, Web Services and even mobility. Test tools supports multiple programming languages like Java, C#, Python, Ruby, etc.
For a Quality Engineer to engage in test automation there are more roles and responsibilities evolved over the period of time as test automation tools have also increased its capabilities. Automation engineer regarded in the industry as a person who automates a set of manual test cases using a test automation tool like Selenium. Today a test automation engineer should play a role of a software developer and he/she is required to know coding and software development techniques that a software developer should know. Earlier the title, test automation engineer was changed to Quality Engineer. Now it has changed again from Quality Engineer to Software Developer in Test (SDET). Let’s see what are the modern needs that are required by a SDET.
- Should be familiar with multiple programming languages - As we discussed above, test automation tools facilitate scripting test cases in multiple array of development languages. Therefore, a SDET engineer should learn multiple languages and should be also competent enough to switch between programming languages when its needed. The future there will be more demand on Java, Python and Ruby test automation projects and the SDET should be skilled on this programming languages.
- Should know integration between multiple test automation tools - The automation developer should have a knowledge on how to integrate between test tools at API level which will build more extensible test automation frameworks. He/she should be also skilled to integrate the test automation framework with other tools such as JIRA and Bugzilla by looking at the available web services APIs. Automation developer should be having an updated knowledge on all the third party libraries and APIs that are available which can be used to enhance the current test automation framework (Example new reporting tools that that can be incorporated to the test automation framework)
- Use of Behavioral Driven Development tools (BDD) - BDD is a main software development methodology that every development project or an organization undertakes. It helps to come-up and understand requirements crystal clear within all stakeholders. BDD is practice is now included into the software development process as well as software testing process. The test automation (SDET) engineer should be familiar with tools like Cucumber, SpecFlow and JBehave. He/she should know how to integrate these tools into the existing test automation framework or create a test automation framework incorporating BDD.
- Well-equipped to with the use of developer support tools - The SDET engineer should also know how to work and use tools that are for a collaborative developer environment. The test automation developer should work effectively with versioning tools (such as Git) as the test automation codebase always should be under a version control mechanism. He/she should be well versed on how to maintain the version control repository and how-to maintain different version of the test automation codebase when its needed.
- Integration with Continues Delivery - This is an utmost important area to know as we live in an agile world and most software projects works in a Continues Delivery process. The test automation developer should have a knowledge on Continues Integration tools available in the market, and should know how to deploy and maintain such environment concerning with the test automation framework.
- Working with the Developers and other stakeholders – SDET engineer should work closely with developers and should be knowledgeable on their coding styles and techniques. He/she should be at a position to even carryout white box testing. In future developers will be relived to just code the requirements of the software, while the SDET will even own the task of creating automated unit test and even the automated unit test frameworks. Even developing the test automation code, SDET should liase with the developer to carry out a practice like TDD.
- Should know every corner of the developed solution’s architecture – SDET should know the design and the technological architecture of the product being developed. He should also participate in developer discussion on product development. SDET can and should give ideas and feedback in terms of any architectural decisions that are taken for product development. He or she should suggest areas of testing for the software architecture of the software that has being developed. SDET should be involved in more towards Non-UI API level testing rather than UI based functional testing.
- Well worse on the technological jargon that is used in the industry – SDET should also know most of the technological solutions that we are utilizing when creating software solutions. They should also have a deep understanding on Big Data, IOT and Micro services architecture. They should know how we can deploy automated test into these types of projects and at which stage.
Hope this article helps you’ll to climb the ladder of success and be competitive enough to be in par with the testing demands in the global software industry.
Associate Technical Lead at WSO2 Sri Lanka
7 年your artical so informative and extremely helpful. Just wanted to convey my sincere gratitude and a big Thanks for all your help to Automation Engineers.
Sr. Manager, SQA Engineering | Agile Methodologies, Web Applications | DevOps
7 年Continuing my quest to understand this hype around automation better...interestingly...with evolving times..dev have remained calm and grounded with their skills...nothing new to be learnt; no new fancy designations; no new unreal expectations! They never coded well before.. they still continue to do so! Let us stop the 1-sided argument on automation...it is not only qa's job. Quality is not a pleasant surprise but an expected output. Automation in the older days was called as strong and thorough unit tests.. that conveniently have been skipped now to qa team. The article is good for everybody to learn thoguh I disagree on it being qa biased.