8

I am raising a question I'm sure some of you had to tackle or will tackle soon. More and more software projects are adopting the test automation approach. Test automation can be achieve in multiple ways. In a project I joined lately the approach we have chosen is to recruit a team of software engineers that will be responsible for testing the project. We call this position Software Engineer in Test. This team will be able to consult the Software Engineers how to work with unit tests and will produce the more high level tests of the system (e.g. integration tests, end to end tests, performance tests, etc...). The Software Engineer in Tests will also write tools that will facilitate testing like simulators, data generators and the like.

In my point of view, this position is very interesting and requires not only finding excellent software engineers, but also ones that have great passion to what they do and that pay attention to quality. It seems that a lot of Software Engineers in Israel don't see eye to eye with my point of view and are not interested in this position.

My questions to you are:

  1. How do you suggest to sell this position to Software Engineers?
  2. Can you describe good and bad experience in recruiting to this kind of position?
  3. If you are a previous Software Engineer that changed to a Software Engineer in Test position please describe what contributed to your decision.

Thanks

5 Answers 5

4

I currently work on a small team, where I develop test automation in essentially the same way that you describe. To develop effective test automation at the higher levels, you have to be able/willing/trained to quickly perform the scenarios manually before they are automated. Inevitably, defects will be uncovered during these manual runs. As a result, the person running those scenarios should be trained in testing skills, such as recognizing defects from established oracles and submitting a coherent defect report.

You can have others run the manual tests and write detailed scripts to specify the automation to the "engineer", but that becomes very wasteful and the risk of mis-communication is great.

I agree with the opinion that the person you are looking for is someone with a coding background that is interested and trained in testing as a career. Advertising the position as a stepping stone to a development career is a mistake (IMHO).

Good luck!

1
  • Thanks, your input is important and gives me a direction I didn't think about. Although the software we build is supposed to run on server side and as such "screams" to be testing by test automation.
    – Ikaso
    Commented Feb 2, 2013 at 18:35
4

I'm a person who made the switch and I've worked on a team for two years which is primarily made up of SDETS. I was interested in it because I wanted to explore something new and I liked writing tests.

Hiring SDETS is very hard because you need engineering, quality and test expertise and they're seldom found in the same person. We find qualified test folks who don't meet our engineering bar quite frequently. The people who would meet the bar don't identify with doing this type of work, so we never see them. Do not get discouraged, it's going to take a while. (It takes us 3-6 months to find a qualified hire) Do not lower your engineering bar to make this hire. So how do you sell people on the position?

First off, you should get potential hires who self-identify as having a passion for quality. There are many developers who believe that they have this passion. Trying to sell someone who doesn't have the passion will be very difficult, and the performance of the person will probably not be as good.

Once you find a person who identifies themselves as someone with a passion for quality they will be easier to sell. For you, since it is a new team, you can try to find an "explorer" type person who wants to do something completely new. You can also look for people who enjoy writing tests. You can start the conversation about the position by asking exploratory questions. How do you achieve quality? What tools can you think of to do testing for X? Does quality really mean testing? Maybe it means measuring other things or writing tools to make testing easier. If you also have developers in house, I'd look to those people first. The most successful SDETs I know are developers who made the switch from SDE to SDET.

One last thing, we've been very successful hiring recent college graduates for our SDET roles recently. I think this is because they are more willing to try something new and haven't picked a career direction yet. The flip side (aside from a wide variance in performance of college hires) is that they are more likely to want to transition to pure development roles. So those types of transitions should be expected so make sure you keep the pipeline of talent warm.

1
  • Can we hear a bit more about how you define your engineering bar? Commented Feb 27, 2014 at 22:07
2

Personally, I would not sell it with the name you have. It implies you are making them only do testing, and if they are a software engineer you've already got your hands full trying to get them to want to do any testing of their own development, let alone a job that is completely about testing.

Instead, I would attempt to pitch this position as an Architect role that will have control over the ALM processes of the company. Instead of a position about "testing", it becomes a position about improving processes to achieve continuous delivery, and being able to track it. Part of that continuous delivery is the feedback and quality, which is where test automation comes in. You may also want these folks to be looking into better tools for tracking work, logging bugs, continuous deployment capabilities to support testing more often, continuous integration tools, etc.

Suddenly you've gone from a position of "Hey guys, I know you don't like testing, but we want you to test all the time" to "Hey guys, we know you have great ideas about how we can work better and we want to give you a promotion and have you define what is going to be the best process for our company to improve the quality of our builds". Give them the autonomy we all crave, and they'll bang down the door to do that job. Or at the very least they won't run from you in fear :)

On top of that, you'll also be telling them "It's okay, you can still code if you want to, because there are lots of automated tests the rest of the team will need help with".

3
  • 4
    Software Engineer in Test is a standard term other companies are using. Personally, I don't like bombing names that give illusions regarding the position I am posting.
    – Ikaso
    Commented Feb 2, 2013 at 16:57
  • I like this answer because it elevates the role beyond testing to creating processes that ensure quality. Testing is only one of those things.
    – Chris Calo
    Commented Feb 8, 2013 at 23:42
  • I would have to say the term Architect is fairly inappropriate here. A test engineer can certainly validate whether an architecture is viable or not through load testing, performance testing and other analysis. However, being able to prove an architecture is entirely different from the skill-set and responsibilities given to the team member to actual build the architecture. A true architect will have significant, if not absolute, decision making power over things such as hosting Azure, using a Service Bus or not, whether queuing is involved and so on. Commented Feb 11, 2014 at 20:59
2

I think you want to find software engineers who are already interested in testing. Your job is to sell them on the company, the product, and the technology.

I have met several extremely talented software engineers who preferred testing to product development. Those individuals were invaluable. On the other hand, I have also known engineers who joined the test group as a stepping stone into product development. There is nothing necessarily wrong with that, but you do not want to hire people who do not care about testing. If that kind of engineer does not move quickly enough into product development, they will be unhappy.

0

Let me share my experience. I had a telephonic conversation with a fresher who was offered SDET and not an SDE in my previous organization. I was asked to have a call to hear his concerns / doubts about the role. As a fresher he felt SDE is much superior compared to SDET / STE role. The discussion was in three phases

Phase I

  • I introduced myself; I had close 10 yrs exp in DEV-TEST-SUPPORT-DEV-QA. I switched back between roles depending on projects / products I worked on

  • He introduced himself, His interests, and ambitions

Phase II

  • I conveyed him the discussion is to provide clarity on SDET / SDE roles
  • As a fresher idea I observed his fear was, He did not want to remain as Manual QA, His understanding was career move / coding opportunities would be minimal in test function
  • I used my experience as a case to explain how I switched different functions, learning challenges in each role and how I managed to make it work

Phase III

  • Selling Pitch, I suggested him to take up the role, build QA tools, Automation Framework and move to development after proving himself in current role

Verdict

  • The discussion was well, I was not sure how much the candidate got convinced. I finally heard from HR he agreed for SDET position. After couple of months I had quit my previous Organization before meeting the candidate
2
  • Can I ask what a fresher is? It's a term I haven't heard before. Does it mean someone fresh out of school?
    – corsiKa
    Commented Feb 27, 2013 at 23:07
  • Recently graduated Engineers often referred Fresh Graduates
    – Siva
    Commented Mar 4, 2013 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.