A response to the IEEE article: Yahoo’s Engineers Move to Coding Without a Net

http://dilbert.com/strip/1996-07-01

link to the article

First, a disclaimer

Let me start out with the understanding that the article as written is being interpreted through the writer’s own biases and background. I certainly have been misquoted or had a radically different interpretation of my words by an author than was meant.

This is a response to the article as written. I would be happy for someone from Yahoo to let me know if they feel the article was an accurate depiction or not.

Yahoo’s new approach to quality is something many other companies already do

What yahoo learned is what many other companies have learned a long time ago. That segmenting test and development is a bad idea. It leads to developers and testers living in their own silos and playing a blame game on each other. Agile methodologies challenged this idea 16 years ago. Having separate test and development teams is a pretty big red flag for waterfall development.

It wasn’t the fact that there were QA that was the problem

Taking away QA can improve quality to a point because it makes quality everyone’s job, but it won’t get you a high-quality product. You could do that by creating a culture of quality, making everyone feel responsible for quality and keeping the QAs on the teams. You can’t find every bug in the product through test automation. Developers tend to be poor testers of their own code, because they expect it to work and they have a hard time using the product like a non-developer. Having someone on the team with an expertise in quality thinking and a user mindset can do real wonders for product quality.

What Yahoo should try next in their quality evolution

Yahoo could also have increased quality and velocity substantially by keeping the QA, integrating the teams of developers and testers and by creating a culture where everyone feels responsible for the quality of the product. I contend that in their evolution they might yet find another factor increase in these by doing exactly that.

Nice discussion of white box and developer-driven testing in Google Chrome comic book

I debated copying the scans from blogoscoped.com or referencing the images here, but I decided instead to refer you to the appropriate pages to be a good blog citizen.

Getting Scott McCloud to write a comic book announcing your product is a great idea. He did a great job distilling some complicated stuff into a very accessible piece. Tons of people will talk about the Google Chrome announcement and what it means for Microsoft and about using multiple processes for tabs.

One of the things that struck me though, was the nice discussion of white box automated testing. Also, a very simple and concise description of developer-driven testing. I am a huge proponent of these principles since I first worked on an XP project 8 years ago and became an XP coach. Every project I’ve worked on since has had a large test-driven development component and hard-core whitebox QEs (when I’ve had the resources). Doing automated stress testing on a browser is a no-brainer. Internet Explorer has been doing it forever. Google isn’t doing anything new or different here: fuzzing inputs isn’t new, and neither is reducing the test space to make automation run faster and results relevant for users. However, McCloud’s comic does a great job of explaining these ideas in a very simple manner. It’s a great tool for developers, QEs or engineering managers trying to explain why these things are important to others in their organization.

Check it out on pages 9, 10, and 11 of the Google Chrome comic book.