February 2011

Test Engineer

I took time to comment on James Whittaker’s excellent blog post on the roles Google has defined within it’s testing organization and I wanted to share it here.  The basic concept is that the development and testing roles can be defined as Software Engineer (SWE), Software Engineer in Test (SET) and Test Engineer (TE).  The breakdown of tasking is described as SWE’s write functional code, SET’s write unit test code and modify function code to make it more testable & TE’s write integration & user scenario test code as well as coordinate the testing work of the SET’s & SWE’s.  Wow, that’s a lot of code being written by everybody & only one of those roles is writing code that customers will actually use.  I commented to disagree with the idea that all of these roles should be focused primarily on cranking out code, particularly the Test Engineer.  I’d love to hear what your thoughts and experiences with the matter are.

“My experience as a titled Test Engineer at an aerospace company aligns well with James’ description with the exception of the statement that I spent most of my time writing automation. A majority of my time was spent working with the customers on how they use the system, researching test methodology & learning/testing the system I was working on in the lab. I typically performed those tasks in that order, over & over again, week by week until the project was complete. The automation I used as part of my testing was to simulate a random input generating live system that communicated with our system via an API. I needed to be able to control the input so that I could test different user scenarios & that’s where automation became useful. However, I did not write the base test code, the code was written by an experienced developer who modified an existing script in a matter of minutes to do the basics of what I need. It was a fairly simple program so I was able to expend it to simulate exactly what I needed. The customers were impressed that I was able to not only create scenarios to test individual events & functions but that I was also able to create interesting real world scenarios to show how the functions integrated. I was able to design a large volume of user scenario tests because I was I had the benefit of a development expert modifying a piece of code for my own testing use that I could further expand as my test ideas expanded. A TE should be focused on how the customers use their system first & foremost. Automation is a tool to help them achieve the best possible scenarios in the smallest amount of time.”