Lessons Learned in Software Testing - page 65

Summary

This chapter showed you how having access to the software's source code while the program is running can open up a whole new area of software testing. Dynamic white-box testing is a very powerful approach that can greatly reduce your test work by giving you "inside" information about what to test. By knowing the details of the code, you can eliminate redundant test cases and add test cases for areas you didn't initially consider. Either way, you can greatly improve your testing effectiveness.

Chapters 4 through 7 covered the fundamentals of software testing:

Static black-box testing involves examining the specification and looking for problems before they get written into the software.
Dynamic black-box testing involves testing the software without knowing how it works.
Static white-box testing involves examining the details of the written code through formal reviews and inspections.
Dynamic white-box testing involves testing the software when you can see how it works and basing your tests on that information.

In a sense, this is all there is to software testing. Of course, reading about it in four chapters and putting it into practice are very different things. Being a good software tester requires lots of dedication and hard work. It takes practice and experience to know when and how to best apply these fundamental techniques.

In Part III, "Applying Your Testing Skills," you'll learn about different types of software testing and how you can apply the skills from your "black and white testing box" to real-world scenarios.

Quiz

These quiz questions are provided for your further understanding. See Appendix A, "Answers to Quiz Questions," for the answersbut don't peek!

1:	Why does knowing how the software works influence how and what you should test?
2:	What's the difference between dynamic white-box testing and debugging?
3:	What are two reasons that testing in a big-bang software development model is nearly impossible ? How can these be addressed?
4:	True or False: If your product development is in a hurry, you can skip module testing and proceed directly to integration testing.
5:	What's the difference between a test stub and a test driver?
6:	True or False: Always design your black-box test cases first.
7:	Of the three code coverage measures described, which one is the best? Why?
8:	What's the biggest problem of white-box testing, either static or dynamic?

Part III: Applying Your Testing Skills

For my birthday I got a humidifier and a dehumidifier… I put them in the same room and let them fight it out.

Steven Wright, comedian

Discovery consists of looking at the same thing as everyone else does and thinking something different.

Albert Szent-Gyorgyi, 1937 Nobel Prize winner in physiology and medicine

IN THIS PART

8 Configuration Testing

9 Compatibility Testing

10 Foreign-Language Testing

11 Usability Testing

12 Testing the Documentation

13 Testing for Software Security

14 Website Testing

Chapter 8. Configuration Testing

IN THIS CHAPTER

An Overview of Configuration Testing
Approaching the Task
Obtaining the Hardware
Identifying Hardware Standards
Configuration Testing Other Hardware

Life could be so simple. All computer hardware could be identical. All software could be written by the same company. There wouldn't be confusing option buttons to click or check boxes to check. Everything would interface perfectly the first time, every time. How boring.

In the real world, 50,000-square- foot computer superstores are offering PCs, printers, monitors , network cards, modems, scanners , digital cameras , peripherals, net-cams, and hundreds of other computer doodads from thousands of companiesall able to connect to your PC!

If you're just getting started at software testing, one of your first tasks may be configuration testing. You'll be making sure that your software works with as many different hardware combinations as possible. If you're not testing software for a popular hardware platform such as a PC or a Macthat is, if you're testing some specialized proprietary systemyou will still need to consider configuration issues. You can easily tailor what you learn in this chapter to your situation.

The first part of this chapter deals with the generalities of PC configuration testing and then moves into the specifics of testing printers, display adapters (video cards), and sound cards for a PC. Although the examples are based on desktop computers, you can extrapolate the methods to just about any type of configuration test problem. New and different devices are released every day, and it will be your job to figure out how to test them.

Highlights of this chapter include