Prasanna

N U A TESTING

Testing is a Process in which the defect are identified, isolated, subjected for rectification and ensure that the product is defect free in order to produce a quality product in the end and hence customer satisfaction.

BIDDING THE PROJECT Bidding the Project is defined as request for proposal, estimation and Sign-Off.

KICKOFF MEETING: Kick-Off Meeting is the initial meeting held in the software company soon after the project is Sign-Off in order to discuss the overall view of the Project and to select a Project Manager.
N O T E : Pr oje c t Ma na ge r s (PM ) , Te a m Ma nag e rs (T M ), S of t ware Qual i ty Ma na ge rs , Te s t le ad s and Hi g h le ve l M an age me n t wi ll be in v olve d i n t hi s me e t in g .

SDLC (S OFTWARE D EVELOPMENT L IFE C YCLE )

There are 6 phases in the development cycle. 1. Initial Phase / Requirement Phase. 2. Analysis Phase. 3. Design Phase. 4. Coding Phase. 5. Testing Phase. 6. Delivery & Maintenance Phase.

1. I NITIAL P HASE :
T A S K : Interacting the customer and gathering the Requirements. R O LE S : Business Analyst (BA), Engagement Manager (EM).

PROCESS: First of all the Business Analyst will take an appointment from the customer. Collect the template from the company and meets the customer on the appointed date and gather the requirements with the help of Template. If at all any requirements are given by the customer then the Engagement Manager is responsible for the excess cost of the Project. He also responsible for prototype demonstration.

Template is a predefined format which is used to prepare any document. Prototype is a roughly and rapidly developed model which is used for gathering the clear requirements and to win the confidence of a customer.

P RO O F :

The proof document of initial phase is FRS (Functional Requirement Specification). This doc can also be called as CRS (Customer Requirement Specification) BRS (Business Requirement Specification) BDD (Business Development Document) BD (Business Document)

NOTE:

FRS.

So me C o m pa ny wi ll be pu t ti n g t he Bu si ne s s ove r all fl o w o f t he a p pl ic a ti o n i n t he BR S a nd d e ta ile d r e quire me n t i nf or mat i o n i n

2. A NALYSIS P HASE :
TASK: Feasibility Study, Tentative Planning, Technology Selection, Requirement Analysis

R O LE S : SA (System Analyst), PM (Project Analyst), TM (Team Manager)

Feasibility Study is a detailed study of the requirement in order to check whether the requirements are possible or not. Tentative Planning is Resource planning and time planning is temporarily done here in this session. Technology Selection All the technologies that are required to accomplish the project successfully will be selected and listed out in this session. Requirement Analysis What are all the requirements that are require to accomplish the project successfully will be analyzed and listed out here in this session. SRS (System Requirement Specification ): The proof Document of Analysis Phase is SRS; requirements may be Hardware requirements or Software requirements.

3. D ESIGN P HASE :
T A S K : High Level Designing (HLD), Low Level Designing (LLD)

R O LE S : HLD is done by CA (Chief Architect) LLD is done by TL (Technical Lead)

PROCESS: High Level Designing is a process of dividing the whole project in to the modules with the help of some diagrams. Low Level Designing is a process of dividing a module in to sub modules with the help of some diagrams.

NOTE:

These diagrams are designing by using a language called Unified Modeling Language (UML).

The Proof Document on this phase is Technical Diagram Document (TDD). TDD contains some diagrams and Pseudo Code.

PSEUDO CODE:

Pseudo Code is not a real code, but a set of English statements which are very much used by the developers to develop the actual code.

4. C ODING P HASE :

T A S K : Developing. R O LE S : Developers.

PROCESS: The developers will develop the actual code using the pseudo code and following the coding standards with proper indentation, color coding and proper commenting, etc.

5. T ESTING P HASE :
T A S K : Testing. R O LE S : Test Engineers. PROCESS: 1. FRS Review. 2. While reviewing if at all the test engineers gets any doubts, he will list out all the doubts in review report. 3. He will send the review report to the Author of the Document for the clarification. 4. After Understanding the requirements very clearly he will take the test case template and write the Test Cases. 5. Once Built is released, he will execute the Test Cases. 6. If at all any defects are identified, he will isolate them. Once the defect profile is ready he will send it to the development department. 7. Once the next Built is released, he will ensure whether the product is defect free by re executing the Test Cases. This process continues till the product is defect free.

