Verify Area Code:-

 Boundary Value Analysis for Area Code (Size):- Equalance Class Partition for Area Code

Min = Max = 3 Digits  Pass Valid Invalid Min = Max = 2 Digits  Error 0 – 9 A - Z

Min = Max = 4 Digits  Error Blank Space Special Symbols Blank Space  Pass a – z 3. Verify Prefix: -



Boundary Value Analysis for Prefix (Size): - Equalance Class Partition for Prefix Min  200  Pass Valid Invalid

Max  999  Pass 0 – 9 A - Z Min – 1  199  Fail (but 0 & 1 a - z

Min + 1  201  Pass should be Special Symbols Max – 1  998  Pass starts)

Max + 1  1000  Fail 2. Verify Suffix:-

 Boundary Value Analysis for Suffix (Size):- Equalance Class Partition for Suffix

Min = Max = 6 Digits  Pass Valid Invalid Min = Max = 5 Digits  Error 0 – 9 A - Z

Min = Max = 7 Digits  Error Special Symbols a – z Depositor Name Area Code Prefix Suffix Command Submit

Test case for SBI: - Test Case Id Test Case Name Step Name

Description Expected Results

TC_UC_004 Verify the Balance text fields

Functionality

Step 1 Purpose:- The purpose of this

test case is to validate text field available in balance form

Actors:- User

Pre-Condition:- User should

existed with balance account. Step 2 Open IE and enter URL:

www.sbi.com and click on Go button.

User / System is display with home page of SBI Bank with different links successfully. Step 3 Click on login menu link. User / System is displayed

with login page with the following filed

Account Number: Text Password : Text Sign in : Button Step 4 Enter Account Number &

Password & Click on Sign in button.

User / System is displayed with “Welcome to SBI” Bank page with different links. Step 5 Navigate to Balance menu link User/System is displayed

with Balance page with the following fields like Depositor Name, Area Code, Prefix, Suffix, Command & Submit button

Step 6 Enter valid text in all the above text fields and select any one of the option from command drop down & click on Submit button.

User/System is displayed with home page of any one of the option that is selected in command drop down. Step 7 Repeat Step no. (6) for the

remaining options available in command drop down.

User/System is displayed with home page of any one of the option that is selected in command drop down Step 8 Enter all the fields except Area

Code and select any one of the option form command click on submit button.

No Error Message should be display to the user.

Step 9 Enter Invalid text in any one of the filed & select any option from command and click on submit button.

User is displayed with alert message.

(VI) Review Testing Cases: -

After completion of developing Test cases for the current version of all functionality QA Lead or QA Manager will concentrated to review all the test cases for the completeness & correctness, and develop a documentation called as Requirement Traceable Matrixes (RTM) or Validation Traceable Matrixes (VTM). This document defines mapping between the developer test case and the customer requirements.

BRS, Use Case Design

Document Developed Test Cases

Login Steps ********* ********* ********* Deleting *********

New Student Profile

Steps

********* *********

********* Adding *********

In the above review documents developed by QA Leas or QA Manager in order to maintain completeness & correctness of all test cases. And they will decide what the test cases to be done under Manual are & what are the test cases to be done under Automation. This is the finalized document for entire application testing.

Build Version Control: -

Old Version Modify Build New Version

FTP / IP Create New Folder. New Version

Fig: - Build Version Control

After completion of entire development team process deployment team will concentrate to deploy the current version build into soft base in server with respected to supported software’s.

A tester will download the current version through FTP / IP in to they system and they installed the current version according to the initialization guide line by the development team. To maintain all types of version like, New, Old & Modified build are versions they may use configuration management tools like Visual Source Safe (VSS) & Congruent Version System (CVS) or Quality Center 10.

A developer will mail to testing team regarding URL to work with local system, IP address to work with remote system and also initializations instructions if required.

Build +

Supported Software

Soft base in Server

QA Environment

QA Team Hospital B_00.1 Install

