Test Engineering at Google
Thursday, October 16, 2008
By Roshan Sembacuttiaratchy, Software Engineer in Test, Google Zurich, Switzerland
When I tell people that I'm a Test Engineer at Google, I get a confused look from them and questions as to what I actually do. Do I sit in front of a keyboard clicking every button and link on screen? Do I watch over the infinite number of monkeys, checking to make sure they produce Shakespeare's work while clicking said links? Or do we create better and smarter pigeons? Well, it's actually a bit of everything, but not quite in the way you might think at first.
The people working in Test Engineering are software developers with a passion for testing and test automation. Whereas most software engineers at Google are working on developing products, Test Engineering's objective is to help improve the quality of the projects we're involved in. We work integrated with the project team, developing test frameworks and setting up test systems. One of our key mantras is automation, so our first task whenever we're assigned to a new project is to evaluate the current state of test automation, identify what we could do to improve the results obtained, reduce the total run time, and make the best use of available resources. Load and performance testing is another important task we perform, along with analysis of the results. We're also not afraid to get our hands dirty by diving deep into the project's code to identify what re-factoring might be useful to help test the system better, creating and introducing stubs, fakes and mocks as necessary. As you might guess, we're big fans of Test Driven Design, Continuous Integration and other agile techniques and play the role of evangelists, spreading the word on new tools, techniques and best practices.
Individual project assignments tend to be limited in duration, as we're a relatively small group of people in Test Engineering, helping support a much larger group of software developers. So once we've completed our tasks for one project, we move on to the next, working with a different team of people and a different set of problems, changing projects every few months.
That pretty much describes what I do, and how our team in Zurich works. So to answer the questions posed initially, I write software which performs the task of clicking every button and every link, and which then verifies the result of these actions. I run this on a few hundred machines to mimic virtual monkeys, and hand it over to the development team so that they can use it to check that their product is working, even after I've left their project. And if it produces the works of Shakespeare, that's just an added bonus! :-)
When I tell people that I'm a Test Engineer at Google, I get a confused look from them and questions as to what I actually do. Do I sit in front of a keyboard clicking every button and link on screen? Do I watch over the infinite number of monkeys, checking to make sure they produce Shakespeare's work while clicking said links? Or do we create better and smarter pigeons? Well, it's actually a bit of everything, but not quite in the way you might think at first.
The people working in Test Engineering are software developers with a passion for testing and test automation. Whereas most software engineers at Google are working on developing products, Test Engineering's objective is to help improve the quality of the projects we're involved in. We work integrated with the project team, developing test frameworks and setting up test systems. One of our key mantras is automation, so our first task whenever we're assigned to a new project is to evaluate the current state of test automation, identify what we could do to improve the results obtained, reduce the total run time, and make the best use of available resources. Load and performance testing is another important task we perform, along with analysis of the results. We're also not afraid to get our hands dirty by diving deep into the project's code to identify what re-factoring might be useful to help test the system better, creating and introducing stubs, fakes and mocks as necessary. As you might guess, we're big fans of Test Driven Design, Continuous Integration and other agile techniques and play the role of evangelists, spreading the word on new tools, techniques and best practices.
Individual project assignments tend to be limited in duration, as we're a relatively small group of people in Test Engineering, helping support a much larger group of software developers. So once we've completed our tasks for one project, we move on to the next, working with a different team of people and a different set of problems, changing projects every few months.
That pretty much describes what I do, and how our team in Zurich works. So to answer the questions posed initially, I write software which performs the task of clicking every button and every link, and which then verifies the result of these actions. I run this on a few hundred machines to mimic virtual monkeys, and hand it over to the development team so that they can use it to check that their product is working, even after I've left their project. And if it produces the works of Shakespeare, that's just an added bonus! :-)
This comment has been removed by the author.
ReplyDeleteThanks ! this is pretty informative road map for Test engineering.
ReplyDeletei have a question ( silly one may be )
How do testing teams and dev guys interact ? Do they sit in same floor ? Or its better they interact using defect tracking tool ?
Though i am in embeded wireless domain where margin for diffrence of opnion is less, my project teams end up on issue with
not a bug , limitation, invalid req, this not right way to test, customer setup may be wrong, etc etc..( kind of diffrence opnion )and thus compromising on ideas. ( inspite of better process defined for the same :( ).
How is it at your place ?
why is this link here ? not good colour ? is not fitting window size ? wrong content ?
you guys have any mechanisam to help with this ? flood some light.
Thanks
kiran :)
Congratuation for your post!
ReplyDeleteYou wrote very well what is the activity of a test engineer.
Here in Brazil I also have this difficulty to explain my activities for staff!
Regards!
Nice Post!
ReplyDeletePeople many times, have no clue of what actually test engeniering means in terms of activities.
But the role of a test engenieer is far beyond that! definetlly!
Thanks, for sharing your thoughts on the role of a tester
Does everyone see the test engineer as the sole person on the testing team?
ReplyDeleteDo you see a testing team made up of 50% test engineers and 50% regular testers or are those the old days.
I feel all people responsible for validating system specs and finding defects should be as this post defined test engineers.
I write software which performs the task of clicking every button and every link, and which then verifies the result of these actions
ReplyDeletePerforming VERIFICATION for a search engine or any processing system whose results are not static involves great intelligence on the test automation side. Automation is one thing - writing automation to verify a dynamic system is much more complex. It seems like this would entail fuzzy logic, historical benchmark comparisons, variance / relevance score testing, etc. How do you guys do this? :)
So what does a Test Engineer do as opposed to a software engineer in Test.
ReplyDelete