THE

P RO O F O F T ES T IN G P H A S E IS

Q U A L I T Y P RO D U C T .

6. D ELIVERY & M AINTENANCE P HASE :

D E LIV E R Y : T A S K : Development (Installation) R O LE S : Deployment Engineer or Senior Test Engineer. P R O C E S S : A Deployment Engineer will deploy the application in to the clients environment by following the guidelines by given by the development department in the deployment department. M A IN TE N A N C E : Whenever the problem arrases that problem becomes a task depending upon the problem the corresponding role is appointed based on the problem. The problem will be defined and the problem is solved. Q) Where exactly testing comes in to practice? What sort of testing you are expecting?

A: There are 2 sorts of Testing. 1. Unconventional Testing. 2. Conventional Testing.

Unconventional Testing is a process of testing conducted on each and ever out come document right from the initial phase by the Quality Assurance people. Conventional Testing is a process of testing applications in the testing phase by the engineers. Test Case is a check list of all the different presumptions of a test engineer to test a specific future of functionality.

TESTING METHADOLOGY

T E S T IN G

ME T HO D S O R T E ST IN G T E C HN I Q U E S :

These are 3 methods of testing.

1. BLACK BOX TESING: If one performs testing only on the functional part of an application without having any structural knowledge then that method of testing is known as Black Box Testing. It is usually done by Test Engineers. 2. WHITE BOX TESTING: If one performs testing on the structural part of an application then that method of testing is know as White Box testing. It is usually done by Developers of Test Engineers. 3. GRAY BOX TESTING: If one performs testing on both functional and as well as structural part of the application is known as Gray Box Testers.
NOTE:

Gray Testing is done by the Test Engineers with structural knowledge.

LEVELS OF TESTING There are 5 levels of Testing. 1. Unit level Testing. 2. Module level Testing. 3. Integration Testing. 4. System level Testing. 5. User Acceptance Testing. (UAT) 1. Unit level Testing: Unit is defined as a smallest part of an application. If one performs Testing on a Unit, then that level is known as Unit Level Testing. It is a White Box Testing and usually done by White Box Testers or Developers.

2. Module level Testing: If one performs Testing on a Module then that level of Testing is known as Module level Testing. It is a Black Box Testing and usually done by Test Engineers. 3. Integration Testing: Once the Modules are ready they will be integrated with the help of inter phases (linking Program) by the developers and those inter phases are tested by the developers in order to check whether the modules are integrated properly or not. It is a white Box Testing and usually done by the developers. The developers will integrate the modules in following approaches. Top Down Approach. (TDA) Bottom Up Approach. (BUA) Hybrid Approach. Big Bang Approach. Top Down Approach (TDA) (BUA)
M1 M2 M3

Bottom Up Approach

Hybrid Approach

M1 M2 M3

M1 M2 M3

M4

M4

M4

In TDA the parent module are linked with the sub modules. In BUA the sub modules are linked with the parent module. In Hybrid Approach is a mixture of both T D A and B U A .

Big Bang Approach: Once all the modules are ready at a time integrating the modules is known as Big Bang Approach S T UB While integrating the modules in TDA if at all any mandatory module is missing then that module is replaced with a temporary program known as S T U B . D R IV E R S While integrating the modules in BUA if at all any mandatory module is missing then that module is replaced with a temporary program is known as D R I V E R 4. System Level Testing: If one performs testing on a complete application after deploying in to the environment then it is known as System Level Testing. 5. User Acceptance Testing: If one performance the same system testing in the presence of user then it is known as User Acceptance Testing (UAT). This is a Black Box Testing and done by Test Engineers.

SOFTWARE DEVELOPMENT MODELS

W ATER F ALL M ODEL

P HA SE

A C TIV I TY

O U TC O ME

Initial

Req. gathering

BRS

Analysis

Sys. Design

SRS

Design

S/W Design

TDD, GUI

Unit Test Coding Implementation Int. Test

UTR

MTR

Mod. Test Testing Black Box Testing Sys. Test UAT

UTR

STR

MTR

Delivery & Maintenance

Delivery to Client

Whenever the client is very clear with this requirement then the company will choose these requirements. Advantages: Simple model and transparency Disadvantages: New changes or Extra requirements cannot be accepted in the model. P RO TO TY P E M O D E L

Unclear Requirement