Test Harshness: - The application which is readiness to go for the test execution is called as Test Harshness.

Test Cases Software & Hardware (VII) Test Execution: -

After completion of entire development team process a tester will receive initial build from development team and once they complete installing successfully they can test the applications in two types there are 1. Manual Testing. 2. Automation Testing.

To executed the application a tester will follow the below testing work flow.

Development Stage Testing Stages

(BVT / TAT / BLT / TT / OT / DT) Level-0  Smoke / Sanity Testing

If all Test Case Pass If any Test Case Fail

Smoke Test Case Fail

Resolve If Possible  Automation Testing.

(Defect) Real Time Testing (P0, P1 & P2) Entire functionality Testing

Fix the Defect Level – 1  Comprehensive Testing (Stop & Forward)

Modify Build

Level – 2  Regression Testing.

Master Build

Level – 3  Final Regression Testing. High Bug density

Fig: - Work Flow Execution Testing

Level – 0: - This is the first process which should be following for every version testing in order to verify

the stability of the application. This can be followed both Manual Testing & Automation Testing. During this process a tester have to verify the basic functionality like checking every menu link & entire some valid or invalid data, to check whether accepting or not etc. A tester will follow the below 8 factors (Octangle Factors) are:

1. Understandable 2. Maintainable 3. Operate able 4. Controllable 5. Simplicity 6. Consistency 7. Testable 8. Automoble

The above 7 factors are followed for Manual Testing Process and 8th _{Factor is Automation Testing.}

If any one of the factor is failure tester can reject the initial build.

Test Harshness = Test Bed + Test Environment

Level – 1: - After complete of all possible Smoke/Sanity testing testers will concentrate to execute the

entire functionality test cases like Basic Functionality (P0), General Functionality (P1) and Cosmetic Functionality (P2). During test execution, a tester has to compare the given expected results with application behavior values in step by step and they need to maintain documentation is called as “Test Logs”.

Test Logs: - 1. Passed 2. Failed

3. Not Completed 4. No Run

5. Deferred 6. Blocked.

During execution, if tester is finding any mismatches they need to reports Log CR’s (Change Request) in to defect tracking tool

Level – 2: - Regression Testing.

Level – 3: - This level of testing is followed on the Master Build or High Bug density

•

Master Build: - The product / application which is readiness to release the customer or the product / application which is totally free from bugs.

•

High Bug density: - The average number of bugs found in a modules.

This level testing is following once again to on Master build to ensure bug fix works & accuracy of any side effects.

(VIII) Test Logs (Results): -

A tester has to compare the given expected results with application behavior values in step by step and they need to maintain documentation is called as “Test Logs”.

Test Logs: - 1. Passed 2. Failed

3. Not Completed 4. No Run

5. Deferred 6. Blocked.

During execution, if tester is finding any mismatches they need to reports Log CR’s (Change Request) in to defect tracking tool

(IX) Test Reporting: -

During Level – 1 execution if tester are finding any defects or mismatches they need to log those issues into a defect tracking tool like Quality Center (QC) & Clear Quest or Bugzilla etc., are some time a tester can report through Excel sheet format. To report the defects a tester may follows IEEE format in order to maintain better planning for the entire test cases.

IEEE Format: - (In Excel Sheets)

1.

Defect Id:- The name of the defect or Unique number of defect.

2.

Summary / Headline: - A tester has to give Headline of the above defect.

3.

Example: - Steps to reproduces 1. Enter URL

2. Select One way option ……. And soon. Expected Results: -

The list of Flights should not be given.

Defect: - The above expected results not reach the customer request. User is display with list of Flights instant of getting message for more information see the attached word document.

4. Defected By: - The Name of the tester by whom is above defect is found (Shaik Mohammad Fareed)

5. Detected On: - The date & time on which above defect is found (05/24/2010 8:15:25)

