progressing on guestimates

guestimates: time quoted (by an inexperienced tester) as the estimated time taken to carry out a (set of) test(s) by an individual (or a set of individuals) .

a journey from plucking a number out of thin air to providing a right estimate takes time. this time is the ‘experience’ which allows a tester get away from ‘guestimating’ and get closer to ‘predicting’ time it takes to do a (set of) test(s).

i remember being asked “how long will it take you to test this module?” during one of my first employments. i naively replied back, having spoken to the most experienced guy around, “two days”. i did it in two days alright, but they were stretched, working days.

this continued for some time and in 8 out of 10 instances, i was being stretched. i was luckier in others where i could complete my work just in time. that was working hard. not smart!

it took me some time, questions, feedback, more questions and thus, experience, before i got myself into the act of providing a number that included various activities that went into me running a test including (but perhaps not limited to):

  1. understanding the requirement/specification and the functionality behind the item being tested
  2. (basic) understanding of the data required – both as a pre-requisite and operational
  3. writing a test case / scenario
  4. executing a test case / scenario
  5. writing a defect report, if it disagreed with its requirements
  6. retesting defect (if there was one to be raised)
  7. contingency (of any admin tasks, environment non-availability, release delays etc)
  8. regression testing (if there is a requirement for one)

i especially like to keep a note of how this has worked for me. i’ve noticed this model works well in most, if not all, cases.

during the last 6 odd months, this has proven accurate enough to be treated as a template for the cost model for testing activities and has even proven the historic estimate of 35-40% of dev time on testing wrong (atleast in my work place and for data warehouse testing that i do).

matthew heusser has some brilliant advice on software test estimation. series of about 7 items available on his blog.

hello [testing] world

so there is yet another blog on testing (now we shall refer to this as “YABOT”)! myeh

ok. in my defence, i’d like to put this as a place to note down quite a number of things – all testing related. sorry, software testing related – just so that i dont forget and just so that if i come across a person who has had same issues i faced (or even if i have a feeling of deja-vu), i could direct them (or myself) here.

whether you are one of them or not, hello!

and because i intend this to be a place to refer to, to self teach, look for, suggest best approaches as proposed by peers, i hope to link to many ideas proposed by such peers, revolutionaries and hopefully, some day, of my own…