SRS Doc Base Lined

Client Environment Conformation

H/W Prototype Prototype S/W Prototype

Demo to Client

Demo to Client

BRS Doc Base Lined

Requirements are Refined

Whenever the client is not with their requirement the company will choose this model to gather requirements. Advantage: This model is very much used for gathering the requirements whenever the client is confused. Disadvantage: Time consuming, should be built on company cost not a full-fledged model user may stick to the prototype.

E VOLUTIONARY M ODEL
Initial Req.

Development
N Feedback with New Req.

Application

User Validation

User Accept

Feedback with New Req.

Advantage:

This is the best suitable model if at all the client is evolving the requirements.

Disadvantages:Dead lines are not defined, No Transparency.

S PIRAL M ODEL

Defining the Objects / WA / Constraints

Refining & Planning for the next Cycle

Risk root cause analysis estimation contingencies.

Implementation

Advantages: This is the best suited model for risk based projects. Disadvantages:Time consuming, expensive

F ISH M ODEL

Delivery & Mantainence Analysis Design Coding System Testing HLD Req. gathering BRS Review SRS View SRS LLD Black Box Testing TDD Review White Box Tesing Test S/W Changes SCD

Advantages:As the verification and validation are ensure the out come of fish model is Quality. Disadvantages: Time consuming, expensive. Verification: Verification is a process of checking whether the product is being developing in a right manner or not. Validation: Validation is a process of checking whether the product is right or not.

V Model

Verification BRS SRS

Validation Preparing Pro. Plan Preparing Test Plan Req. Phase Testing

Initial & Analysis

Design & Coding

TDD SCD

Design Phase Testing Program Phase Testing

Testing

S/W Build

System Testing Test Management Process User Acceptance Testing Port Testing S/W Efficiency DRE=A/A+B Test S/W Changes

Delivery & Maintenance

A = Defects found by the Testing Team. B = Defects raised by the Customer. Advantages: As the verification, validation are ensure and the test management process is taken care then out come of the V-Model is Quality product. Disadvantages:Time consuming, Efficiency. DRE Defect Removable Efficiency.

ENVIRONMENT
Environment is a combination of 3 layers. A. Presentation Layer B. Business Layer C. Database Layer T Y P E S O F E N V I RO N ME N T There are 4 types of Environment. 1. 2. 3. 4. Stand alone Environment [or] One tier Architecture. Client Server Environment [or] Two tier Architecture. Web Environment [or] Three tier Architecture. Distributed Environment [or] N-tier Environment.

1. Stand alone Environment [or] One tier Architecture If at all the three layers are present in a single system of single then it is known as Stand alone environment
DL BL DBL

2. Client Server Environment In this environment clients resides in one tire and the Database Server resides in another tire. Client will be containing the presentation layer as well as the Business layer. So that the corresponding layer logic will be installed. The Database server contains the Database layers. So that the corresponding logics can be installed.
PL+BL

C Client Side C C 3. Web Environment This environment contains 3 tires. Client resides in the first tire, application server resides in the middle tire and the Database server resides on the other tire. Client contain presentation layer. Application contain Business Layer, Database Layer contains Database. So, that corresponding logics are installed.
DBL

C C C Client 4. Distributed Environment Distributed environment is just similar to Web environment. But number of Application servers is increased in order to distribute the business logic. So, that number of layers will be distributed.
NOTE:

AS

DBS

Application Server

Database Server

Eac h and e ve r y a p pl ic a ti o n se rve r s h ou ld b e re pre se n ti n g i n o ne tire . N= Nu m be r of A p pl ic a ti o n Se r ve r s + 2

WS

C C

AS1 AS2

DBS

C Client Application Server Database Server

TYPES OF TESTING

