Estimation Techniques

Estimation Techniques along with Test Plans and Test Strategies are done throughout the Planning phase of testing.  First there are 2 techniques that ISTQB mentions, consulting people and analyzing metrics.  The consulting technique involves working with experienced staff members and testers drawing upon their collective wisdom to develop structure for testing the project. Then collaborate to understand, tasks, effort, duration, dependencies, and resource requirements that the tests will need to be successful.


Analyzing metrics can be as simple or sophisticated as the tester can make it. ISTQB states the easiest approach asks, 'How many testers do we typically have per developer on a project?'
A more reliable method classifies the project in terms of size (small, medium or large) and complexity (simple, moderate or complex) then sees the average length of projects of a particular size and complexity have taken in the past to test.
Another reliable yet easy approach  that ISTQB mentions is to look at the average effort per test case in similar past projects and to use the estimated number of test cases to estimate the total effort. The more sophisticated methods that ISTQB mentions involve building mathematical models in a spreadsheet that look at historical or industry averages for certain key parameters number of tests run by tester per day, number of defects found by tester per day, etc. and then plugging in those parameters to predict duration and effort for key tasks or activities on your project. The tester-to-developer ratio is an example of a top-down estimation technique, in that the entire estimate is derived at the project level, while the parametric technique is bottom-up, at least when it is used to estimate individual tasks or activities.
ISTQB testers prefer to start by drawing on the team's wisdom to create the work-breakdown structure and a detailed bottom-up estimate. We then apply models and rules of thumb to check and adjust the estimate bottom-up and top-down using past history. This approach tends to create an estimate that is both more accurate and more defensible than either technique by itself.
Even the best estimate must be negotiated with management however. Negotiating sessions exhibit amazing variety, depending on the people involved. However, there are some classic negotiating positions. It's not unusual for the test leader or manager to try to sell the management team on the value added by the testing or to alert management to the potential problems that would result from not testing enough. It's not unusual for management to look for smart ways to accelerate the schedule or to press for equivalent coverage in less time or with fewer resources. In between these positions, you and your colleagues can reach compromise, if the parties are willing. Our experience has been that successful negotiations about estimates are those where the focus is less on winning and losing and more about figuring out how best to balance competing pressures in the realms of quality, schedule, budget and features.

IEEE 829 template

As promised in the last post I will write about the IEEE 829 template which is the ISTQB standard template for test plans.


The book seemed kind of vague to me as to what it was about but below is what the book had on the test plan template and what should be in it.


IEEE 829 STANDARD TEST PLAN TEMPLATE


Test plan identifier                             Test deliverables
Introduction                                        Test tasks
Test items                                            Environmental needs
Features to be tested                            Responsibilities
Features not to be tested                      Staffing and training needs
Approach                                             Schedule
Item pass/fail criteria                           Risks and contingencies
Suspension and resumption criteria     Approvals


I might update this post when I figure out more about the IEEE 829 standard Test Plan Template.

Test Plans

Test plans Estimates and strategies are 3 testing topics that go together and are prepared concurrently during the planning phase of testing.  I will start by talking about test plans.  There are many different definitions for test plan but the ISTQB book states a test plan is mainly the project plan for the testing work to be done.  Test plans differ from Test Design Specification, Test Cases or a set of Test procedures in the fact that less description is used in Test Plans.


ISTQB states that there are 3 main reasons as to why testers write test plans:
1. Writing a test plan guides our thinking. ISTQB explained this reason's logic as 'if we can explain something in words, we understand it. If not, there's a good chance we don't.'
Writing a test plan forces us to confront the challenges that await us and focus our thinking on important topics.


2. The test planning process and the plan itself can be a good excuse for a tester to communicate with other members of the project team, testers, peers, managers and other stakeholders.  This is an important aspect since collaboration can help improve a tester's understanding of a system and their testing overall.


3. The test plan also helps us manage change. During early phases of the project, as we gather more information, we revise our plans. As the project evolves and situations change, we adapt our plans. Written test plans give us a baseline against which to measure such revisions and changes. Furthermore, updating the plan at major milestones helps keep testing aligned with project needs. As we run the tests, we make final adjustments to our plans based on the results. You might not have the time or the energy to update your test plans


ISTQB suggests to use a template when writing test plans to help remember important challenges.  ISTQB has it's own standard template called IEEE829 which I will write about in my next post.