I’ve had a number of questions about the SET role and it seems I have confused folks when I say that the SWE is a tester and the SET is a tester and at the same time the SWE is a developer and the SET is a developer. What could possibly be confusing about that?

Oh, yeah. Right.

My next series of posts are going to detail the role of the SET and all will eventually be clear but some clarification on career path seems worthwhile.

SETs are developers who write test code and automation as their primary task. They are in every sense of the word a developer. When we interview SETs, SWEs are on the interview loop and SWE questions are asked. They are not all of the interview, but they are part of it.

This means that the skill set that our SETs possess makes them perfect candidates for switching to the SWE role. There is neither incentive nor deterrent to do so. SETs and SWEs are on the same pay scale and bonus structure (I have both roles reporting to me so I have real visibility into salary data) and their promotion velocity (again based on actual data) is roughly equivalent. This means that SETs have no outside influences to prompt them one way or the other.

The key factor is really the type of work you are doing. SETs who find themselves involved in SWE work usually convert to SWE. SWEs are also drawn in the opposite direction. Much of this happens through our 20% time work. Any SET interested in SWE work can take on a 20% task doing feature development. Any SWE interested in automation can find a group and sign up for a 20%. Right now I have both SWEs and SETs involved in such cross pollination.

The ideal situation is that the title reflects the actual work that you are involved in. So if an SET starts doing more feature dev work than automation, he or she should convert, same for SWEs doing automation work. In my time here, conversions in both directions have happened, but it is not all that common. The work of both roles is engaging, interesting and intense. Few Googlers are walking around bored.

Bottom line: do the work you are passionate about and capable of and the right job title will find you.

BJ Rolison (I.M.Testy)   http://blogs.msdn.com/imtesty
BJ是微软负责EE工作的Test Architecture，也是HWTSaM的作者。他的文章非常有条理，看起来也比较容易，其中的数据也非常丰富，是我喜欢的风格。

Alan Page  http://blogs.msdn.com/alanpa/ 
Alan是微软负责EE工作的Director，是HWTSaM的主要作者，他的博客是了解微软测试非常好的一个窗口。最近几年，他不限于测试技术的推广，他更多的考虑是测试管理，以及测试氛围/文化的形成，以及对于测试的影响。我很同意他的一句话“95%的UI自动化测试都是浪费时间”详情。他的博客文章比较随意，有时也不知道他在唠叨些什么，但不时却有很多精彩的观点。

Google Test Blog http://googletesting.blogspot.com
这是Google官方的测试博客，信息量很少，除了每年一次的Google Automation Test Conference之外，文章较少。今年6月，James Whittaker离开微软，加入Google后，才到这里增加不少好文章。

James Bach的博客  http://www.satisfice.com/blog/ 
James是一个软件测试的资深人士，90年代曾在Apple和Boland公司���过测试管理工作，后来在其他一些公司负责测试流程和质量管理，2000年自己创办了satisfice测试咨询公司，提供软件质量保证相关的咨询和培训. 他和Cem Kaner撰写了很多Explorary Testing相关的文章和书籍，并且提出了Context-Driven-Testing，这些方法论很适合现在的Agile Testing的特点。

Adam Goucher的博客  http://adam.goucher.ca/ 
一个多产高质的测试写作专家，基本上每个月都有10多篇关于测试的文章，有时候一天写了多篇，真是非常佩服他的写作能力。他的思想很有深度，对软件测试各个方面都有全面的理解，他阅读了几乎所有新出的测试书籍，并且些了与其相关的评论。这些评论通常非常尖锐。比如说，HWTSaM的评论,他的评论就比较中肯。对James Whittalkes的 Exploratory Testing评论 却是嗤之以鼻。