1. Build Verification Testing (BVT) [or] sanity testing BVT is a type of testing in which a Test engineer will perform the overall testing on the released Build in order to check whether every thing is available and proper for further detailed testing. 2. Regression Testing Regression Testing is a type of testing in which one will perform testing on the already testing functionality once again. It is usually done in 2 scenarios. a. Whenever the test engineers raise the defect, developer rectifies it. Next build is released to the testing department then the test engineer to the testing department then the test engineer will test the rectified functionality as well as the related functionality once again in order to ensure while rectifying the defect related functionality is not affected. b. Whenever the new changes are proposed by the customer incorporated by the developers and the build is released to the testing department. Then the test engineer will test the already tested related functionality in order to ensure that the old functionality remains same despite of new change. 3. Re-Testing It is a type of testing in which one will perform testing on the already tested functionality again and again with multiple sets of data in order to ensure the functionality is working fine or the defect is reproduced with multiple sets of data. 4. Alpha () Testing It is a type of User Acceptance Testing done in the company by our test engineers. Advantage: If at all any defects are identified, there is a chance of rectified them immediately. 5. Beta () Testing It is also a type of User Acceptance Testing done in the clients place either by the 3 r d party test engineers or by the end users. Disadvantage:If at all any defects are identified there is a chance to rectify them immediately. 6. Static Testing It is a type of testing in which one will perform testing on application or its related factors whenever it is not been executed. Ex: Doc Testing, Code Analysis, GUI Testing 7. Dynamic Testing It is a type of testing in which one will perform testing on the application whenever it is being executed. Ex: Functionality Testing. 8. Installation Testing It is a type of testing in which a test engineers will try to install the application in to the environment by following the guidelines given in the deployment by developers. If the installation is successful then he will come to a conclusion that the guide lines are correct. Otherwise he will conclude that there are some problems in the guidelines. 9. Compatibility Testing It is a type of testing usually done for the products in which a test engineer may have to deploy the application in to the environments prepare with multiple combination on environmental components in order to check whether it is compatible with those environment or not. 10. Monkey Testing [or] Gorilla Testing It is a type of testing in which one will perform abnormal actions intentionally on the application in order to check the stability.

10

11. End to End Testing It is a type of testing in which one will perform testing on a complete transaction or an end to end scenario. Ex : Login Balance Enquiry Withdraw Balance Enquiry Logout

12. Usability Testing It is a type of testing in which one will concentrate on the user friendliness of the application. 13. Exploratory Testing It is a type of testing in which one will perform testing on the application with out any requirement document support by exploring the functionality usually it is done by the domain experts. 14. Port Testing It is a type of compatibility testing done at the clients place after deploying the application in order to check whether it is compatible with that environment or not. 15. Security Testing It is a type of testing in which one will concentrate on the following areas. Authentication, Direct URL testing, Firewall Testing. 16. Reliability Testing ( Soak Testing ) It is a type of testing in which one will perform testing for longer period of time in order to check stability. 17. Mutation Testing It is a White Box Testing done by the Developers where they do some changes to the program and check for its performance. Since it is associated with multiple mutations, it is known as Mutation Testing. 18. AD HOC Testing It is a type of testing in which one will perform testing on the application in his own style after understanding the requirements very clear.

[Software Testing Life Cycle]

STLC contains 6 phases.

(1)T EST (2)T EST (3)T EST (5)B UG

PLANNING DEVELOPMENT EXECUTION ANALYSIS

(4)R ESULT

TRACKING

(6)R EPORTING
T E S T P L A N N I N G

Plan: It is a strategic document which describes how to perform a task in an effective, efficient and optimized way. Test Plan: It is a strategic document which describes how to perform testing on an application in an effective and optimized way. Optimization: It is a process of reducing the inputs and gathering the same output or even more output.
NO T E: Te st Pla n is pr e p ar e d by t he Te st L e ad .

11

TEST PLAN INDEX [or] CONTENTS

1.0 I N T RO D U CT I O N 1.1 1.2 2.0 Objective. Reference Doc.

C O V E RA G E O F T E S T I N G 2.1 2.2 Feature to be tested. Feature not to be tested.

3.0

T E S T S T RA T E G Y 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Levels of Testing. Types of Testing. Test Design Techniques. Configuration Management. Test Metrics. Terminology. Automation Plan. List of Automated Tools.

4.0

B A S E C RI T E RI A 4.1 4.2 Acceptance Criteria. Suspension Criteria.

E N V I RO N M E N T PLA N N I N G

5.0

TEST

R E S O U RC E 8.0 9.0 10.0 11.0 12.0

S CH E D U L I N G S T A F FI N G & RISKS &

T RA I N I N G

CO N T I G E N S I S

A S S U M PT I O N S A P P RO V A L
I N FO RM A T I O N

1.0

I N TRO D UC T IO N Objective: The purpose of the test plan doc is clearly describes here in this session. Reference Document: The list of all the documents that are referred to prepare the test plan will be listed out here in this session.

