Book:
| | | |  | | How We Test Software at Microsoft
| Author: Alan Page, et al. | | Pages: 405 | Published: 2008 | | Publisher: Microsoft Press | ISBN: 0735624259 | 
     |   Click to Buy | | | | |
|
|
| | | | Topics: Defect Tracking
| | Description:
Discover how Microsoft implements and manages the software-testing process company-wide with guidance and insights direct from its test managers. Organizing any testing program the people, processes, and tools can be challenging and resource intensive. Even when the necessary tradeoffs are made, no development team can test every scenario. This book explains how a worldwide leader in software, services, and solutions staffed with 8,000 testers implements and manages its testing process effectively company-wide. Whether you re a tester or test manager, you'll gain expert insights on effective testing techniques and methodologies including pros and cons of various approaches. For interesting context, the book also shares such facts as the number of test machines at Microsoft, how the company uses automated test cases, and bug statistics. It answers key testing questions, such as who tests what, when, and with what tools. And it describes how test teams are organized, when and how testing gets automated, testing tools, and feedback with illuminating insights for software-development organizations of all kinds.
| | | | | Review by Debra Martinez Debra.martinez@coinstar.com
Back to Top
When I first started reading this book I thought it was going to be about how great it is to be a tester at Microsoft. Boy, was I wrong. This book has great information for the novice and expert tester. The most useful information I found was about structural testing techniques. This information is great for a company such as mine that needs more structure in the way we test. Don't get me wrong, all the information in the book is great. Also, the information on automated testing is valuable and would be great for a company already using or planning to use automation in their testing efforts.
This book has made its rounds in my testing department. There is not a day that goes by when I am not asked if I still have the book. I feel this book is great addition to any testing department. I was not real happy with all the references to Microsoft being the best place to work as a tester, but the information was good nonetheless. I just wish the author would have realized that the rest of us testers are just as proud of where we work.
The author does great job explaining how the bug matrix is a bad idea for any company. The author's main point is that a developer can move the bugs around and make it look like he doesn't have much on his plate, which is what happened at my company when we tired this.
We need more books like this one on the shelves of testers. The only problem I had with this book, like I said earlier, is that the author believes if you are a tester, then you need to work at Microsoft because it’s the only place on Earth you can become a real tester. Regardless, the author does a good job writing the material in a way that everyone can understand which helps one get the most out of the book. I expect to see this book on shelves for a very long time.
| | | Review by Harry Acosta acostah2@gmail.com
Back to Top
I absolutely love this book. It is a concise and detailed story about how Microsoft managed to become the biggest software engineering company and how they have embedded quality within all of their processes, especially with utmost concern for customer needs.
The first three chapters tell Microsoft's story about how they do software engineering. It also explains the differences in roles and responsibilities for each of the different positions involved in development and testing. The role of the Software Development Engineer and Test (SDET) is described as one of the most important positions involved in creating quality software, while, at the same time, minimizing testing effort. The author then goes on to discuss how the software development cycles work at Microsoft, with special attention to the iterative spiral model that is being used for all the different stages of software manufacturing, which we typically hear about in regards to customer-tested software from Microsoft (i.e., Alpha, Beta 1, Beta 2, Release Candidate 1, Release Candidate 2, Release To Manufacturing, etc.).
Chapters four through eight go into an intensive boot camp of software testing principles, with special emphasis on a practical test approach, model-based testing, and a roundup of structural testing techniques. Also explained is cyclomatic complexity analysis, another tool used to evaluate complex code, which creates practical, high-quality and value-adding testing.
Chapters nine through fourteen go over several tools that can be used to facilitate the software developer and tester job, such as non-functional testing and test automation tools. The way that Microsoft manages bugs found during testing is also mentioned. It serves as a statement to how serious Microsoft is on its intent to squash as many critical bugs as possible before shipping a product out of the door. Their commitment to quality software is indeed admirable.
Chapters fifteen and sixteen close with a vision of how Microsoft tries to predict future opportunities to solve problems and develop software accordingly.
Again, I absolutely love this book. It has filled a void that has been with me since I started implementing laboratory information systems in the pharmaceutical industry twenty years ago. Ever since I switched from chemistry to IT, I have been asking the QA departments at pharmaceutical companies whether they have audited Microsoft before implementing systems or processes based on their software. This is a genuine concern for pharmaceutical companies since part of the process of implement IT solutions in this industry—where you can leverage testing performed by the vendor—includes auditing the vendor to evaluate their quality system (processes and procedures to embed quality into their product). At first all I heard was Microsoft was not audited because their software was considered, by most, a black box and universally accepted.
Well, reading this book answered all the questions I ever had about Microsoft's quality system. Not only that, it also provided me with many examples I can use to help my current or future employer achieve CMM Level5. Project Management Institute's Capability Maturity Model Level 5 is to the Project Management discipline what ISO9001 is to ISO-certified companies, a structured set of procedures and processes to ensure products are developed or manufactured with a high degree of quality with the minimum amount of defects.
This book will be an excellent addition to the library of every tester and programmer that is interested in building quality software. Of special interest to me being an IS project manager with expertise mostly on laboratory systems implementation at the user level is the amount of advice in the book related to managing teams and ensuring the quality and quantity of testing is balanced against customer needs, timelines, and your budget.
I recommend this book to those readers who would like to help their software engineering companies enhance their quality system as well as pursue a higher level of software development and testing maturity.
|
| |