6. Priority: - Priority has decided by the “Developer Team” during defect review meeting. In real time weekly once they will conduct defect review meeting. Where test lead, development lead & program manager will participate to assign priority level of depending up severity levels given by QA Team. Priority List:-

Priority

ID Priority Level Priority Description

1 Must Fix This bug must be fixed immediately the product cannot ship with this bug. 2 Should Fix These are important problems that should be fixed as soon as possible. If

would be an embarrassment to the company if this bug shipped.

3 Fix when

Have time The Problem should be fixed within the time available. If the bug does not delay shipping date, then fix it.

4 Low

Priority It is not important (at this time) that these bugs be addressed fix these bug after all other bugs have been fixed. 7. Severity: - This is assigned by QA Team depending upon applications requirement. In general they are 4 types of severities?

1. Very High Severity 2. High Severity 3. Medium Severity 4. Low Severity A tester has to give severity level by following the below table.

Severity

ID Severity Level Severity Description

1 Crash The module / product crashes or the bug causes non-recoverable conditions. System crashes, GP (Graphical Points), faults or database or file corruption or potential data loss, program hangs requiring reboot are all examples of a Severity 1 bug.

2 Major Major system component unusable due to failure or incorrect functionality Severity 2 bugs, cause serious problems such as a lack of functionality or insufficient or unclear errors messages that can have a major impact to the user, prevents other areas of the application from being tested etc. Severity 2 bugs can have a work around, but the work around is inconvenient or difficult.

3 Minor Incorrect functionality of component or process. These are a simple work around for the bug if it is Severity 3.

8. Detected in Version: - The name of the Version in which the above defect is found. 9. Reproduciable (Yes/No):-

If Yes: - The defect is “always appearing” the tester can select Yes.

If No: - The defect is “rarely appearing” the tester has to select No and should give strong reason for developer to understand by given the snapshots.

10. Status: - A tester has to select status of the defect depending upon the type of the defect.

•

New: Defect found first time in application

•

Open: Entering the defect for first time.

•

Resolved: Developer will changes to resolved status when ever it is fixed.

•

Close: After retesting the defect a tester will close by given some QA Notes, if it is working as per expected.

•

Duplicate: If the defect already exists a developer can changed to duplicate.

•

Deferred: Postponing a defect if it is related to enchantment or if the defect is low priority or low severity.

•

Submitted : When we entered a defect into a defect tracking tool. If it is a default status, called as submitted.

•

In-Progress: When ever a developer is working on any issues the status of the defect is will be in progress.

•

Assigned: when ever defect is assigned to one concerned developer then status will be assigned.

•

Enchantment: when the tester entered defect is not related to current version testing then they

will change to enchantment.

11. Functional Area: - A tester has to select concerned module for the above defect or selecting a module to which it is belonging.

12. Sub-Functional Area: - A tester has to select the sub functionality to which the above defect is belonging.

13. Defect Type:- A tester has to select the type of the defect that is entered. Default defect type is ‘Code’ 14. Target to release: - A Manager / Team Lead will be stated the target version which should fixed by the developer.

15. Fixed On (By Developer): - Date & Time on which the above defect is accepted. 16. Solved On (By Developer): - Date & Time on which the above defect is resolved. 17. Approval: - Signature of the QA Manager, Product manager etc.

NOTE: - When tester are reporting defects through Excel Sheets they need to attached Excel Sheet through Outlook or Louts Notes.

Error, Defect & Bug:-

Error: - The mistake had done by human being while coding software during Unit Testing is called an Error. An Error can lead to failure which cans leads to fault.

Defect: - The mismatch which occurred during our test execution when comparing expected results with application behavior values.

(or)

The functionality which is not behaving as per customer expected business requirements. A defect can also found the customer during production.

Bug: - The defect which is accepted by the developer to resolve it is called as Bug. Defect Age: - The time gap between defected on and re-solved on is called defect age. Defect Life Cycle: -

In document Testing Material (Page 36-43)