What does a Software Development (or Software Engineer) in Test do?

Question

I applied for a job at google which is Test Analyst - I thought it would fit me due to the description of the job. Then I got a call and they are looking more of a software engineering in test. Now this brought me to a question to myself and my fellow QAs:

1. What is Software Engineer in Test?
2. I am currently doing automation - selenium and C#. This may still mean I am not a software engineer? I may do coding but now I came to realize I am just automating the manual test cases. Are there other uses of automation aside from just automating the manual test cases or am I just not on the right track?

Answer 1

Without looking at the exact job description, my personal opinion is:

A software engineer in test is more likely coming from a software engineering background but develops into a tester later on. They are more of a coder than a tester.

I am not saying a tester is necessarily a less-good coder but it is a general perception.

I suspected that your past working experience did not fit Google's job description; they were looking for someone with more programming experience than you do now.

Answer 2

I recommend you reading answers to a similar question: What is the difference between Software Test Engineer, Test Automation Engineer and Software Developer in Test (SDET)?

Here would like to answer in detail to the following part of your question:

Are there other uses of automation aside from just automating the manual test cases or am I just not on the right track?

Yes, there are. I recommend you reading "A Context-Driven Approach to Automation in Testing" of James Bach and Michael Bolton. Part of that is covered also in the James Bach presentation "Agile Test Automation":

• Test generation (data and script generators). Tools might create specialized data such as randomized email messages, or populate databases, or generate combinations of parameters that we’d like to cover with our tests.

• System configuration. Tools might preserve or reproduce system parameters, set systems to a particular state, or create or restore “ghosted” disk drives.

• Simulators. Tools might simulate sub-systems or environmental conditions that are not available (or not yet available) for testing, or are too expensive to provide live on demand.

• Test execution (harnesses and test scripts). Tools might operate the software itself, either simulating a user working through the GUI, or bypassing the GUI and using an alternative testable interface.

• Probes. Tools might make visible what would otherwise be invisible to humans. They might statically analyze a product, parse a log file, or monitor system parameters.

• Oracles. An oracle is any mechanism by which we detect failure or success. Tools might automatically detect certain kinds of error conditions in a product.

• Activity recording & coverage analysis. Tools might watch testing as it happens and retrospectively report what was and was not tested. They might record actions for later replay in other tests.

• Test management. Tools might record test results; organize test ideas or metrics.