Know Your Role: Software Testing Lessons From Google

One of the many “great debates” in the software industry is the role of testers in the development process. How soon should they be involved? What tasks should they be completing during the initial, middle and latter phases? Who should be responsible for designing data structures, reviewing code and writing test cases? The list goes on…

While there are technically no wrong answers to these questions, some hold more weight than others. For instance, you’d be much better off listening to advice from a company like Google, as opposed to Uncle Joe’s Discount Software Shack.

Lucky for you, Google Test Director James Whittaker tackles this subject in part II of his “How Google Tests Software” series. If you’re new  to the uTest Blog, James Whittaker is the distinguished author of several uTest blog posts, eBooks and webinars. You would be wise to listen to his advice.

Anyway, here are a few short excerpts from his latest article, addressing the various roles of those in the development process:

The SWE or Software Engineer is the traditional developer role. SWEs write functional code that ships to users. They create design documentation, design data structures and overall architecture and spend the vast majority of their time writing and reviewing code. SWEs write a lot of test code including test driven design, unit tests and, as we explain in future posts, participate in the construction of small, medium and large tests. SWEs own quality for everything they touch whether they wrote it, fixed it or modified it.

The SET or Software Engineer in Test is also a developer role except their focus is on testability. They review designs and look closely at code quality and risk. They refactor code to make it more testable. SETs write unit testing frameworks and automation. They are a partner in the SWE code base but are more concerned with increasing quality and test coverage than adding new features or increasing performance.

The TE or Test Engineer is the exact reverse of the SET. It is a a role that puts testing first and development second. Many Google TEs spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios and even mimics a user. They also organize the testing work of SWEs and SETs, interpret test results and drive test execution, particular in the late stages of a project as the push toward release intensifies. TEs are product experts, quality advisers and analyzers of risk.

What role do YOU think these positions should play in the testing process? Alternative ideas are encouraged.

2 Responses to “Know Your Role: Software Testing Lessons From Google”

  1. Cathy Holmmes said:

    Hello

    Surely software testing is exciting job. But what it needs time so you need judgment skills and patience to assess high-risk areas of an application on which to focus testing efforts when time is limited.

    Thank you for posting your timely views.

    Cathy

  2. Rams said:

    I agree to you Cathy… This is what we judge while hiring the people in our team. They should be patient and persistent

Leave a Reply