Are you a Software Engineer in Test or Test Engineer?

Technical recruiters are always looking for automation engineers or testers that can deliver valuable contribution to the company saving lot of time and resources. Although different company uses different approach to recruit automation engineers, nowadays most of the companies are following the model that Google has implemented successfully to hire the engineers for their need.

As explained in “How Google Tests Software”,  James Whittaker, Jason Arbon and Jeff Carollo has described the three roles that Google have created making the engineers responsible while making productive and more quality-minded which are described below.

• Software Engineer (SWE) : SWE’s play the role of tradition developer  writing functional code that is dispatched to the user. They also create design documentation; choose data structures and overall architecture of the automation framework. They are involved in writing test code, test-driven design, unit tests and they own quality for everything they touch whether they wrote it, fixed it, or modified it.
• Software Engineer in Test (SET): SET also wears the hat of developer role but focuses on testability and general test infrastructure. SET’s review designs and looks closely at code quality and risk. They are more involved in refactoring code to make it more testable and write unit testing frameworks and automation.
• Test Engineers (TE): TE is similar to SET role but focuses on testing on behalf of user first and developers the second. They are involved in writing the code that drives usage scenarios mimicking the user.  In short, TE’s are product experts, quality advisers and analyzers of risk.

Although the definition of three roles seems self-explanatory and we are more interested the later two roles, lot of people including myself are always wondering what engineering hat do we wear every day.

To answer the question,  James Whittaker, Jason Arbon and Jeff Carollo has summarized the list of questions that could help you decide whether you belong to the SET or TE.

You might be a SET If

• You can take a specification, a clean whiteboard, and code up a solid and efficient solution.
• When you code, you guiltily think of all the unit tests you should be writing. Then, you end up thinking of all the ways to generate the test code and validation instead of hand crafting each unit test.
• You think an end user is someone making an API call.
•  You get cranky if you look at a poorly written API documentation, but sometimes forget why the API is interesting in the first place.
• You find yourself geeking out with people about optimizations in code or about looking for race conditions.
• You prefer to communicate with other human beings via IRC or comments in check-ins.
• You prefer a command line to a GUI and rarely touch the mouse.
• You dream of machines executing your code across thousands of machines, beating up algorithms, and testing algorithms–showing their correctness through sheer numbers of CPU cycles and net- work packets.
• You have never noticed or customized your desktop background. Seeing compiler warnings makes you anxious.
• When asked to test a product, you open up the source code and start thinking about what needs to be mocked out.
•  Your idea of leadership is to build out a great low-level unit test framework that everyone leverages or is highly exercised millions of times a day by a test server.
• When asked if the product is ready to ship, you might just say, “All tests are passing.”

You might be a TE if

• You can take existing code, look for errors, and immediately under- stand the likely failure modes of that software, but don’t much care about coding it from scratch or making the change. You prefer reading Slashdot or News.com to reading other people’s code all day.
• You read a spec for a product that is half-baked, you take it upon yourself to fill in all the gaps, and just merge this into the docu- ment.
•  You dream of working on a product that makes a huge impact on people’s lives, and people recognize the product you work on.
• You find yourself appalled by some websites’ UI and wonder how they could ever have users.
• You get excited about visualizing data.
• You find yourself wanting to talk to humans in meat space. You don’t understand why you have to type “i” to start typing in a certain text editor.
• Your idea of leadership is nurturing other engineers’ ideas and challenging their ideas with an order of magnitude more scale.
• When asked if the product is ready to ship, you might say, “I think it’s ready.”