Preface

On this page:	Download:
The team who brought you this guide

Testing has always been the less glamorous sister to software development, scarcely noticed outside the software business, and the butt of complaints inside. If some small error is missed, testing is to blame; if time is running short or costs are getting too high, testing is liable to be starved of resources.

Testing certainly is expensive and time consuming. A project might easily spend 50% more on testing than on coding. Managers will quite reasonably ask whether the smallest update in the code really means that we must yet again configure all the machinery, call in the test team, search the office for the test plan, and work through a full suite of tests.

Back in the old days, testing came at the end of development, when the application's components were finally glued together. But that wasn't the end of the project, because a great many bugs would be found and there would then ensue a long period of repair, euphemistically called "stabilization." The end product of this process would be a full complement of last-minute patches and inconsistencies, and therefore difficult to update in the future.

Over the past decade or so, the software industry has been gradually learning to develop and test incrementally, integrating and testing continuously, and taking frequent feedback from customers. The applications that result from these agile processes are much more likely to satisfy their users.

But testing is still too often a huge, unwieldy process that acts as a roadblock, slowing the development cycle and limiting a development team's ability to respond to customer demands.

Today's software producers cannot afford such overhead. Web applications typically serve millions of people, and continuous bug-free operation is critical to customer satisfaction. These apps have to be updated frequently to keep up with shifting business needs, and at the same time have to maintain maximum up time for the health of the business. With so much riding on properly functioning and agile web apps, a faster develop, test, and deploy cycle is crucial.

In these modern applications, organizations cannot afford to implement long painful testing processes every time a feature needs tweaking or a line of code must change. That's why we wrote this book.

Fortunately, the continuous testing required today need not be as cumbersome as it was in the past. If you perform application lifecycle management using the Microsoft tools based on Visual Studio, the testing piece of your development puzzle will be less painful, time consuming, and expensive than it had always been. This combination of tools helps you automate testing, helps you track and record the process and results of testing, and helps you easily repeat that testing whenever you need to.

The key to this improved testing process is integration. Integrated tools mean that your test plan is a living and executable document that links directly to your tests. It means that you can take snapshots of your testing environment configuration for storage and later use and to memorialize the exact state of a system when a flaw was discovered. You can record tests for later playback and reuse—while you are performing a manual test, you can record the steps which will automatically play back next time you need to kick the tires on that app.

The first software systems wouldn't cause bodily injury if they made mistakes. But as computers found their way into cars, aircraft, hospital equipment, power stations, and factories, their destructive potential rose. Lives were on the line. The fault tolerance demanded by these applications soon became desirable in everyday applications. Many businesses today want or need such reliable outcomes, but they don't have the time or resources that the testing of old required.

It's a different world today in software development. We truly do operate on Internet time. The audience for our applications is huge, they're worldwide, and they don't sleep and allow us to roll out updates overnight. They click by the thousands and tens of thousands simultaneously, and they expect speed, availability, and precision. Today the business that can achieve 99.999 percent uptime, roll out updates continuously, and fix errors as soon as they are discovered will come out on top.

Fortunately, this set of tools, integrated so well with Visual Studio, will help you achieve that rapid fix-and-deploy goal and help keep you competitive. The team that brings you this book hopes, and feels confident that you will make better use of resources and have a much smoother test and release process. You just need to understand how application lifecycle management works in Visual Studio and begin testing the waters.

There are several other excellent books about software testing in Visual Studio, listed in the Bibliography. This book provides a slightly different perspective, in the following respects:

