Re: [Wikitech-l] interesting read: testing@LinkedIn
Hey Brian, Things seem to be trending up at WMF, especially w/ the Web engineers' big strides in end-to-end testing. However, as the article suggests, you need to attack the quality problem from both ends—perhaps even emphasizing unit tests (shortest feedback, cheapest, least fragile). Completely agree. Just wanted to point out that we're not focusing solely on browser tests, but trying to make them more stable and useful for our daily usage. That's why you may be seeing browser testing conversations and noise around, because right now they are far from being useful and stable for what they are and what we do. You'll see more convos regarding exposing unit coverage and stricter testing among developers in the following months. --- It was an interesting article, keeping in mind that there are no universal laws, and it all depends on tradeoffs. Articles like this could certainly help management people understand the importance of the different types of testing. Thanks for sharing. On Fri, Jun 19, 2015 at 3:55 PM, Brian Gerstle bgers...@wikimedia.org wrote: Short case study at LinkedIn [0] http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality about how they cut release latencies by 80-90% by reversing the ice cream cone of death [1] http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png : There's one particular snippet that strongly resonates with what I've experienced at multiple jobs (emphasis mine): *Team ownership of quality* Quality is the responsibility of the *whole team*. Quality control is most efficiently achieved if software quality is considered at *every step in the development cycle*. A software quality process will benefit from an appropriate distribution of test automation ownership between teams cooperating in a software development effort. In other words: QA aren't the only ones responsible for tests. I would go a step (or several) further and explicitly suggest that testing needs to be considered at—or an integral part of—the design planning processes. Rich Hickey goes even further in his talk about Hammock Driven Development https://www.youtube.com/watch?v=f84n5oFoZBc (highly recommended: TL;DR; people start work before fully understanding the problem space). Things seem to be trending up at WMF, especially w/ the Web engineers' big strides in end-to-end testing. However, as the article suggests, you need to attack the quality problem from both ends—perhaps even emphasizing unit tests (shortest feedback, cheapest, least fragile). 0: http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality 1: http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png, thanks to Zeljko for introducing me to that fun term, much better than upside-down pyramid -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] interesting read: testing@LinkedIn
Short case study at LinkedIn [0] http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality about how they cut release latencies by 80-90% by reversing the ice cream cone of death [1] http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png: There's one particular snippet that strongly resonates with what I've experienced at multiple jobs (emphasis mine): *Team ownership of quality* Quality is the responsibility of the *whole team*. Quality control is most efficiently achieved if software quality is considered at *every step in the development cycle*. A software quality process will benefit from an appropriate distribution of test automation ownership between teams cooperating in a software development effort. In other words: QA aren't the only ones responsible for tests. I would go a step (or several) further and explicitly suggest that testing needs to be considered at—or an integral part of—the design planning processes. Rich Hickey goes even further in his talk about Hammock Driven Development https://www.youtube.com/watch?v=f84n5oFoZBc (highly recommended: TL;DR; people start work before fully understanding the problem space). Things seem to be trending up at WMF, especially w/ the Web engineers' big strides in end-to-end testing. However, as the article suggests, you need to attack the quality problem from both ends—perhaps even emphasizing unit tests (shortest feedback, cheapest, least fragile). 0: http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality 1: http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png, thanks to Zeljko for introducing me to that fun term, much better than upside-down pyramid -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] interesting read: testing@LinkedIn
Thanks for sharing this, Brian! x-posting to teampractices On Fri, Jun 19, 2015 at 6:55 AM, Brian Gerstle bgers...@wikimedia.org wrote: Short case study at LinkedIn [0] http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality about how they cut release latencies by 80-90% by reversing the ice cream cone of death [1] http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png : There's one particular snippet that strongly resonates with what I've experienced at multiple jobs (emphasis mine): *Team ownership of quality* Quality is the responsibility of the *whole team*. Quality control is most efficiently achieved if software quality is considered at *every step in the development cycle*. A software quality process will benefit from an appropriate distribution of test automation ownership between teams cooperating in a software development effort. In other words: QA aren't the only ones responsible for tests. I would go a step (or several) further and explicitly suggest that testing needs to be considered at—or an integral part of—the design planning processes. Rich Hickey goes even further in his talk about Hammock Driven Development https://www.youtube.com/watch?v=f84n5oFoZBc (highly recommended: TL;DR; people start work before fully understanding the problem space). Things seem to be trending up at WMF, especially w/ the Web engineers' big strides in end-to-end testing. However, as the article suggests, you need to attack the quality problem from both ends—perhaps even emphasizing unit tests (shortest feedback, cheapest, least fragile). 0: http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality 1: http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png, thanks to Zeljko for introducing me to that fun term, much better than upside-down pyramid -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
