Re: Testing Internet and Telephony Applications
- From: Michael Bolton <michael.a.bolton@xxxxxxxxx>
- Date: Thu, 09 Aug 2007 00:51:45 -0700
On Aug 8, 10:16 pm, Bala <balaji...@xxxxxxxxx> wrote:
Hi,
I would like someone to explain the different Effort Estimation
methods available and one which I can apply for estimating effort
needed to test a set of requirements.
Following is the scenario:
1) I am the only tester available in the organisation.
2) I need to prepare the test plan, schedule it, (reschedule in due
course if plan is not correct), write test cases, execute, track and
report them. (I believe, I should take into account all these
activities)
3) Let us assume, I am having a product "X" of version of 1.2.3 and
has several modules. I am upgrading one of the modules. I have a set
of requirements say 30, of which 15 are upgrades, 10 changes and 5
deletions (deletions may have an impact on the already existing
modules).
4) Since the effort required is based on the number of test cases, let
us assume there are some 300 test cases.
5) I also have a doubt whether effort should be estimated after
identifying test cases or prior to that. (ie) after you have the
requirements, do we need to make a guess, say ok, for this
requirement, I will have this many test cases and for the next
requirement, I will have these many test cases. How should be the
process?
How should I estimate the effort?
That's easy: when do they want to ship? Anything based on any other
factor will be wrong, as you indicate in (2), and will therefore cause
you even more unnecessary work than you're doing already--and since
you're the only tester, I guarantee that this is wasting precious
testing time.
Note that it's ridiculous to count requirements. Here's one
requirement: transactions on the ATM will require the user to enter a
password of 12 digits. Here's another: the ATM will interface with
all of member banks in the Plus System. Do you see a potential for
error here? It's equally ridiculous to count test cases. Does a test
case take one minute or one hundred? Does it exercise one line of
code or one megabyte of it? Can you make one observation in the
process of executing the test, or one thousand? Would each of those
observations (lines of code, minutes) be of equal value?
Do you plan to estimate problem reporting time? Note that you cannot
do this in any meaningful way. You don't know how many problems
you're going to find; you don't know how much time you're going to
spend investigating the problem; and you don't know how long it's
going to take to report the problem. You don't know how the problem
will impact the other test cases that you've planned. You don't know
if there will be a fix. You don't know how much time it's going to
take to test the fix--if there is one--or how much waiting for the fix
will impact your schedule. You don't know if the fix will take one or
ten iterations to fix.
The estimation process is much simpler than that: you don't have to
estimate testing time; your development manager or project manager has
to estimate development time. When they think they're done with that,
then they'll have to estimate fixing time. The matter isn't in your
hands, so I would suggest that you stop estimating and start testing
now.
Have a look here: http://www.developsense.com/blog/archive/2007_01_01_archive.html
I'm serious about this. If you or your bosses don't understand it,
all are welcome to converse with me about it here or via email--
michael.a.bolton@xxxxxxxxxx
---Michael B.
.
- Follow-Ups:
- Re: Testing Internet and Telephony Applications
- From: Vladimir Trushkin
- Re: Testing Internet and Telephony Applications
- From: Pradeep Soundararajan
- Re: Testing Internet and Telephony Applications
- References:
- Testing Internet and Telephony Applications
- From: Bala
- Testing Internet and Telephony Applications
- Prev by Date: Re: Testing Internet and Telephony Applications
- Next by Date: Re: JSP using Cactus
- Previous by thread: Re: Testing Internet and Telephony Applications
- Next by thread: Re: Testing Internet and Telephony Applications
- Index(es):
Relevant Pages
|