Testing Estimation Interview Preparation Guide

Download PDF

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.
Inputs for this process:
* A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
* A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
* Testing methodology. This is based on known standards.
* Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
* Requirements that the system can not provide, e.g. system limitations.
Outputs for this process:
* An approved and signed off test strategy document, test plan, including test cases.
* Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

Time Estimation method for Testing Process
Note : folloing method is based on use case driven specification.
Step 1 : count number of use cases (NUC) of system
step 2 : Set Avg Time Test Cases(ATTC) as per test plan
step 3 : Estimate total number of test cases (NTC)
Total number of test cases = Number of usecases X Avg testcases per a use case
Step 4 : Set Avg Execution Time (AET) per a test case (idelly 15 min depends on your system)
Step 5 : Calculate Total Execution Time (TET)
TET = Total number of test cases * AET
Step 6 : Calculate Test Case Creation Time (TCCT)
useually we will take 1.5 times of TET as TCCT
TCCT = 1.5 * TET
Step 7 : Time for ReTest Case Execution (RTCE) this is for retesting
useually we take 0.5 times of TET
RTCE = 0.5 * TET
Step 8 : Set Report generation Time (RGT
usually we take 0.2 times of TET
RGT = 0.2 * TET
Step 9 : Set Test Environment Setup Time (TEST)
it also depends on test plan
Step 10 : Total Estimation time = TET + TCCT+ RTCE + RGT + TEST + some buffer...;)
Example
Total No of use cases (NUC) : 227
Average test cases per Use cases(AET) : 10
Estimated Test cases(NTC) : 227 * 10 = 2270
Time estimation execution (TET) : 2270/4 = 567.5 hr
Time for creating testcases (TCCT) : 567.5*4/3 = 756.6 hr
Time for retesting (RTCE) : 567.5/2 = 283.75 hr
Report Generation(RGT) = 100 hr
Test Environment Setup Time(TEST) = 20 hr.
-------------------
Total Hrs 1727.85 + buffer
-------------------
here 4 means Number of testcases executed per hour
i.e 15 min will take for execution of each test case

Functional Point is measured from a functional, or user, point of view.

It is independent of computer language, capability, technology or development methodology of the team. It is based on available documents like SRS, Design etc.

In this FP technique we have to give weightage to each functional point. Prior to start actual estimating tasks functional points are divided into three groups like Complex, Medium & Simple. Based on similar projects & Organization standards we have to define estimate per function points.

Total Effort Estimate = Total Function Points * Estimate defined per Functional Point

Three point estimation is the estimation method is based on statistical data. It is very much similar to WBS technique, task are broken down into subtasks & three types of estimation are done on this sub pieces.

Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.) = A

Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.) = M

Pessimistic Estimate (worst case scenario which everything goes wrong.) = B

Formula to find Value for Estimate (E) = A + (4*M) + B / 6

Standard Deviation (SD) = = (B – A)/6

Now a days, planning poker and Delphi estimates are most popular testing test estimation techniques.

A big project is made manageable by first breaking it down into individual components in a hierarchical structure, known as the Work breakdown structure, or the WBS.

The WBS helps to project manager and the team to create the task scheduling, detailed cost estimation of the project. By using the WBS motions, the project manager and team will have a pretty good idea whether or not they’ve captured all the necessary tasks, based on the project requirements, which are going to need to happen to get the job done.

In this technique the complex project is divided into smaller pieces. The modules are divided into smaller sub-modules. Each sub-modules are further divided into functionality. And each functionality can be divided into sub-functionalities. After breakdown the work all functionality should review to check whether each & every functionality is covered in the WBS.

Using this you can easily figure out the what all task needs to completed & they are breakdown into details task so estimation to details task would be more easier than estimating overall Complex project at one shot.

Work Breakdown Structure has four key benefits:

Work Breakdown Structure forces the team to create detailed steps:
In The WBS all steps required to build or deliver the service are divided into detailed task by Project manager, Team and customer. It helps to raise the critical issues early on, narrow down the scope of the project and create a dialogue which will help make clear bring out assumptions, ambiguities, narrow the scope of the project, and raise critical issues early on.
Work Breakdown Structure help to improve the schedule and budget.
WBS enables you to make an effective schedule and good budget plans. As all tasks are already available so it helps in generating a meaningful schedule and makes scheming a reliable budget easier.
Work Breakdown Structure creates accountability
The level of details task breakdown helps to assign particular module task to individual, which makes easier to hold person accountable to complete the task. Also the detailed task in WBS, people cannot allow hiding under the “cover of broadness.”
Work Breakdown Structure creation breeds commitment
The process of developing and completing a WBS breed excitement and commitment. Although the project manager will often develop the high-level WBS, he will seek the participation of his core team to flesh out the extreme detail of the WBS. This participation will spark involvement in the project.

Delphi technique – This is one of the widely used software testing estimation technique.

In the Delphi Method is based on surveys and basically collects the information from participants who are experts. In this estimation technique each task is assigned to each team member & over multiple rounds surveys are conduct unless & until a final estimation of task is not finalized. In each round the thought about task are gathered & feedback is provided. By using this method, you can get quantitative and qualitative results.