2.0

C O V E RA G E

OF

TESTING

Features to be Tested: The lists of all the features that are with in the scope are listed out here in this session. Features not to be Tested: The list of all the features that are not planned for testing based on the following criteria will be listed out here in this session. o Features out scope o Low risk features o Features that are to be skipped based on the time constraints. o Features functionality. 3.0 T E S T S T RA TE G Y It is an organization level term which is used for testing all the projects in the organization.
NO T E: Us u al ly t e s t st ra te gy i s c om m o n f or a ll th e pr oje c ts . Nut u p on c o stu me r r e que st t he m may be sl ig h t c ha n ge s th e r e m ay be sl ig h t c ha n ge s i n i t .

12

Test Plan: Test Plan is defined as project level term which is used for testing a specific project. Levels of Testing: The list of all the levels of testing that are followed by that company are listed out here in this session Types of Testing: The lists of all the types of testing that are followed by that company are listed out here in this session. Test Design Techniques: Technique is some thing that is used for accomplish a complex task in easy manner. The lists of all the techniques that are followed by that company are listed out here in this session. Boundary Value Analysis (BVA) Equivalence Class partition (ECP) Configuration Management:

Test Metrics: The list of all the metrics that are maintained in the organization that are listed out here in this session. Terminology: The list of all the terns that are followed in that company along with the meaning will be listed out here in this session. Automation Plan: The list of all the areas that are planned for automation listed out here in this session. List of Automated Tools: The list of all the automated tools that are used by the company are listed out here in this session. 4.0 B A S E C R I TE RI A 4.1 Acceptance Criteria: When to stop testing in a full-fledged manned is clearly describe here in this session. 4.2 Suspension Criteria : When to reject or suspend testing is clearly described here in this session. 5.0 T E S T D E L IV E RA B LE S The List of all the documents that are about to be delivered are listed out here in this session. E X : T E S T C A S E D O C , R E V I E W R E PO RT , D E F E CT P R O FI LE D O C . T E S T E N V I RO N ME N T The client specified environment is clearly described here in this session. 7.0 8.0 R E SO URC E P L A N N IN G Who have to do What is clearly describes in this session. S C H E D U L IN G The starting dates and the ending dates of each and every task is clearly describes in this session. S TA F F IN G & T RA IN I N G How much staff is to be recruited what kind of training should be provided for the newly recruited staff and for the existing employee to accomplish this project successfully will be clearly described in this session. R I SK S & C O N T IN G E N C E S The list of all the potential risks and the corresponding solutions are listed out here in this session.
RI S K S

9.0

10.0

Unable to deliver the project with in the deadline. Customer imposed deadlines. Employees leave the company in the middle of the project. Unable to test all the features with in the time lake of expertisation.

13

C O N T I N G E N CE S 11.0

FOR

SOLUTION

Proper plan ensure. What not to be tested will be increased in case of customer imposed deadlines. People should be maintaining on the Bench. Severity priority based execution. Training should be provided.

A SS U MP TIO N S What are all the things that a test engineer should assure is mentioned here in this session.

12.0

A P P RO V A L I N F O R M A TIO N Who has to approve what is clearly describe here in this session.

T E S T

D E V E L O P M E N T

P H A S E

Use case is a description of functionality of certain feature of an application in terms of actors, actions and responses. I N PU T I N FO RM A T I O N R E Q U I RE D F O R P RE P A RI N G T H E U S E
CA S E S

APPLICATION

USER NAME PASS WORD CONNECT TO

LOG IN

CLEAR

CANCEL

Functional Requirements: 1. LO G I N screen should contain Username, Password and Connect to fields, Login, Clear and Cancel Buttons. 2. Connect To is not a mandatory field but it should allow the user to select a database object. 3. Upon entering the valid user name, password and click on Login button the corresponding page must be displayed. 4. Upon entering some information into any of the fields and clicking on Clear button all the fields must be clear and the cursor should be placed in the user name field. 5. Upon clicking on Cancel button login screen should be closed.

Special Requirements [or] Validations [or] Business Rules: 1. Initially whenever the login screen is opened Login and Clear buttons must be disabled. 2. Cancel button must be always enable. 3. Upon entering the user name and password the login button must be enabled. 4. Upon entering information into any of the fields clear button must be enabled. 5. The tabbing order must be User Name, Password, Connect to, Login, Clear and Cancel.

