Geez, now I have to follow up David's awesomely funny entry about the food alias with my dry post on testing.

One of the first classes I took after starting here was called “Testing at Microsoft for New SDETs.” This class was full of about 25 people who had either just started with the company, or just started a new job as an SDET. (SDET here means “Software Development Engineer in Test) A good portion of the class was very applicable to what I would end up doing, although a lot of it was focused on Windows technology. Some of the more applicable parts related to test planning, test cases, and more of the theory of testing that applies to any platform you’re working on. During lunch I was talking to the instructor about what I would be working on, the MacBU, and how we might do things differently than the rest of the company. When I told him how big the team was, he was shocked. “How can you test with such a small group and ensure a quality release?”I told him, honestly, that I had no idea! I had just started, and I really didn’t know how we managed to do such a good job with the (seemingly) small group. After working here for a while longer and thinking about how we do things compared with other teams I’ve worked for, I’ve come up with a few thoughts on why our small team is successful.

Simplicity: Office (on both platforms) is sometimes referred to as “bloated” or “complicated.” While we do have a very complex feature set, I think that our program managers (the people that design features) have done a great job of keeping the product simple and straightforward. There are many areas that have the potential to be needlessly complex, and we’ve managed to keep things smart. This simplicity is not only the result of good testing and design, but it also serves to help testers own more areas completely, and leads to better...

Knowledge: Each person on the team knows their product very well, as well as the other products in the Office suite. When you have dozens of people testing an application, no individual person is necessarily going to look outside of their areas to see the big picture. I think understanding how features relate to, and interact with, each other helps us deliver much more consistent applications, something that is key for Mac users to accept them. When you have too many people working to ensure the quality of something, you lose sight of the fact that you’re not just delivering 100 individual things, you’re delivering a whole product. Individual testers and not just leads/managers knowing more about the product leads to better...

Prioritization: Anyone who works in software knows that not every feature gets finished, and not every bug gets fixed. If we waited for that to happen, we would never release a product. The fact that we know what needs to work, how it should work, and when it needs to be done lets us make much better decisions about where our priorities lie. This kind of prioritization happens in any product, but usually at a higher level. As a part of a small team, I feel like I have the ability to affect real change, and make a difference by speaking up about our products’ quality. Empowerment of "the little guy" leads to the most important factor in our success in the MacBU...

Passion: The people I work with are committed to the team and to the products. Very few people end up working in the MacBU because it’s an easier job than the rest of Microsoft or the quickest way up the corporate ladder. People are drawn to this group because they care about the product, enjoy working on the platform, and are committed to it. There is no substitute for a someone enjoying their job, it makes you much more productive and improves the entire process. So I guess to sum up why I think the MacBU is as efficient as we are: Knowledge of what you need to do, and your personal ownership of it makes for a very committed team that is able to accomplish things that would normally take a much larger group of people.

I hope I don't come off like some kind of management training handbook or motivational speaker. At least I didn't arrange those into a cheesy acronym! The new Joe LeBlanc SKPP small team testing methodology!@# :rolleyes: I'm just making an outsider's first impression of how things work around here, and why I think we're as good as we are.

Have a great weekend!