| In a typical software development life cycle (SDLC) it | | | | best testers to help you prove your case. The case |
| is not unusual for the software testing phase of the | | | | you are aiming to prove is that the product will not |
| project to be compressed. As the last stage in the | | | | reach the required level of quality by the time this |
| cycle the time scales for the software testing tend to | | | | software product is ready to ship. |
| get reduced as the project team attempts to maintain | | | | 3. Prepare your evidence |
| the commitment to meet the delivery date. | | | | This step is all about turning the testing from something |
| It is usually the software test schedule that gets | | | | that isn't quantifiable in to something that is quantifiable. |
| reduced because reducing the development time | | | | Start tracking the defect find rate (number and |
| either means removing features or increasing the | | | | severity of defects against the date) on a graph. If |
| amount of developers. Neither of these options appear | | | | your best testers are doing the job they are employed |
| very attractive. One means an uncomfortable | | | | for then this graph is going to show a ramping up and |
| discussion with the customer and the other means | | | | steady increase in the defect detection rate. |
| increased costs. So any tough decisions around | | | | 4. Use your evidence |
| adjusting the development phase are usually | | | | Your defect detection rate should be used as |
| postponed and the call deferred until the product | | | | evidence to break the illusion that the project is on |
| enters the software test phase. At this point the | | | | track. If your testers are continuing to find defects at a |
| discussions become more interesting. | | | | steady rate, with significant defect priorities, then this |
| The main options at this point include adding more | | | | can be projected forward. With projected estimates |
| software testers, reducing the amount of software | | | | you can demonstrate that the software application |
| testing or changing the delivery date. Changing the | | | | won't be of sufficient quality to release on the agreed |
| delivery date is usually dismissed initially as not | | | | date. |
| acceptable to the customer. Adding more testers is | | | | This isn't an exact science in software testing but it will |
| usually dismissed as it requires additional expenditure. | | | | give you something concrete to fight your corner with. |
| This only leaves reducing the amount of software | | | | If you combine this with the rate at which the |
| testing. The interesting thing to note here is that the | | | | development team are fixing defects you have quite a |
| first two (delivery date and more testers) are both | | | | powerful set of statistics to work with. You could even |
| quantifiable and visible. Changing the delivery date | | | | go as far as estimating the number serious defects |
| requires agreement with the customer and adding | | | | that the software product is likely to be released with. |
| more testers will increases costs (and decrease profit). | | | | You need to start collecting this evidence as quickly as |
| Reducing the amount of time spent testing isn't as | | | | possible and present the evidence to the project team |
| visible and is difficult to quantify. The only point at which | | | | as soon as you have enough data. This then gives |
| reducing the amount of software testing becomes | | | | everyone three tangible options to choose from; |
| visible is after the product is released. | | | | change the delivery date, add more resources (to |
| So, unless you've got a very good case, forget about | | | | development and test) or release with poor quality. |
| trying to convince the project team that reducing the | | | | Of course the option to release with poor quality will |
| amount of software testing is the wrong solution. The | | | | still be high on the list of choices here. So you may |
| project team are unlikely to listen when the other | | | | want to support your defect find rate evidence with |
| options are so visible and quantifiable. The option to | | | | details about the types of likely defects. For example, if |
| reduce the amount of software testing is likely to be | | | | your team are finding high priority defects, like issues |
| selected and as a result this will create the illusion that | | | | that would block a release, on a daily basis then you |
| the project is on track. But it's an illusion that can't be | | | | are in a stronger position. In a strong position you are |
| maintained indefinitely. Usually this illusion is shattered | | | | better able to counter people using the software |
| just after the software product is released. The aim is | | | | testing reduction solution as a credible option. |
| to shatter that illusion before the product ships so that | | | | It is important to remember that the aim isn't to work |
| the customer maintains their faith in your ability to | | | | against the development and projects team here. The |
| deliver a quality product. | | | | aim is to work with them. After all the software test |
| There is only really one strategy at the test team's | | | | team have as much to gain from a high quality release, |
| disposal that combats this demand to reduce the | | | | delivered on time, as much as anyone else. |
| software testing schedule. This strategy is as follows: | | | | The goal should always be to present as much |
| 1. Initially accept the reduction | | | | information as possible so that the whole team (test, |
| Don't waste your time trying to argue against the | | | | development and projects) can make the right call. |
| reduction in test time unless you have a very strong | | | | The right call in balancing the release date, features |
| case, which you know you can win. You are better off | | | | and quality is best made with all the relevant data. |
| directing your efforts into more constructive tasks and | | | | Sometimes, much to the disdain of the test team, that |
| following the next 3 steps. | | | | right call is to release with slightly below par quality. So |
| 2. Deploy the best testers you have on the project | | | | long as that call is made with the best intentions and is |
| Good software testers find good defects. With the | | | | based on the right data then you stand a much higher |
| best testers you have on the project you stand a | | | | chance of getting it right. |
| better chance of finding more defects in a shorter time | | | | As always, in the end, it comes down to getting the |
| frame. From the project managers point of view this | | | | balance of delivery date, features and quality right for |
| will look like you are playing ball with their requirements | | | | the customer. |
| to reduce the testing time. In reality you'll be using your | | | | |