Introduction
The purpose of this blog is to explain the Use case point analysis which is one of the well known test estimation technique.
Test Managers use many different ways to estimate the testing efforts. It depends on the organization and the methodologies they have implemented over the past and also the type of project they are dealing with, the type of technology they use etc.
Some of the conventional methods are,
This is purely driven by the existing previous history of the project and also the real time experience of the project members play a vital role in this type of estimation. This is some what Adhoc way of estimating the testing efforts. You can refer this as a bottom up approach as the management will decide a time scale for the delivery of the project based on the previous history of the project releases and the team work backward to fulfill the testing efforts. In this methodology always the gut feeling place a vital role.
In this method the development team estimates the time required to complete the development activities using some analysis techniques. Once this is done, the testing team will take a percentage of the total development efforts as testing efforts. It varies from 65-75% of the development effort.
Capers Jones is a specialist in software engineering methodologies, and is often associated with the function point model of cost estimation. According to him number of test cases can be determined by the functional point estimates for the corresponding effort. The formula is,
Number of test cases = (Functional Points)1.2
Then based on the previous history of the project a conversion factor is derived. This conversion factor is the value in man hours or man days required to execute a single test case. So the effort is,
Effort = Number of test cases * Conversion factor
Since the modern systems are developed using object oriented methodology keeping use cases in mind, this technique will be of no use.
Alistair has explained the use cases and the actors as described below,
Are basically users of the system. They are actually user types or categories. Actors are external entities (people or other systems) who interact with the system to achieve a desired goal.
The Actor(s) using the system to achieve a goal. The ‘Use Case’ documents the interactions between the system and the actors to achieve the goal of the primary actor.
These are Simple users who are like end users of an application. Example is a customer of NAP trying to buy an Item via web app.
Actors that the system needs assistance from to achieve the primary actor’s goal. These are Average users who are like stock control, finance, customer service agents etc. Example is, customer care agents may need to interact with the back end system which intern speak to DB to achieve the end users objective. This can also be an automated system instead of a person.
These are the one who interact at the API level. This can be a person or other system.
Is what happens when actors interact with the system. An actor uses the system to achieve a desired goal. By recording all the ways our system is used (“cases of use” or Use Cases) we accumulate all the goals or requirements of our system.
So, A Use Case is a collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system’s declared responsibilities, showing how the primary actor’s goal might be delivered or might fail.
Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal; each step in a scenario is a sub (or mini) goal of the use case. As such each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.
This hierarchical relationship is needed to properly model the requirements of a system being developed. A complete use case analysis requires several levels. In addition the level at which the use case is operating at it is important to understand the scope it is addressing. The level and scope are important to assure that the language and granularity of scenario steps remain consistent within the use case.
Therefore, A use case is a collection of possible sequences of interactions between the system under discussion and its Users (or Actors), relating to a particular goal. The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly. Any system behavior that is irrelevant to the actors should not be included in the use cases.
ü Hold Functional Requirements in an easy to read, easy to track text format.
ü Represents the goal of an interaction between an actor and the system. The goal represents a meaningful and measurable objective for the actor.
ü Records a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to the goal (success scenarios).
ü Records a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of the goal (failure scenarios).
ü Are multi-level: one use case can use/extent the functionality of another.
ü Specify user interface design. They specify the intent, not the action Detail
ü Specify implementation detail (unless it is of particular importance to the actor to be assured that the goal is properly met)
Use Cases are used during many stages of software development…
ü To Capture the Requirements of the systems.
ü To act as a springboard for the software design.
ü To validate the software design.
ü For Software Test and Quality Assurance. (Tests are performed to validate proper and complete implementation of the use cases)
ü Potentially as an initial framework for the on line help and user manual.
Ivar Jacobson, Swedish computer scientist known as major contributor to UML, Objectory, RUP and aspect-oriented software development , inventor of the use case, describes a use case transaction as a "round trip" from the user to the system back to the user; A transaction is finished when the system awaits a new input stimulus. In other words, in one transaction the actor performs some action which is input for the system. Then the system reacts; i.e., it processes the input and returns the result to the Actor. A new transaction starts when the actor reacts to the result, which in turn is input for the system.
It is quite possible that in a round trip, the system does not have to consult the database at all. There may not even be a database involved, or data may come from outside the system. Thus it is not appropriate to conclude that use case transactions are necessarily linked to transactions on a database.
One of the example is user searching for tops under clothing. When the user clicks on the tops tab, the system will display Tops page containing all tops. Now the user search for flat shoes under shoes section, now do you think they are two different types of transactions? Definitely no, as the use case specification is very generic, like searching for a specific category should display the proper content. How ever we can expect different flows when the user types some content in the search box provided and clicks on the search button.
In the similar way if you consider user sign in page, there are many text boxes to enter user information and each box is associated with different exception handling, so in this scenario you might consider each as a separate transaction. If the exception handling is generic then consider it as single transaction. It may be such that there is a pre defined framework which will handle all these exceptions, so this becomes a single transaction rather than many. Keep in mind that there are at least as many transactions as there are flows.
If a use case is having ten transactions, but only seven of them need effort and three follow from the framework, that use case is average rather than complex since we count the number of transactions as seven instead of ten.
Implementing the Use Case Point Analysis
1. Determine the number and type of Actors
2. Calculate the Unadjusted Actor Weight (UAW)
- calculate the Actor weight = actor factor * number of use cases
- calculated the sum of actor weights which gives UAW.
3. Identify the number and type of use cases
4. Calculate the Unadjusted Use Case Weight (UUCW) by summing the total use case weights identified.
5. Calculate the Unadjusted Use Case Points (UUCP) which is the sum of UAW and UUCW
6. Determine the technical complexity factors and the weight for the same
7. Calculate the Adjusted Use Case Points by using the below mentioned formula,
AUCP = UUCP * [0.65 + (0.01*Technical Complexity Factor)]
8. Determine the conversion factor (CF)
9. Calculate the effort by using the below mentioned formula,
Effort = AUCP + CF
10. Consider the environmental factors which can include,
- Available resources
- Skill set of the resources
- Leave plan
- Bottlenecks
- Etc
11. Calculate the total effort by using the below mentioned formula,
Total Effort = Effort + Buffer Time
Where Buffer Time is 15 to 20% of the effort calculated.
That’s it J we are all done with the estimation :) :)
Happy Happy :) :)
References : Wiki
