This chapter is from the book
This chapter is from the book
This chapter is from the book
Solution Impediments
What if my management refuses to acknowledge the need for better estimates, test tools, or any of the other solutions you suggest?
Remember that “It’s their job, their business, and their profits.” Many people erroneously think that testing is a technical decision. Only a small part of testing is technical. The larger and more important part is business-oriented. Testing is what controls the quality of the product delivered to your customers and to your end-users. In business, poor quality will lose customers quickly, especially in a competitive marketplace. If your management is willing to take that risk, it’s their responsibility, and it’s out of your control as a tester. Unfortunately, a decision to release poor-quality software can affect the fortunes of everyone if the company fails.
What if I do not have measurable criteria, such as requirements, to serve as the basis of my tests?
There are a couple of options to try. One is to reverse-engineer the requirements from your working knowledge of the system. Yes, it may seem weird, and at times you will feel like you are violating good practice—like painting a target wherever the arrow hits. This does, however, set a standard that can be estimated and benchmarked against. You might be surprised at how many people will be interested in seeing the reverse-engineered requirements to understand what the system is really supposed to do.
Another technique is to perform an exploratory test applying your sense of how the software should work. In effect, you are using the system as a prospective end-user would. This is difficult because your perception of how the system should work may be totally different from the design; the defects you find might not be defects at all, but you still have to assess them. All in all, this is a weak and unreliable form of testing. But then again, not defining requirements is also a weak and unreliable way to build a system!
How do I control the scope of a test if the scope is constantly changing?
A scope creep is a contingency that should be considered in the test plan. You should have plans for at least a ten percent increase in the scope of work. Many times you will not be able to control the amount of software to be tested, but you can control the amount of testing performed on software. One very helpful approach is the “build” technique, in which successive builds of the system are tested. Each version of the software or system has an increased level of functionality over the previous build, much like stair steps (see Figure 8.3).
)
Figure 8.3 The Build Technique.
What is a common ratio of testers to developers?
There may not be a “common” ratio. In fact, we don’t think this is a good way to benchmark your testing effort. First of all, technologies and testing techniques differ from organization to organization. Second, to assume everyone else is testing effectively is a huge leap. Third, suppose the answer you arrive at for your organization is ten times the size of your current testing staff. Could you get the funding to hire that many new people? If so, could you manage them?
A reasonable starting point is to determine how many people you can effectively manage and with whom you can maintain good communication. Then assign duties within that group that align with your testing responsibilities. For example, two people might perform regression testing, one person might perform stress testing, and so forth. Within that framework, develop a set of testing techniques, tools, and standards (in short, a test process) that will streamline the testing effort. Studies have proven that small teams with even a shred of a common process can outperform large teams, simply due to the decreased complexity of communication.