- Testing Axioms
- Software Testing Is a Risk-Based Exercise
- Testing Can't Show That Bugs Don't Exist
- The More Bugs You Find, the More Bugs There Are
- The Pesticide Paradox
- Not All the Bugs You Find Will Be Fixed
- When a Bug's a Bug Is Difficult to Say
- Product Specifications Are Never Final
- Software Testers Aren't the Most Popular Members of a Project Team
- Software Testing Is a Disciplined Technical Profession
- About This Article
Software Testing Is a Disciplined Technical Profession
It used to be that software testing was an afterthought. Software products were small and not very complicated. The number of people with computers using software was limited. And, the few programmers on a project team could take turns debugging each others' code. Bugs weren't that much of a problem. The ones that did occur were easily fixed without much cost or disruption. If software testers were used, they were frequently untrained and brought into the project late to do some "ad hoc banging on the code to see what they might find." Times have changed.
Look at the software help-wanted ads and you'll see numerous listings for software testers. The software industry has progressed to the point where professional software testers are mandatory. It's now too costly to build bad software.
To be fair, not every company is on board yet. Many computer game and small-time developers still use a fairly loose software development model—usually big-bang or code-and-fix. But most software is now developed with a disciplined approach that has software testers as core, vital members of their staff.
This is great news if you're interested in software testing. It can now be a career choice—a job that requires training and discipline, and allows for advancement.
|
Big-Bang Model One theory of the creation of the universe is the big-bang theory. It states that billions of years ago, the universe was created in a single huge explosion of nearly infinite energy. Everything that exists is the result of energy and matter lining up to produce this book, floppy disks, and Bill Gates. If the atoms didn't line up just right, these things might all be just quivering masses of goop. The big-bang model for software development shown in Figure B follows much the same principle. A huge amount of matter (people and money) is put together, a lot of energy is expended—often violently—and out comes the perfect software product…or it doesn't. The big-bang model is by far the simplest method of software development. The beauty of the big-bang method is that it's simple. There is little (if any) planning, scheduling, or formal development process. All the effort is spent developing the software and writing the code. It's an ideal process if the product requirements aren't well understood and the final release date is flexible. It's also important to have very flexible customers, too, because they won't know what they're getting until the very end. Notice that testing isn't shown in Figure B. In most cases, there is little to no formal testing done under the big-bang model. If testing does occur, it's squeezed in just before the product is released. It's a mystery why testing is sometimes inserted into this model, but it's probably to make everyone feel good that some testing was performed. If you are called in to test a product under the big-bang model, you have both an easy and a difficult task. Because the software is already complete, you have the perfect specification—the product itself. And, because it's impossible to go back and fix things that are broken, your job is really just to report what you find so the customers can be told about the problems. The downside is that, in the eyes of project management, the product is ready to go, so your work is holding up delivery to the customer. The longer you take to do your job and the more bugs you find, the more contentious the situation will become. Try to stay away from testing in this model. |
){kind=link}
Code-and-Fix Model The code-and-fix model shown in Figure C is usually the one that project teams fall into by default if they don't consciously attempt to use something else. It's a step up, procedurally, from the big-bang model, in that it at least requires some idea of what the product requirements are. The code-and-fix model repeats until someone gives up. A wise man once said, "There's never time to do it right, but there's always time to do it over." That pretty much sums up this model. A team using this approach usually starts with a rough idea of what they want, does some simple design, and then proceeds into a long repeating cycle of coding, testing, and fixing bugs. At some point they decide that enough is enough and release the product. As there's very little overhead for planning and documenting, a project team can show results immediately. For this reason, the code-and-fix model works very well for small projects intended to be created quickly and then thrown out shortly after they're done, such as prototypes and demos. Even so, code-and-fix has been used on many large and well-known software products. If your word processor or spreadsheet software has lots of little bugs or just doesn't seem quite finished, it was likely created with the code-and-fix model. Like the big-bang model, testing isn't specifically called out in the code-and-fix model but does play a significant role between the coding and the fixing. As a tester on a code-and-fix project, you need to be aware that you, along with the programmers, will be in a constant state of cycling. As often as every day you'll be given new or updated releases of the software and will set off to test it. You'll run your tests, report the bugs, and then get a new software release. You may not have finished testing the previous release when the new one arrives, and the new one may have new or changed features. Eventually, you'll get a chance to test most of the features, find fewer and fewer bugs, and then someone (or the schedule) will decide that it's time to release the product. You will most likely encounter the code-and-fix model during your work as a software tester. It's a good introduction to software development and will help you appreciate the more formal methods. |
){kind=link}