Either You're an SDET or You're Not
What's an SDET? Learn about the motivation for the Software Development Engineer in Test role and how automation is changing the face of testing.
Join the DZone community and get the full member experience.Join For Free
I saw the transformation happen right before my very eyes. A few years back, around 2008, I was working at a commercial website that had about a hundred and twenty people in the IT Department. Of those one hundred and twenty, ten to fifteen were UI testers. Their job was to sit at a keyboard and manually exercise features on the website. The approach was old school, but it worked for the time being. However, time was running out.
The website was the historic leader in its market. But, other websites were coming online and proving to be real contenders. These new competitors had no legacy technology to contend with. As a result, they moved fast. Their technology was state of the art and allowed them to get a new feature out in a month. My company needed months to make a change. Bigger changes could take a year. My employer understood that in order to stay in business, they needed to improve the way the company did technology. Otherwise, we would go the way of AltaVista, Excite, and Netscape. Part of that improvement was to embrace testing automation.
My employer pivoted. They hired systems architects that implemented a loosely coupled architecture to take the place of the monolithic web servers. They put an enterprise service bus into place to speed up data updates and memory caching for read-only data. Automated deployment did away with the weekend war room mentality that went with every manual release. Things did start to speed up. But there was a still a problem. No matter how fast things moved lower in the tech stack, when it came time to release a new feature, final approval was left to a QA department that was mostly staffed by manual testers moving at the speed of slow, inexperienced typists. Clearly, a change was needed. The change took the form of a Testing Engineering Manager.
A Change Takes Place
I remember the day the new manager showed up. Nobody really paid attention other than the typical greeting given to any new employee. No big changes were made at first. But, within a month a new position was created, Software Development Engineer in Test, or simply, SDET. Interviews started; candidates appeared. Simultaneously, the manual testers were "trained" on how to use Selenium. The hope was that some simple automation could be used to speed up UI testing while, in the background, SDETs were brought in to automate the entire QA process. Some of the manual testers picked up Selenium, some didn't. Some of the manual testers learned enough basic programming to encapsulate Selenium scripts to run on demand without human interaction. Some of the manual testers read the writing on the wall and simply quit.
Fast forward. Within a year, most of the manual testers were gone. In their place were 3 SDETs and a Test Engineering Manager. The 3 SDETs were doing the work of the entire QA Department and then some.
Déjà Vu All Over Again
Eventually, I left the company to take a leadership position at another company that had a QA Department staffed by 3 manual testers. The testers followed instructions listed on an Excel spreadsheet. Once a test was complete, they entered test results in another spreadsheet. It was déjà vu all over again.
As much as liked the manual testers and wished them no harm, I realized from prior experience that in order to get product out the door fast, these manual testers needed to be replaced by SDETs who could automate 90% of the existing test activity. Part of my job was to figure out how to do the transformation. We were not heartless managers. We didn't call the manual testers into a room and give them their walking papers. Rather, we explained that in order to stay viable, the company needed to automate and they needed to start to acquire the programming, analysis and logic skills required to become full-fledged SDETs.
Today, in reflection, I have come to understand that we would have done better to ask them to learn to speak classical Greek in 12 weeks. The skills they needed to acquire were just out of their league. They were hired to type input into a web page, not to record and run automated scripts, let alone do the analysis and programming work required of an entry-level SDET. Eventually, they left and we hired a third party testing company staffed with experienced SDETs.
Automation Is Key to QA Paradigms
Automation has changed the face of software development. Today we no longer provision boxes manually. We treat computing infrastructure as code. The same is true for deployment. Gone are the days of weekend war rooms where a bunch of sysadmins got together with cases of Coke and bags of chips to install operating systems and applications. Hotfixes are no longer done by hand copying files via SSH on a case by case basis. We create and destroy environments on a whim. Our releases are run by code that makes deployment continuous and constant.
The same dynamic is happening in QA. When it comes to testing in the modern enterprise, the simple fact is either you're an SDET or your not. Yes, it's true that more advanced testing such as complex, multi-system performance testing requires some manual intervention. But, for typical UI and functional tests, these are -- and must be -- handled by automation, otherwise, the competition will prevail.
But still, a set of myths linger on in the minds of many non-technical executives. The myths -- though not ubiquitous, but prevalent -- are that anybody can be taught to program and that any entry-level manual testers can be transformed into an SDET given the proper amount of training. And, that such transformation is possible, the expense of a QA Department can be reduced to minimal levels. This is akin to saying that anybody driving for Uber can compete in Formula 1. It simply does not work this way. It takes a lot of know-how to drive a race car safely at breakneck speeds. The same is true of modern testing. It's complex and requires mastery of a variety of skills: from programming and database administration to system administration and environment provisioning as well as application architecture. Those on the inside of technology understand this. Those on the outside, not so much. Many still freak out over the market rate for a good SDET. It's a foolish anxiety. Making software is expensive, always has been, always will be. The reality on the ground is that when it comes time to hire the right type of personnel needed to ensure the quality of your company's technology, the fact remains: either you're an SDET or your not.
Published at DZone with permission of Bob Reselman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.