14

T E MP LA T E

O F TH E US E C A SE

1. Name of the Use Case. 2. Brief description of the Use Case. 3. Actors involving. 4. Special Requirements. 5. Pre Conditions. 6. Post Conditions. 7. Flow of Events.

U S E C A SE D OC U M E N T 1. 2. 3. 4. Name of the Use Case: Log in Use case Brief Description Of the Use Case: This is Use Case is used for describing the functionality of all the features in the Login screen. Actors Involved: Admin, Normal User. Special Requirements: a) Explicit Requirement Copy the requirements which are given by the client. b) Implicit Requirement Implicit requirements are the requirements that are analyzed by the Business Analyst in order to provide the value to the Application. Ex: Once the login screen is invoked, the cursor should be placed in the user name field. 5. Preconditions Login screen must be available. 6. Post conditions Either Home page or Admin page for the valid user and error message for the invalid user. 7. Flow of Events MAIN FLOW

Action
Actor invokes the application. Actor enters valid user name, Password and clicks on login button. Actor enters valid username valid password selects a database option and click on the login button. Actor enters invalid username, valid password and clicks on login button. Actor enters valid username, invalid password and click on login button. Actor enters invalid user name, password and click on login button. Actor enters some information into any of the fields and click on clear button. Actor clicks on Cancel button.

Response
Login screen is displayed with the following fields. User Name 2. Password 3. Connect to. Authentication either Home page or Admin page is displayed depends on the actor entered. Authentication either Homepage of Admin page is displayed with a mentioned data base connection depending upon the actor entered. Go to Alternative flow Table 1. Go to Alternative flow Table 2. Go to Alternative flow Table 3. Go to Alternative flow Table 4. Go to Alternative flow Table 5.

Alternative Table 1: [Invalid User Name] Action Actor enters invalid username valid password and click on login button. Response Authenticates Error message is displayed. Invalid User name, Please Try Again

Alternative Table 2: [Invalid Password] Action Actor enters valid username invalid password and click on login button. Response Authenticates Error message is displayed. Invalid Password, Please Try Again

15

Alternative Table 3: [Invalid Username & Password] Action Actor enters invalid username and invalid password and click on login button. Alternative Table 4: Action Actor enters some information in to any of the fields and click on Clear button. Alternative Table 5: Action Actor clicks on Cancel button. Response Login screen is closed. Response All the fields are cleared and the cursor is placed in the username field. Response Authenticates Error message is displayed. Invalid Username & Password, Please Try Again

The Guide Lines to be followed by a test engineer to develop the Test case from a given Use Case.

1. Identify the Module to which the Use case belongs to. Security Module.

2. Identify the functionality of the Use case with respect to the total functionality of the application. Authentication.

3. Identify the functional points and prepare the functional point doc. 4. Identify the action involved. Admin, Normal User

5. Identify the inputs require to perform the use case. Valid and Invalid Input.

6. Identify whether the Use Case is linked with any other Use Case. Home Page, Admin Page.

7. Identify the Pre condition Login screen must be available.

8. Identify the Post condition Home page or Admin page for valid users and Error message for in valid Users.

9. Understand the main flow of the Use case. 10. Understand the alternative flow of the use cases. 11. Understand the special requirements of Business rules. 12. Document the Test Cases for the Main flow. 13. Document the Test Cases for the Alternative flow. 14. Document the Test Cases for the Special requirements. 15. Prepare the cross reference Matrix. (Traceability Matrix).

16

Functional Point: FRS

FRS UCD Functional Point Document User Name Entry Password Only D.B entry Master Test Case Doc Validation login, connect to, cancel, clear Detailed Test Case Doc Defect Profile Doc

Traceability Matrix
UCD FPD MTCD DTD DPD

Functional Point:

The point where the user can perform action can be considered as functional point.

Traceability / Cross requirements: Traceability is a table which contains some information used for tracing back for the reference by linking the corresponding documents in any kind of obvious situation. Types of Test Cases: The Test Cases are broadly classified in to 2 types. (i) User interface Test Cases. (ii) Functional Test Cases.

The functional Test cases are further classified in two types. (i) +ve Test Cases. (ii) -ve Test Cases.

Guidelines for developing the user interface Test Cases. 1. 2. 3. 4. Check Check Check Check for for for for the the the the availability of all the objects. alignments of the objects. consisting of the objects [Size, Color, Font, Type.] Spelling & Grammar.

