Testing Life Cycle

System Study:

Making documents of

1. Domain Knowledge :- Used to know about the client business

Banking / Finance / Insurance / Real-estates / ERP / CRM / Others

2. Software : -

Front End (GUI) VB / JAVA/ FORMS / Browser

Process Language witch we want to write programmes

Back End Database like Oracle, SQL Server etc.

3. Hardware: - Internet/ Intranet/ Servers which you want to install.

4. Functional Points: - Ten Lines Of Code (LOC) = 1 Functional Point.

5. Number of Pages: - The document which you want to prepare.

6. Number of Resources: -Like Programmers, Designers, and Managers.

7. Number of Days: - For actual completion of the Project.

8. Numbers of Modules

9. Priority:- High/ Medium/ Low importance for Modules

Scope/ Approach/ Estimation:

Scope:- What to be tested

What not to test

Approach:- Testing Life Cycle

Estimation:- Based on LOC/ FP/Resources

• 1000 = 100 FP (10 LOC = 1 FP)

· 100 x 3 = 300 (FP x 3 Tech. = Test Cases) The 3 Tech are

1. Equivalence Class:

2. Boundary Value Analysis

3. Error Guessing.

• 30 TC Par Day => 300/30 = 10 Days to Design Test Cases
• Test Case Review => ½ of Test Case Design (5 Days)
• Test Case Execution = 1 ½ of Test Case Design(15 Days)
• Defect Headlining = Test Case Design (5 Days)
• Test Plan = 5 days ( 1 week )
• Buffer Time = 25% of Estimation

Test Plan Design:

The Test Plan Design document helps in test execution it contain

1. About the client and company
2. Reference document (BRS, FRS and UI etc.)
3. Scope (What to be tested and what not to be )
4. Overview of Application
5. Testing approach (Testing strategy)
6. For each testing
• Definition
• Technique
• Start criteria
• Stop criteria

7. Resources and there Roles and Responsibilities

8. Defect definition

9. Risk / Contingency / Mitigation Plan

10. Training Required

11. Schedules

12. Deliverables

Test Cases Design:

What is a test case?

Test case is a description of what to be tested, what data to be given and what actions to be done to check the actual result against the expected result.

What are the items of test case?

Test case items are:

Test Case Number

Pre-Condition

Description

Expected Result

Actual Result

Status (Pass/Fail)

Remarks.

Can this test cases reusable?

Yes, Test cases can be reusable.

Test cases developed for functionality testing can be used for Integration/System/Regression testing and performance testing with few modifications.

What are the characteristics of good test case?

A good test case should have the following:

TC should start with “what you are testing”.

TC should be independent.

TC should not contain “If” statements.

TC should be uniform.

Eg. , “Links”…

Are there any issues to be considered?

Yes there are few Issues:

All the TC’s should be traceable.

There should not be too many duplicate test cases.

Out dated test cases should be cleared off.

All the test cases should be executable.

TC ID	Pre-Condition	Description	Expected Result	Actual Result	Status	Remarks
Unique TestCase number	Condition to satisfied	1. What to be tested what data to provided what action to be done	As pear FSR	System response	Pass or Fail	If any
Yahoo-001	Yahoo web page should displayed	1. Check inbox is displayed 2. User ID/PW 3. Click on Submit	System should mail box	System response

Test Case Review:

Peer to peer Reviews

Team Lead Review

Team Manager Review

Review Process

Review Format

Review-ID	Origin	Description	Status	Priority
Unique ID	Birth place From where it starts	Test Case description	Open/ Close	Major Medium Minor

Test Case Execution:

Execution and execution results plays a vital role in the testing. Each and every activity should have proof.

The following activities should be taken care:

1. Number of test cases executed.

2. Number of defects found

3. Screen shoots of successful and failure executions should be taken in word document.

4. Time taken to execute.

5. Time wasted due to the unavailability of the system.

Test Case Execution Process:

Take the Test Case document

Check the availability of application

Implement the Test Cases

Raise the Defects

Inputs

-Test Cases

-System Availability

-Data Availability

Process

-Test it

Output

-Raise the Defects

-Take screen shoot & save it

Defect Handling

What is Defect?

In computer technology, a Defect is a coding error in a computer program. It is defined by saying that “A software error is present when the program does not do what its end user reasonably expects it to do”.

Who can report a Defect?

Anyone who has involved in software development life cycle and who is using the software can report a Defect. In most of the cases defects are reported by Testing Team.

A short list of people expected to report bugs:

Testers / QA Engineers

Developers

Technical Support

End Users

Sales and Marketing Engineers

Defect Life Cycle

Defect Life Cycle helps in handling defects efficiently. This DLC will help the users to know the status of the defect.

Types of Defects

Cosmetic flaw

Data corruption

Data loss

Documentation Issue

Incorrect Operation

Installation Problem

Missing Feature

Slow Performance

System Crash

Unexpected Behavior

Unfriendly behavior

How do u decide the Severity of the defect

Severity Level	Description	Response Time or Turn-around Time
High	A defect occurred due to the inability of a key function to perform. This problem causes the system hang it halts (crash), or the user is dropped out of the system. An immediate fix or work around is needed from development so that testing can continue.	Defect should be responded to within 24 hours and the situation should be resolved test exit
Medium	A defect occurred which severely restricts the system such as the inability to use a major function of the system. There is no acceptable work-around but the problem does not inhibit the testing of other functions	A response or action plan should be provided within 3 working days and the situation should be resolved before test exit.
Low	A defect is occurred which places minor restrict on a function that is not critical. There is an acceptable work-around for the defect.	A response or action plan should be provided within 5 working days and the situation should be resolved before test exit.
Others	An incident occurred which places no restrictions on any function of the system. No immediate impact to testing. A Design issue or Requirements not definitively detailed in project. The fix dates are subject to negotiation.	An action plan should be provided for next release or future enhancement

Defect Severity VS Defect Priority

The General rule for the fixing the defects will depend on the Severity. All the High Severity Defects should be fixed first.

This may not be the same in all cases some times even though severity of the bug is high it may not be take as the High priority.

At the same time the low severity bug may be considered as high priority.

Defect Tracking Sheet

Defect No	Description	Origin	Severity	Priority	Status
Unique No	Dec of Bug	Birth place of the Bug	Critical Major Medium Minor Cosmetic	High Medium Low	Submitted Accepted Fixed Rejected Postponed Closed

Defect Tracking Tools

Bug Tracker -- BSL Proprietary Tools

Rational Clear Quest

Test Director

Gap Analysis:

1. BRS Vs SRS

BRS01 – SRS01

-SRS02

-SRS03

2. SRS Vs TC

SRS01 – TC01

- TC02

- TC03

3. TC Vs Defects

TC01 – Defects01

– Defects02

Deliverables:

All the documents witch are prepared in each and every stage. Like FRS, SRS, Use Cases, Test Plain, Defect Report, Review Report ect,.