Community of Software Testing Professionals
Well said Jaya. It all depends on your level of experience but certain facts do take toll while estimating. Like no of screens/no of fields in each screen, no of roles, etc. As stated by about the modules exactly dividing req into separate modules gives clear picture.
At the end your thought process is good.
Here are some excelent points, but I think it doesn´t provide enough answers to the problem.
To sum what was already said here or in the linked post Pradeep provided:
All of this is true, but there could be said much more about this topic such as:
First you can ask people how much time it will take, but they never think of everything, even you will forgot about lot of tasks and problems. You can double or triple the guess, but it will be difficult to defend it.
To spend less time on estimation and have realistic number it is best to use heuristic and find similar project from past.
If there is not any, it can be usefull to find what the estimation is for development.
Use development estimation:
In development they do the similar thing as we. They design how the code should work i low lavel detail, we describe test cases and prepare data. They write code, we do test or write automation tests. They analyze code, we analyze results. In both cases there is management throuth similar amount of time.
So we should estimate it will take the same amount of time to be really confident about the product.
This is estimation is usefull, do not take more than an hour to make, precise, but has a
a) It works only for projects were the change has little influence to other systems (Change of one line could mean retest whole system)
b) It is for bigger critical projects. In non critical projects, the quality is not enough important to test so deep.
c) This estimation works for the whole testing process. If you want to estimate only business testing, when other department or company delivers it, this is no use for you.
Define assumptions for your estimations
But one thing I found the most important is work with assumptions. When you provide the estimation say on what assumptions you based it. How many bugs you expect, how many problems and with what, how many funtions do you expect, how many specification changes and so on.
In other terms if you say the estimation is valid only within these limits and nobody can blame you when the reality will be somewhere else, as several of these assupmsons will always be broken.
Because it really is just fortune-telling and you need a crystal ball or big luck to have your estimation precise.
(Or you can fix the estimation and have quality and scope of your testing as variable, but is really your estiomation worth doing bad job? )