• This is about how to use the Visual Studio tools effectively as a tester to deal with your product's entire lifecycle. In fact, our suite of lifecycle management tools includes Visual Studio, Microsoft Test Manager, and Team Foundation Server. If your job is to perform end-to-end tests of a complex system, this is one of the most powerful sets of integrated tools you can get. We'll show you how to use it not just to verify the basic functionality, but also to layer your test plans over multiple quality gates to achieve high fault tolerance.
• We think you'll take on this lifecycle management one piece at a time. That's normal. You probably already have some testing tools. It takes time to learn new tools, and even longer for the team to agree how to use them. Fortunately, you don't have to implement all of our advice all in one big bite. We've structured the book along the adoption path we suggest so as to make it easier to adopt it piece by piece.
• ALM—application lifecycle management—is changing. Increasingly, we're writing applications for the cloud. We need to publish updates every few weeks, not every few years. Applications aren't limited to the desktop anymore; a typical requirement might be implemented by an app on your phone and several collaborating servers on the web. Fault tolerance is a critical issue for 24x7 operations. It is no longer acceptable to leave system testing to the end of the project; testing needs to happen continuously. We'll show you how to use the methodology in this book to make this work.
• We describe how to set up and configure the machinery for testing. If your job is to administer Visual Studio, lifecycle management, and its testing tools, the Appendix is for you.
• We try to show you how to drive, not just operate the controls. The bibliography at the end includes some very good books and websites on topics like unit testing, test-driven development, model-driven testing, exploratory testing, and so on. We can't cover all that in this book, but we do take some of the most valuable patterns and show how you can use them to good effect.

We'll assume you have done some testing, or maybe a lot. You might be a test lead, or a developer on a team where developers also test, or a specialist tester. There are a few sections where you'll find it easier if you're the sort of tester who also writes some code; but that's not an essential prerequisite.

Testing is a highly skilled job. In addition to the constructive creativity of coding, it requires an intuition and depth of understanding that can find just those cases that will either find a bug or provide the confidence that the application works for many neighboring cases. It requires the application of many different techniques and categories of test, such as functional, load, stress, and security testing.

Like any job, there are also less skilled and more tedious parts—setting up machines, retesting the same feature you tested last week and the week before. It's these aspects that we hope you'll be able to mitigate by using our tools.

If you test software, you're the guardian of quality for your product. You're the one who makes sure it satisfies the customers. From that point of view, you're the real hero of the development team.

Unfortunately, we can't make software testing sound any more glamorous outside the industry. Bear this in mind when introducing yourself at social occasions. And if you have any good tips for that scenario, we'd love to hear from you.

The team who brought you this guide

Larry Braderconceived, motivated, and led the creation of this book. "I have been testing for a long time."

Chris Burns drew the technical illustrations.

Paul Carew drew the cartoons. He is a graphic designer who has worked for Microsoft and other major software companies in the Seattle, Washington area.

RoAnn Corbisier is a senior technical editor in Microsoft's Developer User Education team.

Nelly Delgado is our production editor.

Howard F. Hilliker wrote Chapter 6 and a lot of the testing content in the MSDN library, and provided support throughout. He has probably been Microsoft's tallest programmer and writer for fourteen years. "It's good to be writing a flowing storyline as opposed to reference pages."

Poornimma Kaliappan created the sample projects and logged the testing activities on which we based the examples in the book. "I have been a software development engineer in test with Microsoft for several years. This book has been an enjoyable trip."

Nancy Michell edited the text and kept us coherent.

Alan Cameron Wills devised the cartoons and wrote most of the words, including some brilliantly funny bits that were edited out.

We had a panel of expert reviewers who saved us from a number of embarrassing pitfalls. Thanks to Tim Elhajj (Microsoft Corporation), Katrina Lyon-Smith (Microsoft Corporation), Willy-Peter Schaub (Microsoft Corporation), Anutthara Bharadwaj (Microsoft Corporation), Muthukumaran Kasiviswanathan (Microsoft Corporation), Tiago Pascoal (Agilior) , Paulo Morgado (Individual), Debra Forsyth (Object Sharp), Carlos dos Santos (CDS Informática Ltda.), Richard Hundhausen (Accentient), Paul Glavich (Saaus.com) , Mike Douglas (Deliveron) , Jacob Barna (Blue Cross and Blue Shield of Nebraska) and Marcelo Hideaki Azuma (ITGroup).

Thanks to Katie Niemer who invented our principal cartoon characters.

Thanks to Hans Bjordahl for the cartoon at the end. It's from his wonderful strip about life on a development team. See http://www.bugbash.net. Make sure you've got an hour or two to spare, and then click the "First" arrow when you get there.

Finally, thanks are due to the development team of Microsoft Test Manager, who created a wonderfully effective and well-integrated testing toolkit.

Next Topic | Previous Topic | Home | Community

Last built: Aug 6, 2012