The testing process is one of the most fundamental parts of a software project. Any software that is built (or modified) would have defects in it. Even the most confident of software developers and the most skilled would admit that there will be defects that creep in when they are writing their code (in fact, the best ones are a part of the testing effort, working closely with the testing team to ensure that the team fully understands what all has been done so that they can do their best to tweak all the defects out). So it is well understood that there is a need for testing in order to deliver a high quality item to the end customer; and the process of testing tries to ensure that most of the high severity defect are found out and fixed during the process.
The challenges come in terms of ensuring that there are enough resources for the testing process and the amount of time required for the testing process is also there. There can be a lot of pushback on this front from the project managers and others in the management team, since the development and testing schedules do take up a significant amount of the overall project cycle. From my experience, there is a fair amount of pressure on the test team leaders about pulling in their estimates and trying to get that part of the project done early. If you speak to some of these testing guys, their common refrain is that management typically (in a majority of cases) do not have people that came from a testing background and hence do not really understand the work we do, and hence we get pressured a lot.
So what is the way out to ensure that the testing estimates are accepted, even though there may be some rounds of discussion and some estimates may be refined (could be reduced, or in the off case, during the process of estimation and discussion, there may be some upwards estimation of the estimates as well). Well, like many other issues that come up during estimation and planning, there would be some amount of rigor combined at the same time with some amount of rough estimates.
How does rough estimate come up ? Well, if you have experienced testing leaders, when they look through the requirements (at a top level, since detailed requirements may not exist, but summary requirements would be there), they would be able to give a fairly good and rough estimate for the testing effort required, which can be broken down into number of people for the desired schedule.
Another way is to see similar projects (a lot of projects in large organizations can be similar, which gives a good idea of the testing efforts for a new project, at least as a good point for comparison purposes).
The effort is in preparing detailed testing estimates by taking the different requirements, breaking them down into test plans (more detailed test cases may not be possible given the state of requirements at this point of time). Some amount of rigorous review of these plans would give a very good consolidated testing requirement, both for the testing effort estimation and for later needs when these test plans would form the basis for preparing more detailed test cases.
The challenges come in terms of ensuring that there are enough resources for the testing process and the amount of time required for the testing process is also there. There can be a lot of pushback on this front from the project managers and others in the management team, since the development and testing schedules do take up a significant amount of the overall project cycle. From my experience, there is a fair amount of pressure on the test team leaders about pulling in their estimates and trying to get that part of the project done early. If you speak to some of these testing guys, their common refrain is that management typically (in a majority of cases) do not have people that came from a testing background and hence do not really understand the work we do, and hence we get pressured a lot.
So what is the way out to ensure that the testing estimates are accepted, even though there may be some rounds of discussion and some estimates may be refined (could be reduced, or in the off case, during the process of estimation and discussion, there may be some upwards estimation of the estimates as well). Well, like many other issues that come up during estimation and planning, there would be some amount of rigor combined at the same time with some amount of rough estimates.
How does rough estimate come up ? Well, if you have experienced testing leaders, when they look through the requirements (at a top level, since detailed requirements may not exist, but summary requirements would be there), they would be able to give a fairly good and rough estimate for the testing effort required, which can be broken down into number of people for the desired schedule.
Another way is to see similar projects (a lot of projects in large organizations can be similar, which gives a good idea of the testing efforts for a new project, at least as a good point for comparison purposes).
The effort is in preparing detailed testing estimates by taking the different requirements, breaking them down into test plans (more detailed test cases may not be possible given the state of requirements at this point of time). Some amount of rigorous review of these plans would give a very good consolidated testing requirement, both for the testing effort estimation and for later needs when these test plans would form the basis for preparing more detailed test cases.
No comments:
Post a Comment