I spent the bulk of the week at STAR, where unlike my Microsoft colleagues, I had the most personal history. If you don’t know it, STAR is the major semiannual testing conference in North America. I’d attended and spoken there perhaps ten times previously, but not in the last four years. I came with a fantasy that, like Rip Van Winkle returning to town, I would see signs of a revolution while I was away. There were lots of talks about different testing techniques or measurements, but very little new. People are still speaking in single dimensions – do exploratory testing or test against requirements or test against code or drive tests from keywords or model requirements to create tests or apply attack patterns or test against risks or use these metrics or automate your testing or … It’s amazing to me that in such a small field there can be so many silos, because there really isn’t enough grain for them all to store.
All of these ors really should be ands. I made a point in my talk, as I do in the book, about the need for multidimensional descriptive metrics and diverse techniques applied together. It’s about requirements, code, risks, fault models, qualities of service, data, configurations, and discovery. They’re all relevant and complementary. The most memorable talk I ever heard at STAR before was Cem Kaner’s Paradigms of black box software testing. Cem surveyed all of these silos as separate paradigms and postulated, along the lines of Thomas Kuhn’s Structure of Scientific Revolutions, that the paradigm diversity was a indicator of a unifying revolution to come. Unfortunately for my fantasy, at this STAR, George III was still on the road sign.
(Now I’ll stretch the metaphor to the breaking point.) If you’re also waiting for the revolution and are interested in the continental congress, you might be interested in joining our “Enterprise IT 9-to-5” program. Somasegar, my divisional VP, recently blogged about it here. The goal of the program is to understand our IT customers’ needs at a much deeper level than can be typically achieved with our current programs. It is also about taking what we learn back to our product teams in rich detail to help them think more deeply about our customers’ diversity of contexts, needs, and goals when considering the direction we take our products.
In the 9-5 program, 4-5 key members of our product teams ask to spend 2-3 days on a customer site during normal working hours. The team is led by one of our Product Unit Managers. All the team members are highly influential in defining functionality of our lifecycle tools.
This is a unique opportunity to influence the future of Microsoft’s products to support the software lifecycle. Your teams’ processes, problems, work styles, and needs become reference examples that inform Microsoft’s lifecycle products when making a broad range of decisions. We firmly believe that with a strong understanding of both your broad as well as your day-to-day needs we can positively improve the utility our tools will have on your software lifecycle. If you’re interested in participating, please reply to me and I’ll connect you to the team privately. Thanks!