Giving test estimation for unknown application

Question

I have come across different estimation techniques like Delphi, WBS, 3 point estimation etc. These techniques work only when you know about the application(website).

Let's suppose I have to give estimates for a website which I never worked on, not even my team members have any experience.

Example:
I can give testing estimates of a website which is built on the Insurance domain but I or my team member only know about the Investment Domain.

How are we going to give estimates for unknown application?

Answer 1

There are a few things you can do.

1. Provide an estimate for providing the actual test estimate.
2. Go and talk with people that DO know, then guesstimate.
3. Add time for learning and for risk. Usually you will not get away with giving a range instead of a target date.
4. At least make an inventory of what is available in terms of documentation, previous test efforts, bug databases, whatever you can lay your hands on to increase "precision" and decrease risk. Comparing it with a familiar alike project will help as well.
5. Make sure you have a real good way to measure progress. Chop it up in very small pieces if you can.
6. Aim to do the most complex test cases early or as soon as you can in the project.
7. Both up front and while you are at it, keep informing all parties of progress and how the risk management plays out.

Good luck!

Answer 2

In addition to Bookeater's excellent answer, I can make a few suggestions:

• Start with the timeframe that you'd need for a familiar domain of about the same size, and double it. In your documentation, note that the time includes learning the new domain, rework because during that learning phase your team will misidentify issues, and so forth.
• Identify business experts you can use for reference and get their agreement to help when you need to know something business-related. Name them in your documentation as knowledge experts.
• If you can, try to list the assumptions and base criteria within which the application is working. This can be poorly documented if at all, particularly in a large application with a long history, and may not appear in use cases because "everyone knows" that's how things work (this is my life - I try to document these assumptions as I run into them, but there's a long way to go).
• Plan to maintain a copy of the application prior to the changes you're testing as well as the version you're testing. That way, you can use the original version as your "oracle" for how existing function should work - and include this in your estimate documentation since you'll be effectively testing a number of things at least twice, once on the original application to determine how it should behave, and once on the upgrade to determine if the behavior matches.
• If at all possible, ask others - developers, project management, and so forth - how long it took to test the application in the past, and whether they were familiar with it.
• If you're coming in to a new application in an unfamiliar domain, you can get a crude estimate via a combination of the number of pages in the site, the number of form fields per page, and the amount of scripting on each page (which implies the number of decision branches). I'd state any such estimate in terms of "this is an initial estimate to give an approximate order of magnitude. My team would need x time to research the system and locate domain experts to give a more detailed estimate".

Answer 3

Regardless of how careful and conservative you will be when making the estimate, most likely you will be wrong. So is important to find out who is carrying the risk of budget overrun, what will be the consequences of the wrong guess?

• Is this a "fixed price" contract and you will you have to eat the cost of overrun? Or is customer willing to pay you (possibly reduced) hourly rate for project extension?
• Is delay possible (even if not preferred), or is release date fixed (say by law or external circumstances) and not movable?
• what will be the consequences of the failure? It this control system for a nuclear power plant, or yet another social platform?
• Do you have a customer on site who can make decisions if identified behavior is bug or feature? Because while customer is making decision, clock is ticking.

You get the idea. For different answers to above questions, I would use different padding factors to whatever guesstimate I would establish.

Answer 4

I want to propose you a different point of view: "don't you know anything about the website you are requested to test?" So, take all of the time they are available to offer you then organize your tests accordingly. Estimating a test is harder than estimating the development of the same software even if you have a good knowledge of the software you are going to test.