I saw the transformation of the QA world from the emergence of the SDET happen right before my eyes. Around 2008, I was working at a commercial website that had about 120 people in the IT Department. Of those 120, 10 to 15 were UI testers. Their job was to sit at a keyboard and manually exercise features on the web site. The approach was old school, but it worked for the time being. However, that 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, who proved to be the harbinger of the massive changes that SDETs would bring.
The Emergence of the SDET
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. The interview started; SDET 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 work flow and output of the 3 SDETs was equal to 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 and no SDETs. 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 this 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, so 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 of an SDET were 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
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. Hot fixes are no longer done by hand copying files via SSH on a case by case basis. We create and destroy environments on whim. Our releases are run by code that make 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 you're 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 should be - handled by automation and SDETs, otherwise the competition will prevail.
But still a set of myths linger on in the minds of many non-technical executives. The myths - while not ubiquitous, still prevalent - are that anybody can be taught to program and that any entry level manual tester can be transformed into an SDET given the proper amount of training. And, since 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 takes a lot to know how to drive a race car safely at breakneck speeds. The same is true of modern testing and the SDET role. 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 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 they’re an SDET or they're not.
mabl is aimed at bridging this gap between the tester and the SDET by empowering testers to easily create codeless tests that are as effective as those coded by more seasoned programmers that can seamlessly integrate into your work flow. Get your free trial now and see how powerful your tests can become.
