Test estimation effort for a new piece of functionality

Question

When joining a new company, how does one give a test estimation effort for a piece of functionality?

When you don't have full knowledge of the system, or the functionality is brand new, wouldn't it be very hard to give a test estimation?

Could you give some examples how you've overcome this, or do you just give a rough estimate such as half the time it takes for the devs to code?

Answer 1

Some of the things I look at are:

• Standalone or Not - test effort tends to be less if the new functionality is a standalone application rather than a new feature of an existing application
• Internal Complexity - Something that does a lot of things will generally need more time than something that does a few things.
• Edges and Integrations - Something that has a single defined interface to integrate with existing functionality will be much simpler to test than something that is embedded into existing functionality. For example, it's simpler to add support for a new turnstile to an admission control application than it is to add a new admission rule because the turnstile communicates over a well-defined API where the admission rule has to be integrated into the application data storage, the system attendance counts, the point of sale system (to sell media with the new admission rule), the reporting system, and so forth.
• Impact on Existing Functionality - this is a little harder to gauge when you're not familiar with the existing functionality, but by looking through the information the developers have given as part of their estimates (which in a waterfall environment will typically be broken down with short descriptions of what they will be doing) you can get an idea of how much existing functionality needs to be regression-checked.

If I'm completely lost after going through this list, I'll use the half-dev-time estimation rule, but with a warning that it could prove to be very inaccurate.

Answer 2

In addition to Katie's excellent response and a general understanding of the technical/business logic complexity of implementing a feature I tend to find myself thinking in a "ballpark matrix" sort of way.

For example if I have a good idea of broad types of users interacting with the application I may know that the feature needs to be tested for "guests", "buyers" and "sellers" as 3 different sets of users with 3 levels of permissions. Perhaps your site also supports users with English, French, and Chinese as their primary languages. This would be another set of parameters to combine. Now let's go even further and assume you want this feature to be accessible to users on Chrome, Firefox, and for some reason IE9. We've now established at least 9 different use cases to account for with the full matrix of combinations looking closer to 27 scenarios. This isn't to say that you will or should hit all 27 combinations in all cases, but it has served me well as a "multiplier" of other estimated complexity.

Answer 3

For new code half the development time can be okay.

For modifications of existing software I would not use this estimate. In this case I would consider following issues:

• does the test environment exist already or will it have to be created
• is the change isolated or does it impact integrated systems
• how long did the last test cycle take