What should SDET CONTRIBUTE?

What should SDET CONTRIBUTE? 

I transferred to R&D group from support team 3 years ago. In the interview, I picked up SDE as my first choice, but the interviewer marked me as “suggest SDET”. I was suspicious about this conclusion, but it turns out I am really good at the SDET role. I love this role more and more. I really appreciate the wise interviewer.

When I recall the situation, there was no Harry Potter’s sorting hat. I thought SDE was good based on my perceptions. One of the perceptions is about contribution. I thought SDE (and PM) was the one that contributes to the product directly. SDET was just the person to watch out for the bad and compensate, and the contribution was less than SDE.

I believe there are many people have the same perception. Ambitious people are eager to work at the front line. This INCORRECT perception prevents many good engineers finding the right position. The following is a summary about my understanding about contribution between SDE and SDET.

QUESTION: Where does bug come from?

We have a bug because someone (Dev) made a mistake. Human being makes mistake so we have to get testers to test the product before shipping. This is the most common understanding. People think bug come from being negligent.

First of all, SDET should not be responsible for other role’s negligence. If a SDE forgets to valid a function parameter, the problem should be caught by code review and unit tests. You may say the tester also needs to validate the function. My argument is, for a specified function, why the tester is a better person than the dev to do such validation? The dev knows every implementation details, boundary checks, worst case in the algorism… There should be some validation work, but the dev should do that. SDET is NOT more competent to do such work. Protecting negligence is not the core function of SDET.

Actually, software development is contributed in two iteration phrases: make assumption and build things on top of assumption. Real bugs come from incorrect assumption.

In design stage, we assume the user scenarios, the performance of the platform where the software will run, and the support lifecycle after release. In coding stage, we assume an API’s possible exception types, the context of a function caller, and the memory pressure at runtime. Most of the assumptions are correct. Stronger developers usually make more proper assumptions. However, when an assumption goes wrong, a bug comes out.

This explains the contributions. SDE contribute to the products by making correct assumption lead to correct output. What about an assumption is wrong? This is SDET’s contribution: finding out the explicit and implicit assumptions we made and settle down them. Make sure the assumptions are 100% correct.

Build things on top of assumptions and settle down assumptions require different set of skills. This is why we have SDE and SDET roles. For example, building things requires the skills to do abstracting and refactoring. Fixing assumption requires the skills to permutate possibilities and simulating.

With this understanding, I can easily manage my work and priorities. My work is based on “how to figure out the incorrect assumptions effectively and completely”. Please note, this statement is different from “how to figure out the incorrect product behavior effectively and completely”. The difference is very important. The second statement reflects the goal, which applies to every role, while the first statement reflects the SDET role’s unique contribution.

The following examples are how I manage my work items.

When I see a bug is caused by Dev’s negligence, I will first focus on the Dev process, including code review and Unit Tests. It is because we assume such bug should be caught in the two stages. I will not take all my time by shooting every negligence issue. I think about the implicit assumption behind this, and target the assumption to find out the fix.

I will take special care of design phrase phase and integration phrase. It is because important assumptions are usually made in the two phrases. I will not wait until the binary comes out because the assumption was already made. I will have a lot of assumptions to work with just by checking the design. I will not wait for the matter of facts.

I will priorities my work by judging what kind of work may settle down assumptions more properly. I would rather skip some BVT automation, and use the time to verify an assumption which may break lots of P2 cases. When doing group review, I have a very clear goal which is figuring out incorrect assumption as earlier as possible. With this, I know what to think about when people talking about the FxCop, StyleCop, Design Pattern and other Dev’s slang.

When designing automation cases, I will consider the assumptions. As a nature assumption is correct things will work correctly when putting together, I will raise the priority for cases which focus on integration risks. Of course it implies another assumption which is, small function units are covered by dev’s unit tests correctly.

Traditionally, SDET’s work is based on end user scenarios and priorities. We will define P0, P1 and P2 cases, and verify, verify, verify. It is not bad, but it is a simple and rough methodology. Thinking about assumption also leads to the same end goal, but it is smart and effective.

Comments

• Anonymous
  March 10, 2011
  Hi.Thanks for detail .it was effective for me.currently i have joined as SDET .before i was dev .