Top Banner
Strategies For Software Test Documentation Suriya G (suriyag at vishwak.com) Vishwak Solutions Pvt. Ltd.
21

Strategies For Software Test Documentation

Jan 20, 2015

Download

Technology

Strategies For Software Test Documentation by Suriya G of Vishwak.com for Anna University Workshop on testing
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Strategies For Software Test Documentation

Strategies For Software Test Documentation

Suriya G(suriyag at vishwak.com)Vishwak Solutions Pvt. Ltd.

Page 2: Strategies For Software Test Documentation

Software Testing

• Software Testing is a process of evaluating a system against the requirements.

• The testing can be done either Manually or by using Automated testing tools.

• By giving Quality deliverables, Customer satisfaction is ensured.

Page 3: Strategies For Software Test Documentation

Principle of Testing

Testing is the process of executing a program with an

intent of finding error and it should be planned well

before testing begins.

Objective of Software Tester

•The goal of a Tester is to find defects.•The goal of a Tester is to find defects as early as possible.•The goal of a Tester is to find defects and fix them.

Page 4: Strategies For Software Test Documentation

What is Defects ?

There are various ways in which we can classify Defects. Below are some of the classifications:

• Wrong: The specifications have been implementedincorrectly. This defect is a variance from customer / userspecification. (correctly mentioned in specification butwrongly implemented)

• Missing: A specified or wanted requirement is not in the built product. This can be a variance from specification, an indication that the specification was not implemented. (given in specification but missed out in application)

• Extra: A requirement incorporated into the product thatwas not specified. This is always a variance fromspecifications, But this could be desired feature for the product. (Good to have)

Page 5: Strategies For Software Test Documentation

Verification and Validation (V&V)

• Verification: Refers to the set of activities that ensure the software correctly implements a specific function.

"Are we building the product right "

• Validation: Refers to a different set of activities that ensure the software that has been built is traceable to customer requirements.

"Are we building the right product "

Page 6: Strategies For Software Test Documentation
Page 7: Strategies For Software Test Documentation

Software Testing Documentation

KISS principle  - Rule for testing processes

(an abbreviation for Keep It Smart, Short )

• Test Plan.• Test Case.• Test Procedure.• Test Log.• Test Report.

Page 8: Strategies For Software Test Documentation

Testing Process

Test PlanDefine

Test Cases

Create TestData

ExecuteTests

Analyzeresults

Require Analysis & Design

TrackDefects

Page 9: Strategies For Software Test Documentation

Definition of Test Plan:

• A document describing the scope, approach, resources, and schedule of intended testing activities.

Table of contents of a test plan might contain the following.

• Roles & Responsibilities• Testing Schedules (testing tasks and milestones)• Environment Needs (hardware and software)• Test Items (what should be tested)• Risk and Constraints• Test Recording procedures (test results must be

systematically recorded)

Page 10: Strategies For Software Test Documentation

Sample Page for Test Case

Page 11: Strategies For Software Test Documentation

Definition of Test Case:

• A set of test inputs, executions, and expected results developed for a particular objective.

• Set of procedures written by a tester which execute in our system to find defect.

-Positive test case.

-Negative test case.

• A test case is said to be effective only when both positive and negative cases are prepared.

Page 12: Strategies For Software Test Documentation

Definition of Test Procedure:

• A document, providing detailed instructions for the [manual] execution of one or more test cases.

• The procedure document describes how the tester will actually run the test, the physical set-up (Environment) required, and the procedures or steps that need to be followed.

Page 13: Strategies For Software Test Documentation

Definition of Test Log:

• The Test Log records the details of what Test Cases have been run, the order of running, and the results of those tests.

• The results are either the test passed, meaning that the actual and expected results were identical, or it failed meaning that there was a discrepancy.

• If there is a discrepancy than one or more Test Incident Reports are raised or updated, and their identities recorded on the Test Log.

Page 14: Strategies For Software Test Documentation

There are many way to have the sources of the document. Like Google docs,share point , VSS(Visual Sources Safe), etc...

Depositary of Document:

Page 15: Strategies For Software Test Documentation

Definition of Test Report:

• To gratify the customer or client’s demand; one must perform complete software testing activities on the application before the deployment as its stated that “No

Software Exists Without a BUG”; while performing those actions if any ambiguity found then the tester should report the bug and notify the developer.

• Elimination of bug from the software needs to follow the proper steps formerly known as BUG LIFE CYCLE; the structure of it varies from organization to organization but the basic flow will remain the same.

Page 16: Strategies For Software Test Documentation

Bug life cycle Test

Open

Assign

Fixed

Re-Test

Closed

Deferred Re-Open

Page 17: Strategies For Software Test Documentation

Bug Life Cycle and Description

• Open: Tester finds a ‘bug’ and posts it with the status OPEN. This bug is yet to be studied/assigned.

• Assign: The assigned Developer’s responsibility is now to fix the bug and have it RESOLVED or give valid reasons.

• Resolved: Developer fixes the bug that is ASSIGNED. Now, the ‘resolved’ bug needs to be verified by the Tester (retesting / regression .

Page 18: Strategies For Software Test Documentation

• Bug Life Cycle and Description

• Deferred / Waived: If lead / verifier / developer considers that the bug is “Not valid” then they should give valid reasons to change the status to Deferred or Waived.

• Re-Opened: If bug still exists not satisfied with the solution in the new build then tester should open the bug again by selecting the status as RE-OPENED.

• Closed: If bug is successfully resolved and verified by the tester then its status should be marked as CLOSED.

Page 19: Strategies For Software Test Documentation

Priority and Severity• Severity - Severity is how seriously the bug is impacting the application• Priority - Priority is the order in which developer has to fix the bug.

• High Priority & High Severity: A show stopper error which occurs on the basic functionality of the application. (E.g.. A site maintains the student details on saving record if it doesn't allow to save the record then this is high priority and high severity bug.)

• High Priority & Low Severity: The spell mistakes that happens on the cover page or heading or title of an application.

• High Severity & Low Priority: The application generates a show stopper or system error but on click of link which is rarely used by the end user.

• Low Priority and Low Severity: Any cosmetic or spell issues which is with in a paragraph or in the report (Not on cover page heading title).

Page 20: Strategies For Software Test Documentation

Summary • Software Testing - A process of evaluating a system against the requirements.

• Software Tester - The goal of a Tester is to find defects as early and fix them.• Defects - Wrong, Missing and Extra• V&V - Verification "Are we building the product right " and Validation "Are we

building the right product " • Testing Documentation - Test Plan, Test Case, Test Procedure, Test Log, Test

Report. • Test Plan - A document describing the scope, approach, resources, and

schedule of intended testing activities. • Test Case - A set of test inputs, executions, and expected results developed

for a particular objective. • Test Procedure - A document, providing detailed instructions for the execution

of one or more test cases. • Test Log - The Test Log records the details of what Test Cases have been run,

the order of running, and the results of those tests. • Test Report - while performing test actions if any ambiguity found then the

tester should report the bug and notify the developer.

Page 21: Strategies For Software Test Documentation

Thank You !!!!!!!!