Random work related entry.
What is a Software Development Engineer in Test [SDET]? In it’s most abstract form, an SDET is a developer that writes software with the purpose of testing other software. In ‘softie terms, if SDE writes software with the focus of producing a product, an SDET writes software to test the SDE’s product. It’s what I’ve been doing for the last 16 months, and for the most part it’s been a satisfying experience, although there have been a hiccup or two recently… but the question I that of role: “what does an SDET do” for a product.
As part of the MSDN “in product” team, I am a person with a foot in two different groups: I work with MSDN content with a the focus of supporting Visual Studio, SQL Server, and any other application that uses the Document Explorer application. You can imagine that with Visual Studio and SQL Server 2005 shipping in a couple of weeks, work will be slowing down to a nice normal level. Great imagination and one I’m jealous of. Once the English version ships, localization efforts will continue, as will the work for VS Team Foundation: we’re hardly “done” with this process, even after the shiny boxes appear on store shelves… not to mention that our Quarterly Library and monthly TechNet shipments: those continue year round.
And as the cycle continues to ebb and flow, that brings me to my musing of what is a Tester in 2005.
My first “real” job in the software business was in a test organization, working for the now-legendary (and non-existant) Enterprise division of Symantec Corporation. It corrupted me, this working for a solid company with fairly deep pockets of money to make payroll: I never thought about a career before I started working there… was a good incubation environment for a young QA Analyst. After my local office moved from CT to CA, I stayed in CT and started on a career as a developer, which kept me entertained and well stressed for a number of years.
Stressed? Yes, stressed. I never seemed to have enough testers for any of the projects I worked on! I saw this as a problem, but I did what I could. Not to mention the constant worry about where the next paycheck was coming from… anyway, I always liked coming into my Dev role from a Test background: it made me more conscious – or at least understanding – of bugs than I think I would have been if I had started out as just a coder. I’ll never forget one Dev that worked for me at one company that not only told me that he didn’t have any memory leaks in his code, but that he had never seen the Output window in VS. I guess he’d never bothered to look at it before… incidentally, he was working in C++, using new all over the place and never calling delete. It’s for hacks like him that managed code was created, the doof.
Anyway, back to the question at hand. In the mid-90’s, QA was considered to be a gatekeeper for products. Nothing should ever be released until QA blessed it. QA was on the hook for everything the product did; any problems would be traced back to QA. Except when QA was overruled, which happened a few times in the life cycle of the Enterprise products group. As I recall, we dubbed our 1.1 version as “Now with error handling!” We didn’t win any brownie points with the VP’s, I can tell you that, but we stood by it as the truth.
Now it’s 2005: what’s Test’s role these days? Less of a gatekeeper’s job, I can tell you that. It’s more of an assessment of quality. Blame for bugs that slip through will impact all three parts of the product team (Dev/Test/Program Manager) so Test doesn’t stand alone anymore. Also, because modern products can be so large, there’s no one feature teams that can assess the over all product quality – it’s subdivided for the teams – so one Test team shouldn’t be able to determine what is “good enough”. I report on what my features are doing, and what they should be doing; what that translates to in release schedules is not my call.
We are witnesses of quality, more or less; we live to tell other teams what is and is not working in the product. Or as I like to think of it “Whipping Boy, Scapegoat for Excellence”. After all, even within modern companies, there are still Developers that look down on Testers as inferior workers or second class citizens. It doesn’t happen nearly as often as it used to, but I’ve still felt it in spite of having a full decade of developer experience… Whipping Boy is still very much in a Tester’s title, not for the faint of heart or thin skinned.
The follow up question to “What is an SDET?” is whether or not it’s something I want to stick with, long term.
With the right project, it’s a great gig. You are empowered to assess quality, improve your tech skills, assist all aspects of the team, and be a part of a great product. With the wrong project, it’s a nightmare on many levels: all of your assessments are ignored, you can hardly ever get an accurate test due to code churn, and you realize, long before the project ends, that it will be your neck on the chopping block even though you’ve done everything you could to ship a quality product. A tale of two worlds – or an episode of Mirror Mirror, you decide.
In my current role I’m tied to two projects: one online, one offline. Sort of a Ying-Yang deal. The offline project is kick ass and has been for over a year. Solid processes in place, interactive developers, well documented product. The online project feels like a tightly tied plastic bag that’s been wrapped around my face, before having my head shoved into a hole in the dirt like an ostrich. While the individual team members are solid, the overall process is a wreck and that impacts effectiveness. What’s a Tester to do? A Tester instinctively analyzes the situation for quality… and I’m not too happy with what I see. The question remains: has this been enough to soured me on my current SDET role? Hard to say. Now is not the time to consider it, as I’m still knee deep in bits, but it’s a question that will be answered over time, I’m sure.
Sorry for the glimpse of reality: I think it’s a result of working the majority of the weekend (even during the Blogger Tournament and with a break to get some apples at Fred Meyer).