Equivalence Partitioning

Equivalence Partitioning

Definition of Equivalence Partitioning

Equivalence Partitioning is a black-box testing technique (basic test-design technique) that splits the input domain into classes of data. From this data we can derive test cases.

Test-case design with the help of equivalence partitioning technique has two steps:

1) Identifying the equivalence classes.

2) Defining the test cases.

Example 1 of Equivalence Partitioning

Problem:

The program reads three integer values from an input dialog. The three values represent the lengths of the sides of a triangle. The program displays a message that states whether the triangle is scalene, isosceles, or equilateral. Remember that a scalene triangle is one where no two sides are equal, whereas an isosceles triangle has two equal sides, and an equilateral triangle has three sides of equal length. Moreover, the angles opposite the equal sides in an isosceles triangle also are equal (it also follows that the sides opposite equal angles in a triangle are equal), and all angles in an equilateral triangle are equal.

(Source: http://www.amazon.com/Art-Software-Testing-Glenford-Myers/dp/0471043281)

Solution:

As seen in the definition above we have to identify equivalence classes and define test cases based on those classes.

Equivalence Classes for the triangle problem

Test Cases (Valid) for Equilateral Triangle

Test Case #	Side1	Side2	Side3	Expected Output
1	5	5	5	Equilateral

Test Cases (Valid) for Isosceles Triangle

Test Case #	Side1	Side2	Side3	Expected Output
1	2	2	3	Isosceles
2	2	3	2	Isosceles
3	3	2	2	Isosceles

Test Cases (Valid) for Scalene Triangle

Test Case #	Side1	Side2	Side3	Expected Output
1	3	4	6	Scalene
2	3	6	4	Scalene
3	4	3	6	Scalene

Test Cases (Invalid) Not a Triangle

Test Case #	Side1	Side2	Side3	Expected Output
1	3	1	2	Not a triangle
2	2	3	1	Not a triangle
3	1	2	4	Not a triangle

Pragmatic software testing By Rex Black also has solution

Example 2 of Equivalence Partitioning

The specifications for a application software system for authenticating expenses claim for motel accomodation for one night includes the following requirements:

Upper limit is $100 for accomodation expenses claims.

Any claims above $100 should be rejected and should cause an error message to be displayed.

Expense amounts should be greater than $0 and an error message should be displayed otherwise.

Designing test cases

Test case ID	Motel Charge	Equivalence class	Expected output
1	65	0 <>	OK
2	-24	Motel Charge <=0	Error message
3	110	Motel Charge > 100	Error message

Another Example of Equivalence Partition

Another Good Example on Equivalence Partitioning

Advantages of Equivalence Partitioning

It decreases the scope of extensive testing to a well-defined set of test procedures i.e. it reduces the number of required test cases by identifying classes of data. This in a way also helps to reduce redundant test cases.

Drawbacks of Equivalence Partitioning

The resultant test procedures do not include other types of tests that may have a high likelihood of finding an error. e.g. suppose for some problem we might need to define equivalence classes for infinite number of days.

first day of month

middle day of month

last day of month

last day of year

28th of February, non-leap year

28th of February, leap year

29th of February, leap year

In this way we surely bring down the number of test cases but equivalence partitioning may not check unexpected input as 32nd of November.

Equivalence Partitioning Example

Grocery Store Example

Consider a software module that is intended to accept the name of a grocery item and a list of the different sizes the item comes in, specified in ounces. The specifications state that the item name is to be alphabetic characters 2 to 15 characters in length. Each size may be a value in the range of 1 to 48, whole numbers only. The sizes are to be entered in ascending order (smaller sizes first). A maximum of five sizes may be entered for each item. The item name is to be entered first, followed by a comma, then followed by a list of sizes. A comma will be used to separate each size. Spaces (blanks) are to be ignored anywhere in the input.

Derived Equivalence Classes

1. Item name is alphabetic (valid)
2. Item name is not alphabetic (invalid)
3. Item name is less than 2 characters in length (invalid)
4. Item name is 2 to 15 characters in length (valid)
5. Item name is greater than 15 characters in length (invalid)
6. Size value is less than 1 (invalid)
7. Size value is in the range 1 to 48 (valid)
8. Size value is greater than 48 (invalid)
9. Size value is a whole number (valid)
10. Size value is a decimal (invalid)
11. Size value is numeric (valid)
12. Size value includes nonnumeric characters (invalid)
13. Size values entered in ascending order (valid)
14. Size values entered in nonascending order (invalid)
15. No size values entered (invalid)
16. One to five size values entered (valid)
17. More than five sizes entered (invalid)
18. Item name is first (valid)
19. Item name is not first (invalid)
20. A single comma separates each entry in list (valid)
21. A comma does not separate two or more entries in the list (invalid)
22. The entry contains no blanks (???)
23. The entry contains blanks (????)

Black Box Test Cases for the Grocery Item Example based on the Equivalence Classes Above.

#	Test Data	Expected Outcome	Classes Covered
1	xy,1	T	1,4,7,9,11,13,16,18,20,22
2	AbcDefghijklmno,1,2,3 ,4,48	T	1,4,7,9,11,13,16,18,20,23
3	a2x,1	F	2
4	A,1	F	3
5	abcdefghijklmnop	F	5
6	Xy,0	F	6
7	XY,49	F	8
8	Xy,2.5	F	10
9	xy,2,1,3,4,5	F	14
10	Xy	F	15
11	XY,1,2,3,4,5,6	F	17
12	1,Xy,2,3,4,5	F	19
13	XY2,3,4,5,6	F	21
14	AB,2#7	F	12

UML : Relationships

Association relationships

In UML models, an association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.

An association represents a structural relationship that connects two classifiers. Like attributes, associations record the properties of classifiers. For example, in relationships between classes, you can use associations to show the design decisions that you made about classes in your application that contain data, and to show which of those classes need to share data. You can use an association's navigability feature, to show how an object of one class gains access to an object of another class or, in a reflexive association, to an object of the same class.

The name of an association describes the nature of the relationship between two classifiers and should be a verb or phrase.

In the diagram editor, an association appears as a solid line between two classifiers.

Association ends

An association end specifies the role that the object at one end of a relationship performs. Each end of a relationship has properties that specify the role of the association end, its multiplicity, visibility, navigability, and constraints.

Example

In an e-commerce application, a customer class has a single association with an account class. The association shows that a customer instance owns one or more instances of the account class. If you have an account, you can locate the customer that owns the account. Given a particular customer, you can navigate to each of the customer’s accounts. The association between the customer class and the account class is important because it shows the structure between the two classifiers.

Generalization relationships

In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use-case diagrams to indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent.

To comply with UML semantics, the model elements in a generalization relationship must be the same type. For example, a generalization relationship can be used between actors or between use cases; however, it cannot be used between an actor and a use case.

You can add generalization relationships to capture attributes, operations, and relationships in a parent model element and then reuse them in one or more child model elements. Because the child model elements in generalizations inherit the attributes, operations, and relationships of the parent, you must only define for the child the attributes, operations, or relationships that are distinct from the parent.

The parent model element can have one or more children, and any child model element can have one or more parents. It is more common to have a single parent model element and multiple child model elements.

Generalization relationships do not have names.

As the following figures illustrate, a generalization relationship is displayed in the diagram editor as a solid line with a hollow arrowhead that points from the child model element to the parent model element.

Single parent with a single child	Single parent with multiple children

Example

The following figure illustrates an e-commerce application for a Web site that sells a variety of merchandise. The application has an InventoryItem class that is a parent class (also called a superclass). This class contains the attributes, such as Price, and operations, such as setPrice, that all pieces of merchandise use.

After defining the parent class, a child class (also called a subclass) is created for each type of merchandise, such as books and DVDs. The book class uses the attributes and operations in the inventory class and then adds attributes such as author and operations such as setAuthor. A DVD class also uses the attributes and operations in the inventory class, but it adds attributes such as manufacturer and operations such as setManufacturer, which are different from those in the book class.

Include relationships

In UML modeling, an include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use-case model.

You can add include relationships to your model to show the following situations:

• The behavior of the inclusion use case is common to two or more use cases.
• The result of the behavior that the inclusion use case specifies, not the behavior itself, is important to the base use case.

Include relationships usually do not have names. If you name an include relationship, the name is displayed beside the include connector in the diagram.

As the following figure illustrates, an include relationship is displayed in the diagram editor as a dashed line with an open arrow pointing from the base use case to the inclusion use case. The keyword «include» is attached to the connector.

Example

The following figure illustrates an e-commerce application that provides customers with the option of checking the status of their orders. This behavior is modeled with a base use case called CheckOrderStatus that has an inclusion use case called LogIn. The LogIn use case is a separate inclusion use case because it contains behaviors that several other use cases in the system use. An include relationship points from the CheckOrderStatus use case to the LogIn use case to indicate that the CheckOrderStatus use case always includes the behaviors in the LogIn use case.

Extend relationships

In UML modeling, you can use an extend relationship to specify that one use case (extension) extends the behavior of another use case (base). This type of relationship reveals details about a system or application that are typically hidden in a use case.

The extend relationship specifies that the incorporation of the extension use case is dependent on what happens when the base use case executes. The extension use case owns the extend relationship. You can specify several extend relationships for a single base use case.

While the base use case is defined independently and is meaningful by itself, the extension use case is not meaningful on its own. The extension use case consists of one or several behavior sequences (segments) that describe additional behavior that can incrementally augment the behavior of the base use case. Each segment can be inserted into the base use case at a different point, called an extension point.

The extension use case can access and modify the attributes of the base use case; however, the base use case is not aware of the extension use case and, therefore, cannot access or modify the attributes and operations of the extension use case.

You can add extend relationships to a model to show the following situations:

• A part of a use case that is optional system behavior
• A subflow is executed only under certain conditions
• A set of behavior segments that may be inserted in a base use case

Extend relationships do not have names.

As the following figure illustrates, an extend relationship is displayed in the diagram editor as a dashed line with an open arrowhead pointing from the extension use case to the base use case. The arrow is labeled with the keyword «extend».

Example

You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case called Specify Shipping Instructions. An extend relationship points from the Specify Shipping Instructions use case to the Place Online Order use case to indicate that the behaviors in the Specify Shipping Instructions use case are optional and only occur in certain circumstances.

Use Case Template

Use Case:{number}[the name should be the goal as a short active verb phrase]

Goal in Context:[a longer statement of the goal, if needed]

Scope:[what system is being considered black-box under design]

Level:[one of: Summary, Primary task, Subfunction]

Primary Actor:[a role name for the primary actor, or description]

Priority:[how critical to your system / organization]

Frequency:[how often it is expected to happen

Use Case Template

Use case name

A use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., Borrow Books, Withdraw Cash), should describe an achievable goal (e.g., Register User is better than Registering User) and should be sufficient for the end user to understand what the use case is about. Goal-driven use case analysis will name use cases according to the actor's goals, thus ensuring use cases are strongly user centric. Two to three words is the optimum. If more than four words are proposed for a name, there is usually a shorter and more specific name that could be used.

Version

Often a version section is needed to inform the reader of the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different from the evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups.

Goal

Without a goal a use case is useless. There is no need for a use case when there is no need for any actor to achieve a goal. A goal briefly describes what the user intends to achieve with this use case.

Summary

A summary section is used to capture the essence of a use case before the main body is complete. It provides a quick overview, which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. Ideally, a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

Actors

An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor. An actor may be a person, a device, another system or sub-system, or time. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified. An individual in the real world can be represented by several actors if they have several different roles and goals in regards to a system. These interact with system and do some action on that.

Preconditions

A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate. Note that the preconditions arenot the same thing as the "trigger" (see below): the mere fact that the preconditions are met does NOT initiate the use case.

However, it is theoretically possible both that a use case should be initiated whenever condition X is met and that condition X is the only aspect of the system that defines whether the use case can meaningfully start. If this is really true, then condition X is both the precondition and the trigger, and would appear in both sections. But this is rare, and the analyst should check carefully that they have not overlooked some preconditions which are part of the trigger. If the analyst has erred, the module based on this use case will be triggered when the system is in a state the developer has not planned for, and the module may fail or behave unpredictably.

Triggers:

A 'triggers' section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. If the trigger is not a simple true "event" (e.g., the customer presses a button), but instead "when a set of conditions are met", there will need to be a triggering process that continually (or periodically) runs to test whether the "trigger conditions" are met: the "triggering event" is a signal from the trigger process that the conditions are now met. There is varying practice over how to describe what to do when the trigger occurs but the preconditions are not met.

• One way is to handle the "error" within the use case (as an exception). Strictly, this is illogical, because the "preconditions" are now not true preconditions at all (because the behavior of the use case is determined even when the preconditions are not met).

• Another way is to put all the preconditions in the trigger (so that the use case does not run if the preconditions are not met) and create a different use case to handle the problem. Note that if this is the local standard, then the use case template theoretically does not need a preconditions section!

Basic course of events

At a minimum, each use case should convey a primary scenario, or typical course of events, also called "basic flow", "happy flow" and "happy path". The main basic course of events is often conveyed as a set of usually numbered steps. For example: The system prompts the user to log on, the user enters his name and password, the system verifies the logon information, and the system logs user on to system.

Alternative paths

Use cases may contain secondary paths or alternative scenarios, which are variations on the main theme. Each tested rule may lead to an alternative path and when there are many rules the permutation of paths increases rapidly, which can lead to very complex documents. Sometimes it is better to use conditional logic or activity diagrams to describe use case with many rules and conditions. Exceptions, or what happens when things go wrong at the system level, may also be described, not using the alternative paths section but in a section of their own. Alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and, if appropriate, where they rejoin. The intention is to avoid repeating information unnecessarily. An example of an alternative path would be: "The system recognizes cookie on user's machine", and "Go to step 4 (Main path)". An example of an exception path would be: "The system does not recognize user's logon information", and "Go to step 1 (Main path)"

According to Anthony J H Simons and Ian Graham (who openly admits he got it wrong - using 2000 use cases at Swiss Bank), alternative paths were not originally part of use cases. Instead, each use case represented a single user's interaction with the system. In other words, each use case represented one possible path through the system. Multiple use cases would be needed before designs based on them could be made. In this sense, use cases are for exploration, not documentation. An Activity diagram can give an overview of the basic path and alternative path.

Post conditions

The post-conditions section describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.

Business rules

Business rules are written (or unwritten) rules or policies that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of requirement. Business rules may be specific to a use case or apply across all the use cases, or across the entire business. Use cases should clearly reference BRs that are applicable and where they are implemented. Business Rules should be encoded in-line with the Use Case logic and execution may lead to different post conditions. E.g. Rule2. that a cash withdraw will lead to an update of the account and a transaction log leads to a post condition on successful withdrawal - but only if Rule1 which says there must be sufficient funds tests as true.

Notes

Experience has shown that however well-designed a use case template is, the analyst will have some important information that does not fit under a specific heading. Therefore all good templates include a section (e.g. "Notes to Developers") that allows less-structured information to be recorded.

Author and date

This section should list when a version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned.

Use Case

A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.

A use case (or set of use cases) has these characteristics:

• Organizes functional requirements

• Models the goals of system/actor (user) interactions

• Records paths (called scenarios) from trigger events to goals

• Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)

