If you’re a software tester who’s been in the field for a few years, you may have found yourself in one of
the following situations:
- You’re working as hard as you can to find bugs in a huge system and you can’t get to everything within the deadline. You’ve already stumbled across some good bugs, and you think there are more in there, but the deadline comes and the software is released. A week later, a major client finds a serious problem with the new release and lets everyone know about it in an industry press release. You begin thinking about what went wrong and how you can improve your testing coverage.
- You’re on a job interview, and the person across the desk asks you how to test a product, especially when there’s too much to do in so little time.
- Your management has an elementary understanding of software testing, and as a result, sets unrealistic expectations for you to “test everything.” They demand 100% coverage, including testing all possible inputs, from all possible interfaces, into all possible system paths, into all possible outputs. You know these are ridiculous demands, and you start thinking about alternate testing methods. (and/or alternate employment opportunities).
Loading ...