Many times you don't have time to create the test plan, I have at times been in project planning meetings where a grand scope has been given and Engineering is then asked then and there - to give an estimate. Basically then its a sort of guessing game, which is what estimates are, and if you are being asked to give one you can be sure it will be wrong. That is what an estimate is. Although this will all depend on what sort of process you are using, but if this was a full-up project starting at the beginning with Dev and Test working in parallel I think of the following:

• Is this new technology? The development will need to learn it, extending their time so you will need to learn it to test
• How often will builds come? Are there milestones? Is there a new build process that will need to be implemented? Considering the code coming in to test and how stable it will be, as well as bugfix builds
• Does this require new tools to test? You'll need time to acquire/build as well as setup/train the tools...then take some trial runs to see if things work as expected
• How many resources will you be allowed to have? Will they be shared? This means context switching and loss of resources (emergencies, vacations, people leaving, new hires), you need to plan properly

These are the ones that I would think of in addition to what glowcoder mentioned, they will be a part of any project, and the more documentation you have to provide the longer things will take as well.

Many times you don't have time to create the test plan, I have at times been in project planning meetings where a grand scope has been given and Engineering is then asked then and there - to give an estimate. Basically then its a sort of guessing game, which is what estimates are, and if you are being asked to give one you can be sure it will be wrong. That is what an estimate is. Although this will all depend on what sort of process you are using, but if this was a full-up project starting at the beginning with Dev and Test working in parallel I think of the following:

• Is this new technology? The Development Team will need to learn it, extending their time so you will need to learn it to test
• How often will builds come? Are there milestones? Is there a new build process that will need to be implemented? Considering the code coming in to test and how stable it will be, as well as bugfix builds
• Does this require new tools to test? You'll need time to acquire/build as well as setup/train the tools...then take some trial runs to see if things work as expected
• How many resources will you be allowed to have? Will they be shared? This means context switching and loss of resources (emergencies, vacations, people leaving, new hires), you need to plan properly

These are the ones that I would think of in addition to what glowcoder mentioned, they will be a part of any project, and the more documentation you have to provide the longer things will take as well.

Many times you don't have time to create the test plan, I have at times been in project planning meetings where a grand scope has been given and Engineering is then asked then and there - to give an estimate. Basically then its a sort of guessing game, which is what estimates are, and if you are being asked to give one you can be sure it will be wrong. That is what an estimate is. Although this will all depend on what sort of process you are using, but if this was a full-up project starting at the beginning with Dev and Test working in parallel I think of the following:

• Is this new technology? Development will need to learn it, extending their time so you will need to learn it to test
• How often will builds come? Are there milestones? Is there a new build process that will need to be impleted? Considering the code coming in to test and how stable it will be, as well as bug fix builds
• Does this require new tools to test? You'll need time to acquire/build as well as setup/train the tools...then take some trial runs to see if things work as expected
• How many resources will you be allowed to have? Will they be shared? This means context switching and loss of resources (emergencies, vacations, people leaving, new hires), you need to plan properly

These are the ones that I would think of in additoin to what glowcoder mentioned, they will be a part of any project, and the more documentation you have to provide the longer things will take as well.

Many times you don't have time to create the test plan, I have at times been in project planning meetings where a grand scope has been given and Engineering is then asked then and there - to give an estimate. Basically then its a sort of guessing game, which is what estimates are, and if you are being asked to give one you can be sure it will be wrong. That is what an estimate is. Although this will all depend on what sort of process you are using, but if this was a full-up project starting at the beginning with Dev and Test working in parallel I think of the following:

• Is this new technology? The development will need to learn it, extending their time so you will need to learn it to test
• How often will builds come? Are there milestones? Is there a new build process that will need to be implemented? Considering the code coming in to test and how stable it will be, as well as bugfix builds
• Does this require new tools to test? You'll need time to acquire/build as well as setup/train the tools...then take some trial runs to see if things work as expected
• How many resources will you be allowed to have? Will they be shared? This means context switching and loss of resources (emergencies, vacations, people leaving, new hires), you need to plan properly

These are the ones that I would think of in addition to what glowcoder mentioned, they will be a part of any project, and the more documentation you have to provide the longer things will take as well.