Guidelines for developing the +ve Test Cases. 1. A Test engineer should have the +ve perception. 2. A Test engineer should consider the +ve flow of the application. 3. He should always use only the valid inputs. Guidelines for developing the ve Test Cases. 1. A Test engineer should have ve perception. 2. A Test engineer should consider the ve flow of the application. 3. He should use the invalid inputs. T E S T C A S E T E MP LA T E 1. 2. 3. 4. 5. 1. 2. 3. 4. 5. Test Test Test Test Test Test Test Test Test Test Objective. Scenario. Procedure (Functional level term used to test particular functionality). Data. Cases. Objective: The main purpose of the document is described in this session. Scenario: The situation that are to be tested described in this session. Procedure: It is a functional level term which describes how to perform testing on functionality. Data: The Data that is required for testing is described in this session. Cases

17

TEST CASES
T.C Type Prior ity Refer ence

T.C

Description

Expected Value

Actual Value

Result

Savoir

1 2 3 4

UI UI UI UI

5 6 7

UI +ve +ve

8 9

+ve +ve

10

+ve

Check for the availability All the objects must be of all the objects. available as per the OBJ Tab Check for the consistence All the objects must be of all the objects. consistence. Check for the spellings of All the objects must be all the objects. spelled properly as per the OBJ Tab Check for the enable Login, clear buttons property of login, clear and must be disabled and cancel buttons. cancel button must be enable. Check for the curser Curser must be placed in placement in the the username field. application Enter username , password Corresponding page as per the V I T and click must be displayed as per on login button the V I T. Enter Username, password Corresponding page as per the V I T, select a must be displayed as per database option and click the VIT with the on login button. mentioned database connection. Enter username, password Login button must be and check for the enable enabling. property of login button. Enter some information in Clear button must be to any of the fields and enabling. check for the enable property of clear button. Enter some information in All the fields must be to any of the fields and clear and the curser click on clear button. should be placed in the username field.

All the objects are available as per the OBJ Tab All the objects are consistent. All the objects spelled properly as per the OBJ Tab. Login, clear and cancel buttons are enable Curser is placed in the user name field Corresponding page displayed as per the V I T. Corresponding page displayed with the mentioned database connection. Login button enabling. Clear enable. button is is

Pass Pass Pass

Pass

Pass Pass

Pass

Pass

Pass

11 12

+ve +ve

13

ve

14

ve

All the fields are cleared but the curser is not placed in the username field. Click on the cancel button. Login screen must be Login screen is closed. closed. Check for the tabbing Tabbing order must be Tabbing order is order. username, Password, working properly. connect to, login, clear and cancel. Enter username, password Corresponding error Corresponding pages as per the IVIT and click message should be are displayed as per on login button. displayed as per the the IVIT. IVIT. Enter either username or Login button must be Login button is password or select a disabled. enabled. database option and check for the enable property of login button.

Pass

Pass Pass

Pass

Fail

OBJ TABLE

S.no 1 2 3 4 5 6 V A L ID I N P UT S T A B L E S.no 1 2 3 4 User Name Suresh Santos Admin Madhav

Object User Name Password Connect To Login Clear Cancel

Type Text Box Text Box Combo Box Button Button Button

Password QTP Bunny Admin Mmd

Expected Page Admin Homepage Admin Home page

Actual Page Admin Home page Admin Home page

18

I N V A L ID I N P UT S T A B LE S.no 1 User Name Sures Password QTP Expected Page Invalid Username Please try again Invalid Pass word Please try again Invalid Username & Password Please try again Actual Page Error message displayed.

2 3

Santos Test

Bun Test

TEXT EXCUTION PHASE In this phase the test engineers will do the following actions. 1. He will perform the action that is described in the description column. 2. He will observe the actual behavior of the application. 3. He will document the observed value under the actual value column of the test case document. RESULT ANALYSIS PHASE In this phase the Test engineer will compare the actual value with the expected value and both are matched he will mention the result as pass otherwise failed. BUG TRACKING Bug tracking is a process in which the defects are identified, isolated and maintained.
1 2 3 4 5 6 7 8 9 10 11

