In a traditional software development lifecycle (SDLC) is not unusual for the test phase of software project to be compressed. As the last phase of the timetable cycle software testing tends to reduce the project seeks to maintain the commitment to meet the delivery date.
It is generally the timing of testing of software will be reduced due to reduced development time in both directions to remove features or increasing the amount of developers. None of these options seem very attractive. An unpleasant way to a discussion with the client and other means increased costs. So all the hard decisions on the adaptation of the development is normally exposed, and he called deferred until the product in the phase of software testing. At this point the discussion becomes more interesting.
Main options at this stage, but also by increasing the software tester, software testing by reducing or changing the delivery date. Changing the delivery time is usually rejected at first did not accept the client. Adding more testers are usually rejected because it requires additional expenses. This leaves only the reduction of software testing. One interesting thing to note is that the first two (delivery and more testers) are measurable and visible. Change the delivery requires the customer and the cost of adding more testers (and reduce profits). By reducing the time spent on testing is not as visible and it is difficult to measure. The only point where the reduction of software testing should be visible when the product is released.
Unless you have a very good case, forget trying to convince the project team that reducing the amount of software testing is the wrong solution. The project team are not willing to listen when other options are so visible and quantifiable. The option of reducing the amount of software testing is likely to be selected and therefore will create the illusion that the project is on track. But it is an illusion that can not be maintained indefinitely. Usually, this illusion breaks just after the software product is released. The aim is to break this illusion before sending the product to the client keeps faith in his ability to deliver a quality product.
There's really only one strategy to the test team has to fight against this requirement is to reduce software testing schedule. This strategy is as follows:
1. Initially accepting the reduction
Do not waste your time trying to argue against reducing the test time, unless you have a very strong case that you know you can win. You're missing your best efforts into more constructive tasks, and after the next 3 steps.
2. Implement best testers in the project has
Good software testers find defects right. With the best testers in the project is having a better chance of finding more defects in a shorter period. Project managers from the point of view seems to play ball with their requirements to reduce test time. In fact, use its best testers to help prove your case. If we want to show is that the product does not reach the level of quality required by the time the software is ready to be shipped.
3. Prepare screen
This step is to convert the try for something that was not quantifiable in something that is quantifiable. Begin tracking the bug find rate (number and severity of errors against the date) on a graph. If your best testers do the job they are hired to this graph shows an increased and steady rise in the rate of fault detection.
4. Use the display
The rate of fault detection should be used as evidence to break the illusion that the project is progressing. If the testers were still finding errors in a steady rhythm, and a serious error of priorities, this can be important. In assessing the estimates, you can show that the application program is not of sufficient quality to deliver the agreed date.
This is not an exact science in software testing, but it gives you something concrete to fight their corner. Combine this with the speed at which the development team is fixing the flaws that have a good powerful system of statistics to work. You could even go as far as estimating the number of serious defects that the software product is likely to be released.
You need to start collecting evidence as soon as possible and to provide evidence of a project team as soon as they have sufficient information. This then gives all three concrete options to change the date of delivery, more resources (for development and testing) or a bad version.
Of course, the possibility of release of poor quality remains high on the list of options here. So you can not support a failure to find evidence of interest in all probable defects. For example, if a team is to identify priority problems, things like that would have blocked the exit, on a daily basis so you're stronger. In a position of strength you are better able to fight the people who use the software testing solutions to reduce the viable option.
It is important to remember that the goal is not to work against the development team and projects here. The objective is to work with them. After all the software test team has much to gain by publishing high quality, delivered on time, as much as everyone else.
The aim must always be present as much information as possible so that the whole team (testing and development projects) can make the right call. The right call to balance the release date, features and quality are best done with all the relevant data. Sometimes, much to the disdain for the test team, the right call is to release a little below par in quality. Until this call is made with the best intentions and based on real data, so you have more chance of getting it right.