In overall techniques this technique gives good confidence in the estimation. This technique can be used with the combination of the other techniques.

There are different Software Testing Estimation Techniques which can be used for estimating a task.

1) Delphi Technique
2) Work Breakdown Structure (WBS)
3) Three Point Estimation
4) Functional Point Method

The third question is very important one. You can write about test Director, Win runner/Load runner, McCable or any other coverage tool. Test director is useful to track defect. WR or LR to do functionality/Load testing, Coverage tool to check the code coverage thereby helping in White box testing.

Following steps need to be taken .
a) Acceptance criteria should tighten
b) Test cases should be re-evaluated (preferably peer review)
c) If possible more test cases should be added. With boundary value and
equivalence class partition cases.
d) More test cases with invalid condition should be added
e) Stop criteria needs to be modified

Conflict resolution – Get on your customer wavelength. Get the facts and ask
questions, get detail info and take notes listen carefully. Establish and initiate an action program(admit error if it is there, negotiate satisfactory solution, state the solution and get agreement, take action and follow up with customer). Finally establish proper daily problem review process to prevent such problems in future.

The first step in FPA is to define the boundary. There are two types of major boundaries:

Internal Application Boundary
External Application Boundary

The external application boundary can be identified using the following litmus test:

Does it have or will it have any other interface to maintain its data, which was not developed by you?.
Does your program have to go through a third party API or layer? In order for your application to interact with the tax department application your code has to interact with the tax department API.
The best litmus test is to ask yourself if you have full access to the system. If you have full rights to make changes then it is an internal application boundary, otherwise it is an external application boundary.

This section is the most important section. All the previously discussed sections relate only to applications. But there are other things also to be considered while making software, such as are you going to make it an N-Tier application, what's the performance level the user is expecting, etc. These other factors are called GSCs.

An EQ is a dynamic elementary process in which result data is retrieved from one or more ILF or EIF. In this EP some input requests have to enter the application boundary. Output results exits the application boundary.

EOs are dynamic elementary processes in which derived data crosses from the internal application boundary to the external application boundary.

EIs are dynamic elementary processes in which data is received from the external application boundary. Example: User interaction screens, when data comes from the User Interface to the Internal Application.

EIFs reside in the external application boundary. EIFs are used only for reference purposes and are not maintained by internal applications. EIFs are maintained by external applications.

ILFs are logically related data from a user's point of view. They reside in the internal application boundary and are maintained through the elementary process of the application.ILFs can have a maintenance screen but not always.

An FTR is a file or data referenced by a transaction. An FTR should be an ILF or EIF. So count each ILF or EIF read during the process. If the EP is maintained as an ILF then count that as an FTR. So by default you will always have one FTR in any EP.

Software applications are a combination of elementary processes. When elementary processes come together they form a software application.

There are two types of elementary processes:

Dynamic elementary Process: The dynamic elementary process moves data from an internal application boundary to an external application boundary or vice-versa. Example: Input data screen where a user inputs data into the application. Data moves from the input screen inside the application.
Static elementary Process: Static elementary process which maintains the data of the application either inside the application boundary or in the external application boundary. For example, in a customer maintenance screen maintaining customer data is a static elementary process.

The testing estimates derived from function points are actually the estimates for white box testing. So in the following figure the man days are actually the estimates for white box testing of the project. It does not take into account black box testing estimation.

Static elementary process which maintains the data of the application either inside the application boundary or in the external application boundary. For example, in a customer maintenance screen maintaining customer data is a static elementary process.

The dynamic elementary process moves data from an internal application boundary to an external application boundary or vice-versa. Example: Input data screen where a user inputs data into the application. Data moves from the input screen inside the application.

TPA is a technique used to estimate test efforts for black box testing. Inputs for TPA are the counts derived from function points.

Below are the features of TPA:

Used to estimate only black box testing.
Require function points as inputs.

There are five methodologies most frequently used:

Top down according to budget
WBS (Work Breakdown Structure)
Guess and gut feeling
Early project data
TPA (Test Point Analysis)

There are three main elements which determine estimates for black box testing: size, test strategy, and productivity. Using all three elements we can determine the estimate for black box testing for a given project. Let's take a look at these elements.

Size: The most important aspect of estimating is definitely the size of the project. The size of a project is mainly defined by the number of function points. But a function point fails or pays the least attention to the following factors:
Complexity: Complexity defines how many conditions exist in function points identified during a project. More conditions means more test cases which means more testing estimates. Software Testing Image
Interfacing: How much does one function affect the other part of the system? If a function is modified then accordingly the other systems have to be tested as one function always impacts another.
Uniformity: How reusable is the application? It is important to consider how many similar structured functions exist in the system. It is important to consider the extent to which the system allows testing with slight modifications.

Test strategy: Every project has certain requirements. The importance of all these requirements also affects testing estimates. Any requirement importance is from two perspectives: one is the user importance and the other is the user usage. Depending on these two characteristics a requirement rating can be generated and a strategy can be chalked out accordingly, which also means that estimates vary accordingly.
Productivity: This is one more important aspect to be considered while estimating black box testing. Productivity depends on many aspects.