Today’s software testing environment has changed. A common trend we are seeing these days is
advertisements for software developers and testers that look virtually the same. Today, companies
all seem to require software test professionals with in-depth knowledge of programming languages
and with significant database skills. Testers are constantly striving to keep up with the knowledge
required to be effective on the complex projects we encounter regularly.
A test engineer is expected to know at least a little about practically everything—from operating
systems to networks to databases—in order to find bugs and report them articulately. What we
always say to new testers is that this is a great profession for those of us who love to learn
continuously. It’s like you’ve never left college—you must study constantly. (Of course, that
also makes it a great profession if you like to feel constantly inadequate! Because you can never
know enough, can you?) So, this book is for that self-motivated test engineer who is intent on
continually upgrading his or her knowledge and now wants to learn more about automated
software testing using .NET.
We have also targeted this book toward nonprogramming computer professionals, such as
those of you in Networking and IT professions. You are technical, but want to know more about
programming in .NET in order to enhance your skills. The additional information about testing
will only help to guide you in ways to uncover and deal with problems in systems.
Finally, this book is also for you test leads and managers who want to know what .NET can
do for your test project. A not-so-well-kept secret of automated software testing is that the major
tools available commercially don’t do everything you need them to do, in spite of their advertisements.
It’s probably unrealistic to expect any tool to be able to fully support the automated
testing required for so many diverse applications. This includes the additional new Team Test
software added into Visual Studio’s Team Edition software (see Chapter 11). This revolutionary
new software will be a fabulous resource for mid- to large-size companies, but it is still not
going to eliminate the need for testers to become more technically adept.
This is not to say that writing your own tools is always the right answer. However, supplementing
automated tools with some scripting done by testers fluent in a traditional language
can help a company get more out of its automated testing projects. It is our hope, in these
pages, to help you see how you can do just that.