• Is multi-level, so that one use case can use the functionality of another one.

• Use cases can be employed during several stages of software development, such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.

What makes up a UML use case diagram?

• Actors: An actor represents a role external to a system that uses or is used by a system. Actors can be shown as boxes marked with an «actor» stereotype or a stick figure. From a stylistic point of view, stick figures are best reserved for human roles. (In spite of technological advances and Hollywood, it looks a little strange to see devices or software systems presented in human form. As an aside, the term actor is somewhat misleading, as we normally think of an actor as someone who plays a role, not as the role itself. To sidestep such confusion an increasing number of practitioners favor the term user role.

An actor represents a role of a user that interacts with the system that you are modeling. The user can be a human user, an organization, a machine, or another external system.

You can represent multiple users with a single actor and a single user can have the role of multiple actors. Actors are external to the system. They can initiate the behavior described in the use case or be acted upon by the use case. Actors can also exchange data with the system.

In models that depict businesses, actors represent the types of individuals and machines that interact with a business. In models that depict software applications, actors represent the types of individuals, external systems, or machines that interact with the system.

You would typically use actors in use-case diagrams, but you can also use them in class and sequence diagrams.

As the following figure illustrates, an actor is displayed as a line drawing of a person.

Each actor has a unique name that describes the role of the user who interacts with the system.

You can add documentation that defines what the actor does and how the actor interacts with the system.

• System boundary: A boundary that separates actors -- which are external to the software system -- from use cases -- which represent goals fulfilled by the system -- makes clear the separation between the software system of interest and the world around the system. It also acts as a reminder that the behavior of the use cases in question is system behavior and not the broader and sometimes less-deterministic and less-biddable behavior of the world around the system that might lead to or be inspired by the use cases. The system box is sometimes treated as an optional presentation feature. Omission makes sense if use cases are used to model a business rather than a software system, but otherwise absence does not make the chart grow sounder.

• Use case

A use case describes a function that a system performs to achieve the user’s goal. A use case must yield an observable result that is of value to the user of the system.

Use cases contain detailed information about the system, the system’s users, relationships between the system and the users, and the required behavior of the system. Use cases do not describe the details of how the system is implemented.

Each use case describes a particular goal for the user and how the user interacts with the system to achieve that goal. The use case describes all possible ways that the system can achieve, or fail to achieve, the goal of the user.

You can use use cases for the following purposes:

• Determine the requirements of the system
• Describe what the system should do
• Provide a basis for testing to ensure that the system works as intended

In models that depict businesses, use cases represent the processes and activities of the business. In models that depict software systems, use cases represent the capabilities of the software.

Each use case must have a unique name that describes the action that the system performs. Use case names are often short phrases that start with a verb, such as Place Order Online.

As the following figure illustrates, a use case is displayed as an oval that contains the name of the use case.

You can add the following features to use cases:

• Attributes that identify the properties of the objects in a use case
• Operations that describe the behavior of objects in a use case and how they affect the system
• Documentation that details the purpose and flow of events in a use case

• Associations between use cases and actors:Actors do not simply sit around resting, and a system's use cases are not orphaned islands of functionality. Associations connect primary actors with the use cases that represent the goals they can have against a system, and they connect secondary actors with the use cases that use them to fulfill goals.

• Relationships between use cases: It is possible for use cases to include, extend or generalize other use cases. In theory the idea that use cases can interrelate, much as classes on a class diagram do, makes sense. The problem is that in practice this aspect of use case diagrams is not only less than useful, it is typically harmful.

Association relationships

In UML models, an association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.

Generalization relationships

In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use-case diagrams to indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent.

Include relationships

In UML modeling, an include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use-case model.

Extend relationships

In UML modeling, you can use an extend relationship to specify that one use case (extension) extends the behavior of another use case (base). This type of relationship reveals details about a system or application that are typically hidden in a use case.

Not only do use case relationships obscure a diagram, disenfranchising all but the UML geeks, but they tend to distract practitioners from the objective of identifying and understanding the system's behavior. Use case diagrams that make use of such relationships often end up degenerating into an ineffective top–down programming model of the system. They are rarely backed up by clear use case descriptions.

There are a couple of other elements that sometimes find their way onto use case diagrams, such as packages, but the ones just listed are the core ingredients that, depending on use, can clarify or obscure the message of a diagram.

The notion that a diagram has a message is perhaps the question we should be asking. Having answered what a use case diagram can show from a technical point of view, we really need to ask what we want or need it to show from an intentional point of view. Unless we have a clear purpose for a diagram, the diagram is likely to end up a confused and aimless exhibition of notation.

What use case diagrams do not show

Use case diagrams do not present architectural models, user-interface models or workflow models. However, this does not appear to stop them from being press-ganged into these roles. It is common to find use case diagrams with extra ad hoc ornamentation. Although well meant, such extras are invariably confusing rather than helpful.

There are better approaches suited to each of these tasks. For architectural models, there are many ways to present and describe architecture, and many viewpoints from which to do so. For user-interface models, UI design is a discipline and activity that is not well addressed by UML, and even less so by use case diagrams. For workflow models, activity diagrams offer a clearer way of organizing flow by considering use cases as activities.

What a use case diagram is good at showing is the system context and a summary of the functional goals fulfilled by the system. In other words, use case diagrams offer a rich "table of contents" but are not themselves the content. They do not illustrate the structure of the software or its required behavior, which is why they are an iconic rather than a schematic concept.

By contrast, a class diagram can illustrate a system's information model or some aspect of design, a textual use case description describes a slice of system behavior, and a state-machine diagram can illustrate an object's lifecycle. All of those are schematic in the sense that something can be built from them and they offer concrete and testable assertions about a system, either from an external or an internal point of view.

The notion that a use case diagram acts like a table of contents, a summary, is one that suggests that use case diagrams are not the only way to present an overview of actors and their goals. A tabular presentation can be just as effective, with actors in one column and their corresponding goals (i.e. use cases) in an adjacent column. Use case diagrams offer a more visual presentation for sketching on whiteboards, but sometimes a tabular presentation is easier to both read and write in word-processed documents and on Wiki pages.

Risk Management

• Identification- define the risks that are likely for the project
• Projection- attempt to indicate the quantitative likelihood that a risk will occur
• Assessment- evaluate accuracy of projections and prioritize risks
• Management and monitoring- move to avert those risks that are of concern and monitor all circumstances that may lead to risk

Risk Identification

è Team

- Inexperienced project leader, project team

- Project team members working part-time

- Multi-departmantal project team

- High turnover

è Customer/user

- Client with low confidence in developer

- Users are threatened by application

- Users won’t spend the time to define

- Multi-departmental users

- Client project rep is part-time

Software Project Planning

Purpose: to provide a faremwork that enables the manager to make reasoble estimates of resources, cost and schedule.

Software Project Planning

o understand the scope of the problem

o make use of past historical data (metrics)

o perform functional decomposition

o estimate effort and/or function and/or size

o perform risk analysis

o develop a work breakdown structure

o define a project schedule

Software Scope:

• Software scope descibes-

– Function - estimation

– Performance – processing and response time requirements

– Constraints – limits placed on the SW by external HW, available memory, etc.

– Interfaces

– Reliability

• The analyst might ask

– Who is behind the request for this work?

– Who will use the solution

– What will be economical benefit of a successful solution

– Is there another source for the solution

• Ask To customer-

– How wouldd you charachterize good output that would be generated by a successful solution?

– What problem(s) will this solution address?

– Can you show me the environment in which the solution will be used

– Are there special performance issues or constraints that will affect the way the solution is approached

Functional Decomposition:

Cost Estimation:

... occasionally we actually estimate costs -most of the

time we merely validate budgetary constraints ...

• project scope must be explicitly defined
• task and/or functional decomposition is necessary
• historical measures (metrics) are very helpful
• at least two different techniques should be used
• remember that uncertainty is inherent

Project Management Concerns

• Product quality

• risk assessment

• measurement

• cost estimation

• projects scheduling

• customer communication

• staffing

• other resources

• project monitoring

Capability Maturity Model (CMM)

• Level l : Initial
• Level 2: Repeatable
• Level 3: Defined
• Level 4: Managed
• Level 5: Optimizing

Level 1: Initial

– adhoc, chaotic, few process defined, success depends on individual

efforts

Level 2: Repeatable

– Project management to track cost,schedule and functionality.

Disciplined to repeat earlier success.

Level 3: Defined

– Management and engineering activities are

documented, standardized and integrated into an organization-wide SW process.

Level 4: Managed

– Detailed measures of SW process and product quality are collected.

Level 5: Defined

– Continuous process improvement by quantitative feedback form process and from testing innovative ideas and technologies.

Change Management & Testing

Reasons for change:

- Elimination of existing defects.

- Adaptation to di erent application environments.

- Alteration in order to improve the quality of the product.

- Extensions in order to meet new requirements.

Testing for change:

- Determine if changes have regressed other parts of the software - regression testing.

- Cost-risk analysis: full regression testing or partial regression testing?

- Effectiveness: automation and persistent test-points.

Software Testing Life Cycle

Test Requirements

· Requirement Specification documents

· Functional Specification documents

· Design Specification documents (use cases, etc)

· Use case Documents

· Test Traceability Matrix for identifying Test Coverage

Test Planning

· Test Scope, Test Environment

· Different Test phase and Test Methodologies

· Manual and Automation Testing

· Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc

· Evaluation & identification? Test, Defect tracking tools

Test Environment Setup

· Test Bed installation and configuration

· Network connectivity

· All the Software/ tools Installation and configuration

· Coordination with Vendors and others

Test Design

· Test Traceability Matrix and Test coverage

· Test Scenarios Identification & Test Case preparation

· Test data and Test scripts preparation

· Test case reviews and Approval

· Base lining under Configuration Management

Test Automation

· Automation requirement identification

· Tool Evaluation and Identification.

· Designing or identifying Framework and scripting

· Script Integration, Review and Approval

· Base lining under Configuration Management

Test Execution and Defect Tracking

· Executing Test cases

· Testing Test Scripts

· Capture, review and analyze Test Results

· Raised the defects and tracking for its closure

Test Reports and Acceptance

· Test summary reports

· Test Metrics and process Improvements made

· Build release

· Receiving acceptance

Boundary Value Analysis

• Based on experience / heuristics

-Testing boundary conditions of equivalence classes is more effective

• Choose input boundary values as equivalence classes representatives
• Choose inputs that invoke output boundary values

Examples:

(0, 10] ⇒ validate using 0, 1, 2, 9, 10, 11

Read up to 5 elements ⇒ validate reading 0, 1, 4, 5, 6 elements

White Box Testing

It is the process of giving the input to the system and checking, how the system processes the input, to generate the output. It is mandatory for a tester to have the knowledge of the source code.

Unit Testing: This type of testing is done at the developer's site to check whether a particular piece/unit of code is working fine. Unit testing deals with testing the unit as a whole.

Static and Dynamic Analysis: In static analysis, it is required to go through the code in order to find out any possible defect in the code. Whereas, in dynamic analysis the code is executed and analyzed for the output.

Statement Coverage: This type of testing assures that the code is executed in such a way that every statement of the application is executed at least once.

Decision Coverage: This type of testing helps in making decision by executing the application, at least once to judge whether it results in true or false.

Condition Coverage: In this type of software testing, each and every condition is executed by making it true and false, in each of the ways at least once.

Path Coverage: Each and every path within the code is executed at least once to get a full path coverage, which is one of the important parts of the white box testing.

The Incremental Model

The Incremental Model combines elements of the Linear Sequential Model (applied repetitively) with the iterative philosophy of prototyping. When an Incremental Model is used, the first increment is often the “core product”. The subsequent iterations are the supporting functionalities or the add-on features that a customer would like to see. More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished.

Increment 1: Analysis-->Design-->Code-->Test (Delivery of 1st Increments. Normally '''Core Product''')

Increment 2: Analysis-->Design-->Code-->Test (Delivery of 2nd Increments)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Increment n: Analysis-->Design-->Code-->Test (Delivery of nth Increments)

Advantages:

• It is useful when staffing is unavailable for the complete implementation.
• Can be implemented with fewer staff people.
• If the core product is well received then the additional staff can be added.
• Customers can be involved at an early stage.
• Each iteration delivers a functionally operational product and thus customers can get to see the working version of the product at each stage.

Functional Analysis:

• Analyze the expected behavior of the system according to its functional specification

• Generate a test procedure for each of the possible usage scenarios

- Corresponds to use case scenarios

- Analyze how a change in one part of the system affects other parts

- “Grand tour” test cases: the result of one test case produces the data that is the input to the next test case