Saturday, March 7, 2009

Effort Estimation

Estimates is considered to be difficult/challenging as most of the time estimate is requested so early in the project you might not even know how much information to provide a close to accurate estimate. In-order to provide a decent estimate below mentioned information is considered.

Factors for Estimation

Market opportunity

  • Who the competition is?
  • What is the opportunity now and in the future?

Contractual terms

  • Are there penalty clauses?
  • Is it phase wise delivery?
  • Volatility of requirements
  • How standard is the requirement?
  • What could be the change in requirements over time?

Past Experience

  • Have we had a better or bitter experience?
  • Have we delivered something similar in the past?

Skill Set

  • Talent pool of engineers and the expectations of the project
  • In house training capability
  • Ability to learn quickly
  • Ability to ramp up
  • Can we ramp up our team in case we win the project?
  • Option and flexibility to outsource?

Technology

  • Complexity
  • Environment –Onsite/Offsite
  • Virtual Testing

Estimation Models

What is it?

  • Estimation model is the combination of the technique and the factors
  • A predefined framework or template
  • Adaptable with modifications

Build or use Models?

  • Using existing models is a safe bet
  • Derive and build your own models

Principle of Estimation for testing projects shall be:

  • Based on
  • Software requirements
  • Previous projects
  • Metrics
  • Estimation shall
  • Never forget the past
  • Be recorded
  • Be supported by tools
  • Be always verified
  • Consider automation needs
  • Consider people skills
  • Other Inputs to consider
  • # of test cases/scenarios,
  • # test cases per scenario,
  • # of builds (for regression)

We also have an old thumb rule for estimation i.e. to complete testing we will take about 30% of Development time. This will not hold good all the time as some time coding for some functionality can be done much faster than the time it takes for testing the functionality.

If at al possible, keep a history of your estimates versus actual. Time and experience are some of the best educators. If you keep track you can gain some useful history.


Thursday, March 5, 2009

Software Testing Methods

Software Testing Methods can be broadly classified as Black Box Testing, White Box Testing & Gray Box Testing.

Black Box Testing: In this type of testing , the tester views the program as a black - box, tester doesn't see the code of the program: Equivalence partitioning, Boundary - value analysis, Error guessing are the few which user will consider when testing.

White Box Testing: In this type of testing , the tester examine the internal structure of the program: Statement coverage, Decision coverage, condition coverage, Decision/Condition coverage, Multiple - condition coverage. This to do more with code verification. Usually the development team does this type of testing as many a times QA will not get accessto the code written by the developer.

Gray Box Testing: In this type of testing Black box testing can be combined with knowledge of database validation, such as SQL for database query and adding/loading data sets to confirm functions, as well as query the database to confirm expected result.