(1) Defect ID. (2) Defect Description. (3) Steps for reproducibility. (4) Submitter. (5) Date of Submission. (6) Build Number. (7) Version Number. (8) Assigned to. (9) Severity. (10) Priority. (11) Status. (1) Defect ID: The sequence of defect numbers will be there in this session. (2) Defect Description: What exactly the defect is clearly describes here in this session. (3) Steps for reproducing: The lists of all the steps that are followed by the test engineer to identify the defect are listed out here in this session. So, that the developer will follows the same steps in order to reproduce the defects. (4) Submitter: The name of the test engineer who submitted the defect is mentioned here in this session. (5) Date of Submission: The date on which the defect is submitted is mentioned. (6) Build Number: The corresponding build number will be mentioned here in this session. (7) Version Number: The corresponding version will be mentioned here in this session. (8) Assigned to: This field is not filled by the Test engineer, but it is filled by the Project Manager or Project Leader with the name for where the defect is assigned. (9) Severity: Severity describes how serious the defect is this is classified in to 4 types. a) Fatal b) Major c) Minor d) Suggestion. a) Fatal: If at all the problem is related to the navigational block or unavailability of the functional then such types of problems is treated to be Fatal. 19

b) Major: If at all the major functionality is not working fine then such type problems treated to be Major defects. c) Minor: If at all the problems is related to the feel of Look and Feel of the application. Such type of defects is treated to be Minor defects. (10) Priority: The priority defines the sequence in which the defects has to be rectified. Priority is classified in to 4 types. a) Critical. b) High. c) Medium. d) Low. Usually the Fatal defects are given Critical Priority. Major defects are given High Priority. Minor defects are given Medium Priority. Suggestion defects are given Low Priority. But there are some situations where in the priority change. Case 1: Low severity High Risk. In case of client visit all the look and feel defects are given highest priority. Case 2: High severity Low priority. Whenever the functionality unavailable the test engineer will raise it as a Fatal defect. But, if that functionality is under development and it taken some more time and that such situation is Low priority given by Project Manager or Project Leader. BUG LIFE CYCLE
Hold As per Design
No Yes

Testing Error Requiremen t Is it really a Defect?

Yes

Development

Rectification

M1 Testing

B1 B2

Fixed for verification.

New/ Open

Yes

If Defect

No

Stop the Testing

Reopen

No

Is defect is really rectified

Yes

Closed

New/ open: Whenever the test engineer identifies the defect newly for the first time then he will set the states as new/open. But some companies will say it as new and once the developer accept as defect he will set as open. Fixed for verification: Whenever the test engineer raises the defects and the developer rectifies it the he will set the status as of the defect as Fixed for verification before releasing the next build. Reopen and Closed: Whenever the defects are rectified and next build is releasing to the testing department then the test engineer will check whether the defects rectified properly or not if they feel the defects is not rectified properly then they will wet the status as Reopen if at all they feel that the defect is rectified properly then they will set status as Close. Hold: Whenever the developer is in a confusion situation to accept or reject the defect in such situation he will set the status as Hold. As per Design: Whenever the new requirements are given by the development team and the developers incorporated those new fields and release to the testing department. As the test engineers are not aware of those new changes he will raise as them defects. But the developers will set the status as As per Design. Testers Error: If at all the developer feels it is not at all a defect then he will set the status as Tester Error.

20

REPORTING PHASE (1) Classical Bug Reporting Process: Drawbacks: Time consuming, Redundancy, insecurity. (2) Common Repository oriented Bug reporting Process: Drawbacks: Time consuming, Redundancy. (3) Bug Tracking Tool oriented Bug Reporting Process: Bug Tracking Toll is software which can be accessed by the authorized persons only. It is used for complete bug tracking process. TEST DESIGN TECHNIQUES Whenever the test engineer is developing the test cases he may face some difficulties. In order to overcome those difficulty and complete the tasks easily there are some techniques known as Test Design Techniques (1) Boundary Value analysis: Whenever the test engineer need to develop the test cases for a range kind of the input, then he will use a technique called Boundary value analysis. Using this technique one will

(2) Equivalence Class Partition: It is a technique used by the test engineer in order to develop the +ve and ve test cases easily for a functionality which has more number of validations. Using this technique one can divide the valid class inputs and invalid class inputs. Case Study: Develop the test cases to test a Text Box which has the following validation. (a) It should accept minimum 4 characters and maximum of 20 characters. (b) It should accept small a z only. (c) It should accept special symbols @ and _ only.

21