Thanks for sharing information about how the TEs add value to Google products. This is the post I have been waiting since you started this series about how Google tests software.
I am trying to build a team of software quality assurance people and the skills set of a Google's TE is what I am looking for in the people I hire. However, at least here in Brazil, this is something REALLY hard to find. The market is full of "classic style" testers though.(By classic style tester I meant people who are more comfortable with writing and manually running long test scripts, that will be out of date as soon as the product is released).
Does Google also face any kind of issue when hiring TEs? Any hints for me?
Does this mean that TEs change projects more usually than SETs? [since they should go through different projects at later parts of the development lifecycle] this seems a better title for an SDET more focused on E2E testing.
Love your post! I'm surprised to see "many of the top test managers in the company come from the TE ranks". I thought Google's management were dominated by developers.
@Weining: At Google, testers report to testers, not to developers.
@Bruno: I don't have any data on job changes by title but my suspicion is that it is *easier* for TEs to change projects because they serve the users and not the code base.
Great and very informative post, James. I also have got your book on Exploratory Testing and enjoyed it. It must be cool to work with folks like you and learn at the feet of the masters, so to speak.
Nice read. I always have leaned towards/pitched for getting folks like TE's involved earlier as then they have higher chances of influencing functionality or feature set, and taking a swipe at the broader big picture problems - like interop with other products. (I would imagine that would lie outside the charter of SWT's?) If they come in later when a large part of the spec and usability has been baked in, aren't we really limiting their chances of success and if there is any impact unearthed by them, further risking release schedule?
Thoughts?
Regardless, Loved how you laid down the fluidity of the role of a TE and the leadership aspect! It is something very fundamental for a good TE to stand up and effect change where needed! TE's who are customer advocates are priceless!
Generally the test engineers with extensive experience and broad perspective like TEs leave the test execution, and dedicated themselves to the test management. But such a career path, in some cases, narrow their perspective and dull their intuition.
It seems that TEs activities include leading to a better place products and services. These activities may strongly dependent on individual ability and experience. For global products and services, It may be necessary to support to their activities by some systems.
I am pleased to read that the Google Test Engineering department is once again appreciating the value of having Test Engineers on their projects. As one of the original group of Test Engineers at Google, I understand the value that a great exploratory tester with creativity, curiosity and good communication skills can add to the success of a project's deployment. You can run automation all day long and of course you will find issues and bugs in the code, but it takes a person to find those edge cases or issues that the actual end user might find. Ultimately we want the user to be happy and not frustrated with the product. Having a Test Engineer give it a once-over, based on extensive knowledge of testing techniques and how to exercise the code in ways that the developer never intended, is the best way to assure the success of the product for Google or any other company.
Thanks for the update. I am so happy to hear that google has introduced the TE role. Please post the information on eligible criteria to apply for the TE position in google. I am working as TE in a software firm.
Amazing article, it seems that here at Directi, India we also believe in more or less similar strategy. The TE's involve in later phases and analyse the break-points before shipment of a product.
What I wonder is that you refer to Exploratory testing with "exploratory testing with little to no planning". This confuses me as in exploratory approach the testing IS planned, but made less rigid and more reactive. Do you have exploratory experts as TEs? Do all TEs do exploratory testing? Do they do it RIGHT (according to your specification of Exploratory testing something is wrong)? But nonetheless fachinating to see the aspects of TE's jobs you have at Google. We are doing the same role clarification in our company so this is very enlightning.
That's a nice piece of information and guidance for the TE, helping TE to examine his much needed skills and to incorporate if missing some.
SvarSletton the similar lines there could be 'DE' development engineers.
SvarSlettHi James,
SvarSlettThanks for sharing information about how the TEs add value to Google products. This is the post I have been waiting since you started this series about how Google tests software.
I am trying to build a team of software quality assurance people and the skills set of a Google's TE is what I am looking for in the people I hire. However, at least here in Brazil, this is something REALLY hard to find. The market is full of "classic style" testers though.(By classic style tester I meant people who are more comfortable with writing and manually running long test scripts, that will be out of date as soon as the product is released).
Does Google also face any kind of issue when hiring TEs? Any hints for me?
Thanks again!
Great post James!
SvarSlettDoes this mean that TEs change projects more usually than SETs? [since they should go through different projects at later parts of the development lifecycle] this seems a better title for an SDET more focused on E2E testing.
Keep the posts comming!
Love your post! I'm surprised to see "many of the top test managers in the company come from the TE ranks". I thought Google's management were dominated by developers.
SvarSlett@Weining: At Google, testers report to testers, not to developers.
SvarSlett@Bruno: I don't have any data on job changes by title but my suspicion is that it is *easier* for TEs to change projects because they serve the users and not the code base.
Great and very informative post, James. I also have got your book on Exploratory Testing and enjoyed it. It must be cool to work with folks like you and learn at the feet of the masters, so to speak.
SvarSlettNice read. I always have leaned towards/pitched for getting folks like TE's involved earlier as then they have higher chances of influencing functionality or feature set, and taking a swipe at the broader big picture problems - like interop with other products. (I would imagine that would lie outside the charter of SWT's?) If they come in later when a large part of the spec and usability has been baked in, aren't we really limiting their chances of success and if there is any impact unearthed by them, further risking release schedule?
SvarSlettThoughts?
Regardless, Loved how you laid down the fluidity of the role of a TE and the leadership aspect! It is something very fundamental for a good TE to stand up and effect change where needed! TE's who are customer advocates are priceless!
Hey James,
SvarSlettAwaiting your post on SETs - the continuation of part 6.
Thanks,
Raghav.
Thank you for your always great posts.
SvarSlettGenerally the test engineers with extensive experience and broad perspective like TEs
leave the test execution, and dedicated themselves to the test management.
But such a career path, in some cases, narrow their perspective and dull their intuition.
It seems that TEs activities include leading to a better place products and services.
These activities may strongly dependent on individual ability and experience.
For global products and services, It may be necessary to support to their activities by some systems.
I am pleased to read that the Google Test Engineering department is once again appreciating the value of having Test Engineers on their projects. As one of the original group of Test Engineers at Google, I understand the value that a great exploratory tester with creativity, curiosity and good communication skills can add to the success of a project's deployment. You can run automation all day long and of course you will find issues and bugs in the code, but it takes a person to find those edge cases or issues that the actual end user might find. Ultimately we want the user to be happy and not frustrated with the product. Having a Test Engineer give it a once-over, based on extensive knowledge of testing techniques and how to exercise the code in ways that the developer never intended, is the best way to assure the success of the product for Google or any other company.
SvarSlettThank you for the "tutorial", it was very useful :)
SvarSlettThanks for the update.
SvarSlettI am so happy to hear that google has introduced the TE role.
Please post the information on eligible criteria to apply for the TE position in google.
I am working as TE in a software firm.
Amazing article, it seems that here at Directi, India we also believe in more or less similar strategy. The TE's involve in later phases and analyse the break-points before shipment of a product.
SvarSlettHi, James!
SvarSlettWhat I wonder is that you refer to Exploratory testing with "exploratory testing with little to no planning". This confuses me as in exploratory approach the testing IS planned, but made less rigid and more reactive. Do you have exploratory experts as TEs? Do all TEs do exploratory testing? Do they do it RIGHT (according to your specification of Exploratory testing something is wrong)? But nonetheless fachinating to see the aspects of TE's jobs you have at Google. We are doing the same role clarification in our company so this is very enlightning.
BR, Pekka
Thanks James for sharing the series. One question - how do you generally plan the swe:set:te ratio when forming a team? Is there some thumb rule?
SvarSlett