Testing, once a marginalized function at Google, is now an integral part of Google’s innovation machine. Patrick Copeland describes how this vital transformation took place. As he was analyzing how to be more efficient and better align his testing team with the needs of the company, Patrick realized they had to move beyond “just testing” and become a force for change. His approach was based on five powerful principles: (1) Building feature factories rather than products, (2) Embedding testing at the grass roots level, (3) Solving problems of scale with technology, (4) Automating at the right level of abstraction, (5) Only doing what the team can do well. Learn how Google test teams used these principles to shift from a “service group” composed predominantly of exploratory testers to an “engineering group” with technical skills. Their focus became “delivering innovation” rather than “testing product.” Learn how Patrick led a cultural shift where product teams saw testing and continuous improvement, not as alien concepts driven by someone else, but as a tool for them to meet their own goals of delivering features quickly and with fewer problems. Discover how you can incorporate the lessons of Google to make your test team a vital force for change.
When is GTAC going to be announced for this year?!
Will the keynote eventually be available online for viewing? Sounds like a fascinating topic.
(1) Building feature factories rather than products, Very interesting line - from the perspective of testing this implies having a set of definite tests for every feature and being able to run the tests and produce reports, systematically(2) Embedding testing at the grass roots level, Test design, test code and test the system - fantastic if we can do this(3) Solving problems of scale with technology, This and the next seem to be sayin the same thing - using technology to automate (4) Automating at the right level of abstraction, Exactly - don't automate tests that are for the rare scenarios - the abstraction will take care of the rare sceanrios(5) Only doing what the team can do well.Well I didn't get that - do what is required and if the team is not good at it now, then improve the team's capacity.Hey, looking forward to more details on the topics listed - seems like quality (testing) will be built into the product.This starts another line - design for testability - where the architecture of the product allows automated tests to be run.
Yes you should provide keynote in some format for the readers of this blog.Prerna
The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.