Software Engineer in Test Unicorns & Coding Tests


(Jack) #1

For years I have been trying to recruit testers that can write code, or developers that have a good test mindset and don’t mind having test in their job title.

Why is it such a rare skill-set?

The software I work with has no front-end, you need to write code to manually test, let alone do anything else in-depth.

I speak to a good number of people that say they are an SDET (or whatever variation you can think of), but yet don’t follow core development principles. No their code doesn’t have unit tests! No they don’t do Pull Requests and code reviews!

But the main rant is with the coding test solutions. We have a simple’ish coding test we use to get an idea of coding skills prior to face-to-face interviews. Common practice now I know.
The thing is, so far only a few have actually had any tests.
Isn’t the clue in the job title.

I mean I could just about cope, maybe, with no unit testing around your code, but some system level tests please.
And maybe more than one.

Headcount for 13, found 4 in 9 months. Though that is better than I have done previously.

Sorry, just needed to let it out. Now to send out 3 more coding tests and cross fingers…


(Jason) #2

Problem, put simply: Testers who come from a development background are often the ones who failed to get a job in development. For testers with no development background, who want to go into development, it’s an uphill struggle. I stopped developing stuff over twenty years ago, first for a more senior, customer facing support role, and later test. Training myself back towards a more development oriented test role is proving anything but trivial (and that’s before you throw in modern build and continuous integration).

Perhaps you’d be better thinking of the so called Software Developer in Test as an infrastructure engineer who acts as an enabler (APIs, frameworks and so on) to less development minded testers?


(Jack) #3

Luckily I haven’t had that experience re: failed developers. The ones I have worked with (and now) are awesome developers who have taught me loads. But I guess that could happen.

But as for tester -> tester than can produce quality code, yes I agree it is an uphill struggle in most places (for those that want to gain those skills). I have found companies either don’t give the support for learning, or if they don’t not enough opportunity to develop the skills with real coding work. This is probably why there are so few that sit in this space.


(Paul) #4

In my experience there is no shortage of testers from some sort of coding background. There are lots of testers, especially from India and the Philippines, with CS and IT degrees.

However I do think that the previously non-coding testers who have learned coding just for test automation may find that the breadth of their coding knowledge suffers in comparison - i.e. in language and type theory, design patterns, algorithms, databases, networking, web frameworks etc. They would also lack the practice and coding experience that seasoned developers (even “failed” ones) and those who did significant programming at a very good CS, SE or technical IT course would have.


(Darrell) #5

I’ve often wondered why it is so hard to find testers who can write code.

Like seen what @darth_piriteze is talking about. People wanted to get into software development but they just didn’t work out. They would have a college or university degree in computers, had a software development job but didn’t work out. So the manager would try to get me to hire him as a tester. The thought was they had technical knowledge. If they could apply it to software development, maybe they could use it as a tester.

When we started doing automated testing, these same people thought this was something they would be good at. Maybe some of them see it as a way back into becoming a software developer.

As @paulmaxwellwalters points out, there are also people who just want into the industry. They don’t have the background of a person with a computer science degree. They probably got a job as a manual software tester and thought it would be a good career move to get into automated testing. They don’t understand things like different languages, design patterns, algorithms, etc.

Thus it isn’t hard to find either a person with a CS degree but failed as a programmer or a tester with no CS degree and just enough programming knowledge to write an automated test.

Personally, whenever I was a hiring manager, the best testers who were also good at programming, databases or networking tended to be people who were programmers, DBAs, IT/System Engineers but found they didn’t love it. They fell into testing and loved it.

I’m actually one of those people. I was a software developer. I was self-taught and worked my way up the chain. After 17 years of software development I still didn’t feel satisfied. I thought I’d be happier as a teacher. So quit my job and went back to school to work on a B.Ed degree. While working on that I took a job testing development tools (assemblers, compilers, IDEs, etc.). That was 20 years ago and I’m still testing… I found something I am passionate about.

I wasn’t a bad software developer. i didn’t even know what QA or Tester was. I took the job as a software tester because I didn’t want to take a ‘real’ job as a software developer. I never expected to fall in love with testing.

I think now I’d ask people to name a few books on testing. There are books I really enjoy like the books I read when I was a software developer. As a developer I liked books like The Art of Programming (Donald Knuth), Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides), Intro to Algorithms (Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein), etc…

As a tester I like books like Agile Testing (Lisa Crispin), Developer Testing (Alexander Tarlinder), xUnit Patterns (Gerard Meszaros), etc…

I start interviews with “Name a few books or authors who you have read and made you a better tester.” Maybe I have to accept blogs, podcasts, conference speakers, articles, etc…


(Kate) #6

I’m another who started as a developer then fell into testing and never looked back. The coding is a bit rusty these days, but that’s got more to do with being the only tester in the company so I do everything. It also means my automation has to be as close to zero maintenance as I can get it because I don’t have the time for complicated maintenance schemes.

That said, I’ve taught myself C# (and enjoy it) and enough F# to muddle through with it, I can work with pretty much any programming language that doesn’t use pointers (first language was Java. I’d need to really study to understand pointers). I enjoy playing with code and building test automation - but I strongly suspect I’m operating at a level that would terrify a lot of people who think they know test automation (I’m extremely active on SQA stack exchange and some of the code-based questions there…)

People who don’t understand code structures and can’t break down a problem in a way that will end up with usable, maintainable code are not good choices for SDET positions. They might be okay for expanding on a well-written test suite in a language they’re familiar with, but they don’t typically have the skills to create frameworks - or create ways to speed up testing tasks by building utility tools.

I admit I don’t have nearly as much unit testing of my code as I should (I tend to create it in small chunks that I build on iteratively), and there’s not much in the way of code review happening (where I work the devs don’t do much code review either, and I don’t really have the ability to get them to review what I’m doing - not to mention my automation work keeps getting pushed to the side by things that need to be done now. The joys of the lone tester).

And I love the book list. Both Agile Testing and More Agile Testing are excellent books. My other go-tos for improving my skills are the Dojo, this forum, and the Ministry blog roll. The blog feed is possibly one of the best resources online.