Testing+Tools+(Manual)

[email protected]

Suresh.B –9440163282

Jai Sri Ram Jai Sai Ram Quality Quality means satisfaction of the customer. To define good quality of software, the company people will concentrate on two (2) factors such as 1) Technical factor and 2) Non-technical factor. 1) Technical factor a. Customer requirements in terms of functionalities. b. Customer expectations (Look and feel, Ease of use, right output, speed of processing, security) 2) Non-technical factor a. Low cost to purchase b. Time to market. S.Q.A (Software Quality Assurance) It means monitoring and measuring the strength of development process. REQUIREMENTS GATHERINGS Business Development People / Business Analyst Business Requirement Specification (BRS) / User Requirement Specification (URS) / Customer Requirement Specification (CRS) ANALYSIS Analyst Software Requirement Specification (S/W RS)

DESIGN Designers Design Document CODING Programmers 

FRS Functional Requirement Specification SRS System Requirement Specification HLD High Level Design Document  LLD Low Level Design Document 

TESTING Testers  PROJECT MANAGEMENT Release and Maintenance 

Manual Testing  

1

[email protected] 

Suresh.B –9440163282

1) REQUIREMENT GATHERINGS: In general software development starts with requirement gathering. In this stage Business Development People (BDP) / Business Analyst People (BA) are preparing Business Requirement Specification Document (BRS) / User Requirement Specification Document (URS) / Customer Requirement Specification Document (CRS), after gathering all required requirements from the user / customer. Business Requirement Specification Document defines the requirement of the customer. 2) ANALYSIS: After completion of Business Requirement Specification Document, Analyst People are preparing “Analysis Document”. This document is also called as “Software Requirement Specification Document” (S/w RS). The document consists of (2) Sub documents such as FRS & SRS (i) FRS It means “Function Requirement Specification”. It defines the required functionality to be used in the project. (ii) SRS It means “System Requirement Specification”. It defines the required Hardware to develop that functionality. 3) DESIGN After completion of Analysis Document, Designers are preparing Design Document. It consists of (2) sub documents, such as (i) HLD & (ii) LLD (i) HLD (High Level Design Document) It is also called as External Design Document. It defines the hierarchy of over all application functionalities in terms of modules from root level to leaf level. Ex:

Login Mail

Chat

 

 

Logout

2

Manual Testing

Suresh.B –9440163282

[email protected]

(ii)

LLD (Low Level Design Document) It is also known as Internal Design Document. It defines the internal logic of every functionality or module in terms of ER Diagrams, Data Flow Diagrams. V - Valid LOGIN User Name Password

V

V IV IV

V

IV V IV

CANCEL

OK

MESSAGE BOX

IV - Invalid

Please Try Again

 

OK DATA BASE

INBOX Note:

A Project will have one HLD and Multiple LLDs.

4) CODING: A Physical construction of Software is called as “Coding”. System

SS1 P1

P2

M1

M2

S1

S2

S3

SS2

SS3

M3

BUILD

P3

Build: An executable form of all integrated module set is called “Build”. 5) TESTING In this stage, the testers are validating that developed Build with respective Customer requirements and customer expectations. 6) RELEASE AND MAINTENANCE After completion of software testing the Project Management will deliver that software to customer for usage. During utilization of the software, if customer get any problem or if customer want to enhance the application, that can be handled by the company people. Manual Testing  

3

Suresh.B –9440163282

[email protected] 

™ What is the difference between Software Product and Software Application? Software Application If the Software developed with respective particular client requirements or single client requirements that can be called as Software Application. Ex: Bank Applications, Hospital Applications. Software Product If the Software developed with respective multiple clients requirements, that can be called as Software Product. Ex: MS Office, VB, Operating System etc.,

™ What is Error, Defect, Bug? Error: Any mistake in a programme is called “Error”. Defect: Any mistake found by the tester during Testing can be called as “Defect”. Bug: The reported defect is accepted by developer to resolve can be called as “Bug”. SQC (Software Quality Control) It is a process of validating the Software.

™ Why Software has Bugs?

(i) Poor requirements (ii) Futurities (Customers requirements are frequently changing) (iii) Miscellaneous Communication. (iv) Unrealistic schedule (v) Inadequate testing. Solutions (i) Solid requirements (ii) Good communication (iii) Realistic schedule (iv) Adequate testing (v) Gather / Stick to initial requirements as much as possible.

4

Manual Testing

Suresh.B –9440163282

[email protected]

TESTING MODELS FISH MODEL Fish model defines the mapping between development stages and Testing stages. S/W RS (FRS & SRS) Analysis

Design (HLD & LLD)

Requirements Gathering BRS / CRS / URS

Verification

Reviews in Analysis

Reviews in Design

Coding

Release & Black Box Maintenance Testing / Functional & System Testing / Close Box Testing

Validation

White Box Testing / Glass Box Testing / Programe Phase Testing / Open Box Testing

Test Software Changes

Reviews in Analysis In general Software Development process starts with requirements gathering and analysis. In this, Business Development People are preparing Business Requirement Specification Document and Analyst people are preparing Analysis Document with respective to Business Requirement Specification. After completion of analysis document, the same category people conducting reviews in Analysis Document for completeness and correctness. During the review they are concentrate on the below factors. i) Are they complete? ii) Are they right requirement? iii) Are they achievable? iv) Are they reasonable? v) Are they testable? Reviews in Design Document After completion of Analysis document and corresponding reviews, designers are preparing design document which includes Functional Requirement Specifications and System Requirement Specifications. After completion of design document the same category people are conducting reviews in design document for completeness and correctness. During the review they concentrate on below factors. Manual Testing  

5

Suresh.B –9440163282

[email protected] 

i) Are they complete/ ii) Are they met right requirements? iii) Are they understandable? iv) Does they handle Errors or not? White Box Testing After completion of deign document and correspondence reviews, programs with concentrate on coding to construct a Software Build. After completion of preparing all programs, Programmers are interconnecting them to a system. In this interconnection of programs to verify the programs and interface between programs or modules, programmers are conducting “White Box Testing” White Box Testing classified as Two Types such as (I) Unit Testing (II) Integration Testing. (I) Unit Testing It is also called as Program Testing or Micro Testing. Unit testing means “Single Program Testing or Component Testing. Unit testing consists of below factors. a) Basic Path Testing. During this testing programmers are checking that whether the program is running or not? To perform this test they will follow below approach. 1) Draw flow diagram of that program. 2) Calculate number of independent paths in that program (Cyclometic Complexity) (The number of independent paths in the program) 3) Execute the program more that one time to cover all independent paths in that program. b) Control Structure Testing In this testing the programmers will concentrate on corresponding program output. In this programmers will concentrate on every statement including, If conditions, For loops, Memory allocation etc., c) Program Technique Testing In this testing the programmers are checking the execution speed of the program. If the execution speed of the program is not good, then programmers are performing changes in the structure of the program without disturbing functionality. d) Mutation Testing Mutation means changes in a program. In this testing programmers are performing wanted changes in the program and executing the program repeatedly. In this Test repetition, 6

Manual Testing

Suresh.B –9440163282

[email protected]

Programmers are checking the completeness and correctness of the Test. A=10 B=20 C=A+B msgbox I

Passed (II)

A=10 B=20 I=A+B C=I msgbox I

Perform change

Passed Failed (In-compete (Complete Testing) Testing)

Integration Testing After completion of dependent program development and corresponding Unit Testing, Programmers are interconnecting to form a system. To estimate the interface between programs or modules programmers are conducting Integration Testing. They are (4) Types of approaches. a) Top-Down Approach. The verification of main module without coming to some of the Sub-Modules is called as Top-Down Approach. “Conduct test on Main module without conducting test on some of the Sub-Modules is called Top-Down Approach.” Main Module STUB

Sub-Module-1

Sub-Module-2

Temporary Program / Called Program

Sub-Module-3

In the above approach “STUB” is a Temporary Program, it works like as under constructive Sub Module, it is also called as Called Program. b) Bottom-Up Approach. The verification of Sub-Modules without coming from Main Module is called “Bottom-Up” Approach. “Conducting test on Sub-Modules without testing on Main Module is called Bottom-up Approach. Main Module Driver / Calling Program Sub-Module-1

Sub-Module-2

Sub-Module-3

In the above approach “Driver” is temporary program, it works like as under constructive Main Module. Driver is also known as Calling Program. Manual Testing  

7

[email protected] 

Suresh.B –9440163282

c) Hybrid Approach / Sand-witch Approach The combination of Top-down Approach and Bottom-Up Approach is called as Hybrid Approach / Sand-witch approach. Main Module Driver / Calling Program Sub-Module-1

Bottom-Up Approach Sub-Module-3

Sub-Module-2

STUB Sub-Sub-Module-1

Sub-Sub-Module-2

Top-Down Approach

Sub-Sub-Module-3

d) Bigbang Approach. The verification of all modules after completion of all Modules development and corresponding unit testing is called as “Bigbang Approach”. This approach is not suitable for large modules. CASE STUDY Case 1:

Top-down

approach

is

followable,

when

the

customer’s

when

the

customer’s

requirements are constituent of clear. Case 2:

Bottom-up

approach

is

followable,

requirements are not clear or frequently changing. Case 3:

Hybrid Approach is followable, when the customer’s requirements are clear and the architecture structure of the system is changing.

Case 4:

Bigbang Approach is followable, when the application build consists

less

number

of

modules

or

less

number

of

interconnections.

8

Manual Testing

Suresh.B –9440163282

[email protected]

BLACK BOX TESTING After completion integration of all modules to form a system, developers are sending that build to the separate Testing team. This separate testing team validates the Software build with respective customer’s requirements and expectations through “Black Box Testing” techniques. It is also known as “Close Box Testing” / “Functional & System Testing” It is classified as (3) types such as 1) Usability Testing. a. User Interface Testing. b. Manual Support Testing. 2) Functional Testing. a. Functionality Testing. b. Sanitation Testing. 3) Non-Functional Testing. a. Recovery Testing. b. Compatibility Testing c. Configuration Testing. d. Intersystem Testing e. Comparative Testing f. Security Testing. g. Installation Testing. h. Load Testing. i. Stress Testing j. Data Volume Testing. k. Storage Testing. 1) Usability Testing After receiving build from the development people, testers are conducting usability testing to check whether the application build is providing user friendly screens or not. Usability Testing is classified into (2) Types such as (a) User Interface Testing (2) Manual Support Testing. a. User Interface Testing During this testing testers are checking the Look and Feel, Ease of use of application of build screen. Ex: The Microsoft (6) Rules for testing 1) Controls are initcaps. 2) Ok, Cancel existence. 3) System Menu existence. 4) Controls are not overlapped. 5) Controls should be visible. 6) Controls must be aligned. Manual Testing  

9

Suresh.B –9440163282

[email protected] 

b. Manual Support Testing It is also known as “Help document Testing”. During this testing Testers are checking the context sensitiveness testing. Ex: Spelling Mistakes, Grammar mistakes, Word Missing, Line Missing etc., Case 1: Receive build from the developers. ™ User interface testing. Usability ™ Functional & Non-Functional Testing Testing ™ Manual Support Testing. 2) Functional Testing After completion of User Interface testing, Testers are conducting Functional Testing to validate customer requirements. Functional Testing classified into (2) Types (a) Functionality Testing (b) Sanitation Testing. a) Functionality Testing During this Testing Testers are validating customers requirement in terms of (6) coverage. 1) Behavioural Coverage. 2) Input Domain Coverage. 3) Error-Handling Coverage. 4) Calculation Coverage. 5) Back-end Coverage. 6) Service level Coverage. 1) Behavioural Coverage. In this testing Testers are checking whether the objects are properly responding of not, with respective to Business Operation. 2) Input Domain Coverage In this testing Testers are checking whether the input objects / Input fields are taking right type and range of value or not. To perform this test we (Testers) are using (2) Types of Testing. (i) BVA (Boundary Value Analysis (ii) ECP (Equivalence Class Partitioning) BVA ECP (Range of Object) (Defines Type of Object) Range Expected Actual Result Valid Invalid Pass Min= Min-1= Fail Min+1= Pass Pass fail Pass Max= Max-1= Pass Max+1= Fail

10

Manual Testing

Suresh.B –9440163282

[email protected]

Ex:

A Login process allows User Name and Password from a User. In this User Name object allows “Alphabets lower case” Range from 4 to 8 Characters long and Password object allows “Alphabets lower case” range from 6 to 10 Characters long. Prepare BVA and ECP for the above expected.

Range Min= 4 Char Min-1= 3 Char Min+1= 5 Char Max= 8 Char Max-1= 7 Char Max+1= 9 Char

BVA & ECP for User Name BVA Expected Actual Result Pass Fail Pass Pass Pass Fail

BVA & ECP for Password BVA Range Expected Actual Result Pass Min= 6 Char Min-1= 5 Char Fail Min+1= 7 Char Pass Pass Max= 10 Char Max-1= 9 Char Pass Max+1= 11 Char Fail

Ex:

ECP Valid [a-z]

Invalid [A-Z] [0-9] All Special characters

ECP Valid [a-z]

Invalid [A-Z] [0-9] All Special characters

Age object allows numeric range from 16 to 60. Prepare BVA and ECP for the above expected. BVA & ECP for Age

Range Min= 16 Min-1= 15 Min+1= 17 Max= 60 Max-1= 59 Max+1= 61 Manual Testing  

BVA Expected Actual Pass Fail Pass Pass Pass Fail

ECP Result

Valid [0-9]

Invalid [A-Z] [a-z] All Special characters 11

[email protected] 

Suresh.B –9440163282

Ex:

Mobile No. object allows numeric 10 digits only. Prepare BVA and ECP for the above expected.

Range Max= 10 Max-1= 9 Max+1= 11

BVA & ECP for Mobile No. BVA Expected Actual Result Valid Pass [0-9] Fail Fail

ECP Invalid [A-Z] [a-z] All Special characters

3) Error-Handling Coverage. In this we are checking whether the objects are preventing “Negative Operations” or not. 4) Calculation Coverage. In this we are checking whether the functionality output is right or wrong.

5) Back-End Coverage. ODBC JDBC

In this testing we are checking whether the insert of front end operations on back end table context. 6) Service level coverage. The order functionality.

12

Manual Testing

Suresh.B –9440163282

[email protected]

b) Sanitation Testing It is also known as “Garbage Testing”. During this testing, testers are finding extra functionalities in the build with respect to customer requirements.

3) Non-Functional Testing After completion of Functional Testing, testers are concentrating on Non-Functional Testing to validate extra characteristics of that build. They are divided into (11) Types. a) Recovery Testing During this testing we are checking that whether the application Build is changing from Abnormal State (Crash / Hang) to Normal State or not. Abnormal State to Normal State Normal State Abnormal State b) Compatibility Testing They are (2) types of Compatibility Testing.

Build

V.B

O.S

Unix

Build

VC++

O.S

Win98

Æ Win98 is supporting VC++ Æ But Build is not working Properly due to defects During this testing we are checking whether the application build is able to run on different platforms or not. Platform means Operating System, Browsers, compilers and other System software’s.

Ex: Unix does not support VB Techniques

Manual Testing  

13

[email protected] 

Suresh.B –9440163282

c) Configuration Testing It is also known as “Hardware Compatibility Testing”. During this testing we are validating whether the application build is supporting different technologies input / Output devises or not. d) Intersystem Testing. It is also known as “Inter operability Testing”. During this testing we are checking whether the application build is coexistence with other existence to share common resource or not. Ex.: E-Seva. Elec. Bill

Server

Telephone Bill

Server

Water Tax Bill

Common Data Base

Server

Income Tax Bill

Server

Municipal Bill

Server

e) Comparative Testing. It is also known as “Competitive Testing”. During this testing we are comparing the features of produce with some like previous produce (or) Existing produce in the market to estimate competitiveness. Note: Comparative Testing is applicable for Software Produces only not for applications, because Software application is developed for a single client requirement, but product can be developed with respect to multiple clients requirements. f) Security Testing. It is also known as “Penetration Testing”. During this testing we are validating (3) types of factors such as (i) Authorization. (ii) Access Control. (iii) Encrypt / Decrypt Data Testing. (i) Authorization. In this testers are checking whether a valid user is accessible or not, invalid user is preventable or not. (ii) Access Control In this we are checking whether a valid user have permission to use specific features / Services or not.

14

Manual Testing

Suresh.B –9440163282

[email protected]

(iii)

Encrypt / Decrypt Data Testing. The code conversion in between client process and server process to avoid third party accessing.

CLIENT User Name

SERVER

Password

Request Encrypt

Decrypt Cipher Text

Decrypt

Request

Encrypt Cipher Text g) Installation Testing It is also known as “Deploying Testing”. During this testing we are validating below factors. Build & Supported Software

Customer expected configure Computer

Æ Setup Program. Æ Easy Navigation. Æ Occupied Disk Space. Æ Check Un-installation.

h) Load Testing. Run the application under customer expected configuration under customer load to estimate the speed of processing is called “Load Testing”. i) Stress Testing. Run the application under customer expected configuration under various loads from low to peak to estimate Stress capacity of the application build is called Stress Testing. j) Storage Testing. The execution of application build under customer expected configuration under huge amount of resources to estimate the storage capacity of the application database is called Storage Testing. k) Data Volume Testing. During this testing Testers are calculating the number of records to be stored into application database. Note:

Storage Testing, Data volume Testing coverages same, but Storage Testing is representing in Number of bytes and Data Volume Testing is representing number of Records.

Manual Testing  

15

[email protected] 

Suresh.B –9440163282

GRAY BOX TESTING Gray Box Testing is a combination of “White Box Testing” and Black Box Testing. UAT (User Acceptance Test) After completion of Software Testing, the Project Management / Project Manager will invite customer to collect feedback on one developed software. They are (2) types such as

α

– Test

(Alfa Test) Æ Software Application. Æ By Real customer. Æ At development site.

β – Test (Beta Test) Æ Software Product. Æ By Model customer. Æ At customer site.

Release Testing It is also known as “Port Testing”. After completion of User Acceptance Test” and corresponding modifications, the Project Management will establish Release Team with few Developers, few Testers and One (or) two Hardware Engineers. This release team will go to customer’s site to install the software ion the customer’s environment. During this they will concentrate on below factors. Î Compact Installation. Î Overall functionality. Î Input device handling. Î Output device handling. Î OS Error handling. Î Secondary storage handling. Î Coexistence with other existence software. After completion of above like factor observation the release team is providing required training sessions to the customers to understand about the project.

16

Manual Testing

Suresh.B –9440163282

[email protected]

Maintenance During utilization of Software by customers, the company people are receiving change request from them. To receive change request from the customers the Project Management establish “CCB” (Change Control Board) with few Developers, few testers and Project Manager. CCB Receive change

Missed Defect

Enhancement

Impact Analysis Impact Analysis Perform changes Perform changes

Test S/w changes

Test S/w changes

Increase Testing process Capability

CASE STUDY TESTING STAGES Review in Analysis Review in Design Unit Testing Integration Testing Functional & System Testing User Acceptance Testing Release Testing / Port Testing

RESPONSIBLE PERSONS Analyst Designer Programmers Programmers Test Engineers / Testers Users / Customers CCB

TERMINOLOGY DEVELOPERS

TESTERS

Input Test Data Output Test Log Program Test Script Challenges in Testing Generally organizations are maintaining separate Testing for Functional and System Testing. This separate Testing team is also involving in Release Team and CCB. Some time this separate Testing team is also not able to conduct planned Testing or good testing due to some risks. Manual Testing  

17

Suresh.B –9440163282

[email protected] 

The risks are Î Lack of knowledge on project domain. Î Lack of communication. Î Lack of resources. Î Lack of time. Î Lack of Test Data. To overcome above like risks, the people are following “Ad-hoc” Testing. Planned Testing A Tester conduct Test on application build with pre-planned procedure is called Planned Testing. (or) A Tester conduct Test on application build by following formal methods are called Planned Testing. Ad-hoc Testing A Tester conduct test on application build without Pre-planed is called Ad-hoc Testing. (or) A Tester conduct test on application build by following “Informal Methods” is called “Ad-hoc Testing”. They are classified as (4) Types. (a) Monkey Testing. Due to lack of time, Testers are conducting test on major functionalities of the application build. This style of testing is called “Monkey Testing”. It is also known as Cheapening Testing. (b) Buddy Testing. Due lack of time, Testers are grouping with programmers to conduct Test on application as early as possible. This style of Testing is called as Buddy Testing. Buddy means a group of Programmers and Testers. (c) Pair Testing. Due to lack of knowledge on domain Junior Testers grouped with Senior Testers to share their knowledge. This style of testing is called Pair Testing. (d) Exploratory Testing. Due to lack of Test Data, Testers are conducting Test on application depending on available documents, discussions with other and get the requirements from customers. This style of testing called Exploratory Testing.

18

Manual Testing

Suresh.B –9440163282

[email protected]

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) 1) WATERFALL MODEL Requirement Gathering Analysis Design Coding Testing Release & Maintenance Î In this Model next stage starts after completion of previous stage. Î There is no overlapping between two stages. ADVANTAGES i) It is less expensive. ii) It works well for small applications. iii) It is flexible when the customer requirements are constant. DISADVANTAGES i) Testing is a single stage starts after coding. ii) If any defect is found during Testing, the rectification of that defect would be difficult. iii) It is “not flexible” to have changes in the customer requirements during developing the software. 2) INCREMENTAL WATERFALL MODEL Î To overcome some of the limitations of Waterfall we can use Incremental Waterfall model. Î Incremental Waterfall Model can be used Software Produce Development. Î In this Model a set of requirements they would be one working product. 1.0 Analysis Coding Testing R&M R.G Design R.G

Analysis

Design

Coding

Testing

R&M

R.G

Analysis

Design

Coding

Testing

R&M

Manual Testing  

2.0 3.0

19

[email protected] 

Suresh.B –9440163282

3) PROTOTYPE MODEL It is followable when the customer requirements are not clear. “Prototype means a sample Model of application without functionality. Not Clear Hardware Prototype

Software Prototype Demo to Client

Finalize Environment

Requirements refined

SRS Base lined

BRS Base lined

ADVANTAGES i) It is flexible when the customer requirements are not clear. DISADVANTAGES i) It is expensive 4) Spiral Model Î Spiral Model is followable when the customer requirements are enhanceble in terms of versions. Î In this Model we will start the process within complete requirements. Planning

Risk Analysis

Requirement Gathering 5.0 4.0  3.0  2.0  1.0 

Customer Evaluation Evaluation

ADVANTAGES It is flexible for high risk based projects. DISADVANTAGES It is expensive. 20

Coding and Testing Engineers

Manual Testing

Suresh.B –9440163282

[email protected]

5) V-MODEL Like as Fish Model “V-Model” is also defines the mapping between Development stages and Testing stages. In V-Model V stands for “Verification and Validation”. Verification To check whether the people are developing right product or not. Validation To check whether the developed product is right or not. Software Testing The “Verification and Validation” of a Software is called Software Testing. BRS

User Acceptance Testing

Requirement Gathering

System Testing

FRS

Black Box Testing

Analysis HLD Design

Integration Testing

LLD

White Box Testing

Unit Testing

Coding

Manual Testing  

21

Suresh.B –9440163282

[email protected] 

6) Agile Model ™ It is a latest model which is used in Software produce development. ™ In this model we can get build from the developers in very short time (1 to 4 Weeks) ™ In this model development process, testing process will be carried out parallelly. They are (2) methods such as (a) X-Tream Programming. (b) Scrum ADVANTAGES i) Any defect identified early, so that he rectification of the defect cost and time would be very less. ii) As the defect is identified early, the impact of the same defect is very less on subsequent features. DISADVANTAGES i) Documentation is very less.

Sanity Testing After receiving the build from the developers we people are conducting “Sanity Testing” to estimate stability of that build before start real testing. During this testing we will be concentrate on below factors. a) Understandable. b) Operatable. c) Observable. d) Controllable. e) Consistency. f) Automatable. g) Maintainable h) Simplicity. From the above (8) factors, Sanity Testing is also known as Build Verification Testing (BVT) or Tester Acceptance Testing (TAT) or Testability Testing or Oct-angle Testing. Smoke Testing Like as Sanity Testing, Smoke Testing is also used to estimate the stability of the Build.

22

Manual Testing

Suresh.B –9440163282

[email protected]

Re-Testing. Case 1: The repeating of same test for more than one time with multiple data is called as “Re-Testing”. Case 2: The re-execution of failed tests on modified build to ensure bug fixing work is called “Re-Testing” Regression Testing. The Re-execution of selected test or modified build, to check is there any side effects occurred or not on dependent functionalities by modifying reported defects or by adding new requirements. Types of Build They are (7) types of Build. They are (1) Initial Build

Initial Build

Development

Stable Build

Sanity Testing

Defect Effected Build Comprehensi ve Testing Modified Build

Bug Fixing

(2) Stable Build (3) Defect effected Build (4) Modified Build (5) Complete Build

Re-Testing Regression Testing

(6) Master Build (7) Golden Build

Complete Build Master Build

Test Closer (Test Lead)

U.A.T Golden Build

Sign off

Types of Projects Mainly there are (3) Types of projects. They are (1) Traditional Project (2) Outsourcing Project (3) Maintenance Project Type of Project R/G Analysis Design Coding Testing R&M Traditional 9 9 9 9 9 9 Outsourcing Maintenance

Manual Testing  

8 8

8 8

8 8

8 8

9 8

9 9 23

[email protected] 

Suresh.B –9440163282

MANUAL TESTING Testing Process Test Initiation (Project Management / Quality Analyst

Test Plan Document (Test Lead)

T.R.M (Test Responsibility Matrix)

1) Scope of the Project 2) Type of the Project 3) Risk involved in that Project

1) What to Test? 2) How to Test? 3) Who to Test? 4) Whom to Test?

Test Scenarios & Test Cases with Step by step procedure (Test Engineer / Tester)

Re-testing & Regression Testing

Test Case execution as Batches

Defect Report Bug fixing

Final Summary Report

Test Closer (Test Lead) UAT  Sign Off 

24

Manual Testing

Suresh.B –9440163282

[email protected]

PETT Process (Process Expert Tolls and Techniques) Requirement Gathering Analysis

Design

Test initiation 

Coding

Test Plan Document Test Scenarios & Test Case with Step by step process (1) Initial Build Level ‘0’ Testing / Sanity Testing

Level ‘2’ Testing Re-Testing / Regression Testing  (4) Modified Build

(2) Stable Build Level ‘1’ Testing / Comprehensive Testing / Batch Testing 

Defect Report

Bug Fixing

(3) Defect Effected Build

(5) Complete Build

Level ‘3’ Testing / Test Closure / Postmortem Testing / Pre-acceptance Testing  (6) Master Build User Acceptance Testing (7) Golden Build Sign Off

Manual Testing  

25

[email protected] 

Suresh.B –9440163282

Testing Initiation: In general testing process start with “Test initiation”. In this, Project Manager / Quality Analyst develop Test starting Document. This document defines the required testing approach to be followed by the testing team. During this document preparation they will concentrate on below (12) components. 1) 2) 3) 4) 5) 6)

Scope & Objective. Budget Control. Test approach. Roles & Responsibilities Communication & Status Reporting Test deliverables

7) 8) 9) 10) 11) 12)

Test Automation Defect Tracing & Reporting Measurements & Matrix. Change & Configuration Management Risks & Mitigations Training Plan.

1) Scope & Objective: The need of testing in the project. 2) Budget Control. Time & Cost allocation to the project. Ex: As per U.S. Norms 100%

64% Development Department

36% Testing Department

#  3) Test approach ##  In this they will specify a list of selected quality factors to be applied by the Tester. T.R.M (Test Responsibility Matrix) can be finalized by Project Manager / Quality Analyst based on scope of the project, type of the project and Risks involved in that project. TRM :

It defines the mapping between Test factors and Development Stages.

26

Manual Testing

Suresh.B –9440163282

[email protected]

Quality Factors / Test Factors 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13)

Design

Function & Coding System R&M Testing

Authorization Access Control Ease of use Ease of operation Correctness Continuity & Processing Coupling Data integrity Recovery Portable Service Level Performance Maintainable Methodology Audit trail. Authorization: Whether a valid user is accessible or not and Invalid User is preventable or not. Access control: Whether a valid user have permission to user specific service of not Ease of Use: Whether the application build is providing user friendly screens or not. Ease of operate: Easy to installation, downloading, uploading, dumping, un-installing. Correctness: Whether the functionality output is right or wrong. Continuity & processing: The integration of modules. Coupling: Co-existence with other Software. Data Integrity: Whether the input objects are taking right type and range of values or not. Recovery: Whether the application build is changing from abnormal state to normal state or not. Portable: Whether the application build is able to run on different platforms or not. Service Level: The order of functionality. Performance: The speed of processing. Maintainable: Whether the application build is longtime serviceable in customers site or not.

Manual Testing  

RG & Analysis

27

[email protected] 

Suresh.B –9440163282

14) Methodology:

Whether the people (Tester) are following right process of not. If not he will be punishable.

15) Audit Trail:

Whether the system is maintains data for the user operation (Ex. Bank Application, Withdrawal time, ATM Centre Code etc.,)

1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15)

Authorization Access Control Ease of use Ease of operation Correctness Continuity & Processing Coupling Data integrity Recovery Portable Service Level Performance Maintainable Methodology Audit trail.

Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ

Security Testing Security Testing User interface Testing Installation Testing Functionality Testing Integration Testing Intersystem Testing Input domain Testing Recovery Testing Compatibility Testing Functionality Testing Load, Stress, Storage, Data volume Testing Stress Testing Compliance Testing Functionality Testing

4) Roles and Responsibilities Name of the jobs and his / her responsibilities. 5) Communication n& Status reporting The required communication between two consecutive jobs. Ex: Project Management Test Lead Test Engineer When do report? Weekly Once, twice, daily etc., 6) Test deliverables The required documents to be prepared by the testing team. The following documents were prepared by the Test lead and Test engineers. Test Plan, Test Scenario, Test Cases, Test Data, Test log, Defect report, Final Summery Report etc., 7) Test automation The purpose of Automation testing in the project and available tools in the organization. 28

Manual Testing

Suresh.B –9440163282

[email protected]

8) Defect tracing & Reporting. The required communication between Programmers and Testers when Test Engineer / Tester got a mismatch. Large Scale Small Scale Project Management

Test Lead

Project Lead

Project Management

Test Lead

Team Lead

Test Engineer

Programmer

Team Lead Test Engineer

Programmer

Transmittal Report 9) Measurement & Matrix: The required measurement to estimate the status of the project. In measurements there are (3) types such as (1) Quality Assessment Measurement (2) Test Management Measurement (3) Process Capability Measurement. 10) Change & Configuration Management How to handle change request from the customer and how to store the documents for future reference. 11) Risk & Mitigations: The possible risks and solutions to overcome them. 12) Training Plan: The required training secession to the Testing team to understand about the project.

Manual Testing  

29

[email protected] 

Suresh.B –9440163282

TEST PLAN After completion of Test Strategy Document, the strategy of the Project implemented by Test Lead in the Project through Test Plan. During Test Plan Document preparation, Test Lead category people follows below approach. BRS

a) Team formation b) Identify risks

TRM Development Plan

c) Prepare Test Plan d) Review Test Plan

System Test Plan Module Test Plan (if project is big then only Module Test Plan is to be prepared)

a) Team Formation: In general Test Plan Document preparation starts with Team formation. In this Test Lead category people form the Testing Team depending on below factors. i. ii. iii. iv.

Project size. Project duration. Availability of domain testers. Resources (Automation Tools)

b) Identify Risks After completion of Team Formation the Test Lead identifies risks with respect to that formed testing team in Testing. i. ii. iii. iv. v. vi. vii.

30

Lack of time. Lack of resources. Lack of communication. Lack of knowledge on project domain. Lack of test data. Lack of development process rigor. Delays in delivery.

Manual Testing

[email protected]

1) 2) 3) 4) 5) 6) 7) 8)

Suresh.B –9440163282

c) Prepare Test Plan After completion of Team formation and Risk Analysis, Team Lead will prepare Test Plan Document in IEEE (Institute of Electrical & Electronic Engineer) Format (829) Test Plan ID 9) Exit Criteria Introduction 10) Test deliverables Test items 11) Test environment Features to be tested 12) Staff & Training needs Features not to be tested 13) Responsibilities Test approach 14) Schedule Entry criteria 15) Risks & Mitigations Suspension Criteria 16) Approved by

1)

Test Plan ID: Unique number for feature reference.

2)

Introduction Introduction about the project or module.

3)

Test items The name of the requirements or features.

4)

Features to be tested The name of the requirements or features to be test.

5)

Features not to be tested The name of the requirements or features not to be test

6)

Test approach The list of selected quality factors to be applied by the Tester.

7)

Entry criteria When to start Testing Î Take complete and correct Test cases. Î Create Test Environment. Î Receive Stable Build from the developers.

8)

Suspension criteria When to suspend testing temporarily Î When we have network problem. Î If pending defects are more (Pending defects = No. of reported defects – No. of resolved defects)

Manual Testing  

31

Suresh.B –9440163282

9)

[email protected] 

Exit criteria When to stop testing Î After completion of all module testing. Î After completion of all Major bugs resolved.

10)

Test deliverables The required documents to be prepared by the Testers. Ex.: Test Scenarios, Test Cases, Test Scripts, Test Data, Test log, Defect Report, FSR ………… etc., 11)

Test environment The required Software and Hardware to conduct Testing.

12)

Staff and Training needs The names of selected testers and their training needs.

13)

Responsibilities Work allocation to the testers. Ex. Modules Vs. Testers.

14)

Schedule Time duration to the testers.

15)

Risks and Mitigations The required solutions for the previously analyzed risks.

16)

Approved by Who approved the document, the signature of the Project Manager. Name of the Test Lead.

d) Review Test Plan: Completion of Test Plan Document preparation, Test Lead is conducting Review Meeting to estimate completeness and correctness of that document. During this review they will concentrate on below coverages. (i) Requirements Based Coverage (What to Test?) (ii) Risk Based Coverage (Who to Test & When to Test?) (iii) TRM Based Coverage (How to test?)

32

Manual Testing

[email protected]

Suresh.B –9440163282

TEST SCENARIOS & TEST CASE DESIGN After completion of Test Plan Document and corresponding Reviews Test Lad allocate the work to the Testers. Testers are preparing corresponding Test Scenarios and Test Caes based on Requirement Specifications. USE CASE Use Case is a required document which maintenance the detail information about one low level requirement. If you want to design Test Cases based on Use Cases, we can study the Use Case below approach. USE CASE FORMAT: Title Requirement Description Actors / Users Pre-operation Action Positive Flows Exceptions / Negative flows Alternative flows / Alternative Positive flows 1) Collect all Use Cases. 2) Take one Use Case and Study. 2.1) Identity Entry Point. 2.2) Identity Input Requirement 2.3) Identity Outputs 2.4) Identity Alternative flows and exceptions. 2.5) Identity exit point. 3) Prepare scenarios. 4) Review scenarios. 5) Prepare Test Cass with step by step procedure. 6) Continue from step (2) to (6) until completion of all Use Cases. TEST SCENARIOS Test Scenarios means Test situations. Test Scenario Template These templates are created in MS Excel. Project Name: Reviewed by Module Name: Created by: Reviewed by Created on: Sl. No. Requirement Name Test Scenario Test Cases

Manual Testing  

33

Suresh.B –9440163282

[email protected] 

TEST CASES A set of Test steps documented along with required inputs and expected results in order to test one low level requirement. Thinks to remember while designing the Test Cases. 1) Test Case should be simple and clear. 2) Test Case should be complete. 3) No duplicate Test Case should b written. TEST CASE TYPE 1) User Interface Test Cases. 2) Usability Test Cases. 3) Validation Test Cases. 4) Functional Test Cases. 1) User Interface Test Cases To verify the look and Feel of application build screens. Ex: Font Size, Text alignment, Images etc., 2) Usability Test Cases To verify ease of use of application build screens. Ex: a) Default cursor should be present at the first field. b) Tab keys should be implemented for all input objects from left to right in downward direction. c) Shortcut keys should be implemented for all menu operation. d) Tool tips (Whenever we place the cursor on particular object, it should return meaningful message) 3) Validation Test Cases: Test Cases that are required to validate business rules or field validation. 4) Functional Test Cases: Test Cases that are required to validate the functionality. TEST DESIGN TECHNIQUES They are mainly (5) types of design techniques. (1) Boundary Value Analysis (BVA) (2) ECP (Equal Class Partition) (3) Error Guessing (4) Decision Tables (5) State transition. 34

Manual Testing

Suresh.B –9440163282

[email protected]

(1)

BVA: It is used to validate the range of input objects.

(2)

ECP: Î Splitting the inputs into equal parts and randomly checking them. Î To verify the type of input objects.

(3)

Error Guessing It is a technique which can be used by the people, who have prior knowledge on that application (Ex. This can be used by experts)

(4)

Decision Tables A Black Box Test Design testing in which test cases are designed to execute the combination of inputs.

(5)

Valid Invalid

Valid

Invalid

Valid Valid

Invalid

Valid

State Transition A Black Box Test design techniques, in which test cases are designed to execute valid, invalid state transition.

Insert card Block Card

Wait for PIN Entry

PIN Wrong PIN Wrong

2

nd

PIN Wrong

Entry

1st Entry

3rd Entry PIN Ok PIN Ok

PIN Ok Access Account

Manual Testing  

35

[email protected] 

Suresh.B –9440163282

TEST CASE TEMPLATE Test Case Test Case Step Step Priority Name / ID Description Name Description 1 2 3 4 5 Expected Results 7

Actual Created Created Status Comments Results By on 8 9 10 11 12

QC Path 13

Test Data 6

Reviewed By 14

Reviewed On 15

Reviewer’s Comments 16

1)

Test Case Name / ID: Unique Number for future reference Ex: TC001_Project Name_Module Name_Functionality Name

2)

Test Case Description: The description about that Test case. Î Pre-requisites Î Documents referred.

3)

Priority Importance of the Test Case. They are classified into (3) Types such as (1) High Priority (Basic functionality Test Cases) (2) Medium Priority (General functionality Test Cases – Recovery, Compatibility Testing etc.,) (3) Low Priority (Cosmetic Test Cases – User Interface Testing)

4)

Step Name Every Test Case divided into multiple steps, every step in the test case will have unique number. Ex: Step–1; Step–2; Step–3 etc.,

5)

Step Description The required action to be performed by the user.

6)

Test Data Set of inputs that are required to execute steps.

36

Manual Testing

[email protected]

Suresh.B –9440163282

7)

Expected Results The required expected output from the system for the corresponding user action.

8)

Actual Results The actual output of the system after performing user action.

9)

Status The current position of the Test Case. They are classified into (4) types, such as (a) No Run: Test Case not executed atleast for once. (b) Not complied: A partially executed test case. (c) Passed: Test Case executed and the expected value and Actual value is same, “Test is passed”. (d) Failed: Test Case any step(s) expected values mismatched with actual value, “Test is failed”.

10)

Created By The name of the Test Engineer, who created the Test Cases.

11)

Created on Date and Time of the created Test Case.

12)

Comments A set of comments given by Tester for the Step or Test Cases.

13)

QC Path The path of Quality Control.

14)

Reviewed By Name of the Reviewer.

15)

Reviewed on When (Date & Time) the document was reviewed by reviewer.

16)

Reviewer’s Comments A set of comments given by reviewer.

Manual Testing  

37

Suresh.B –9440163282

[email protected] 

CASE STUDY

38

Manual Testing

[email protected]

Suresh.B –9440163282

User Name User Name object allows alphabets lower case range from 4 to 8 characters. Password Password object allows alphabets lower case range from 6 to 10 characters. Customer Name Î Customer Name object allows alphabets. Î Range from 4 to 12 characters. Î First letter should be Upper Case. Î Mandatory. Customer Address Î Customer Address object allows alpha-numeric and some special Characters (“–“ “/” “#” “,” “.”) Î Maximum of 20 Characters. Î Mandatory. Customer DOB Î Customer DOB object allows Numeric Only. Î The format is MM/DD/YYYY. Î Date should be less than current system date. Î Mandatory. Customer Ph.No. Î Customer Ph.No. object allows Numeric Only. Î Allows 10 digits only. Î Phone number is unique. Î Mandatory. E–Mail Î Î Î

E-Mail object allows alpha-numeric and special Characters. Format is [email protected]. It is not mandatory.

Manual Testing  

39

[email protected] 

Suresh.B –9440163282

TEST SCENARIO DOCUMENT Project Name: Module Name: Created by: Created on: Sl. No. 1

Customer Info Admin Suresh 18/10/2008 Requirement Name

Reviewed by Reviewed by Test Scenario Ok

Login Cancel Insert

2

Add

Cancel Search 3

Search Cancel Update

4

5 6 7 8

Edit

Delete Cancel Home Logout

Cancel Home Delete Cancel Home Logout

Test Cases 1) 2) 3) 1) 2)

Verify Ok with valid data. Verify Ok with invalid data. Verify Cancel Verify Insert with valid data. Verify Insert with invalid data. 3) Verify Insert with duplicate data. 4) Verify Insert with missing mandatory fields. 5) Verify Cancel 1) Verify Search with valid data. 2) Verify Search with invalid data. 3) Verify Cancel 1) Verify Update with valid data. 2) Verify Update with invalid data. 3) Verify Update with duplicate data. 4) Verify Update with missing mandatory fields. 5) Verify Cancel 6) Verify Home Verify Delete Verify Cancel Verify Home Verify Logout

Note:

RCN (Requirement Clarification Note) Any doubt in FRS / BRS Document, we people design RCN Document and the same will be sent to BDP for clarification. 40

Manual Testing

Suresh.B –9440163282

[email protected]

TEST CASE DOCUMENT Test Case Test Case Step Step name description Name Description This Test Step-1 Open Brower, TC01_ enter Url. case Customer Address, click Info_Admin_ validates on Go Verify Ok ‘Ok’ with Valid functionality Step-2 Enter valid with valid data User Name data and Password click on Ok This Test Step-1 Open Brower, TC02_ enter Url. case Customer Address, click Info_Admin_ validates on Go Verify Ok ‘Ok’ with invalid functionality Step-2 Enter invalid with invalid data User Name data and Password click on Ok TC03_ This Test Step-1 Open Brower, Customer case enter Url. Info_Admin_ validates Address, click Verify Cancel Cancel on Go User functionality Step-2 Enter

Test Data Url

User Name & Pass word

Url

User Name & Pass

Expected Result It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. It should display Customer Information page with Add, Search, Logout functionalities. It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. It should display meaningful error message.

word

It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. User It should clear all fields Name and Name and cursor should be Password click & Pass present in the first field. on Cancel

TC04_ Customer Info_Admin_ Verify Insert with Valid data

word

Url It should display Login This Test Step-1 Open Brower, enter Url. Page with User Name, case Address, click Password objects and Ok, validates on Go Cancel functionalities. ‘Insert’ functionality Step-2 Enter should display valid User It with valid Information User Name Name Customer data and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on Add -It should display Add Customer page with C.Name, C.Addr., C.DOB, C.Ph.No., Email objects and Insert, Reset, Cancel functionalities.

Manual Testing  

Url

41

[email protected] 

Suresh.B –9440163282

Test Case name

Test Case description

Step Step Name Description Step-4 Enter data in corresponding fields and click on Reset

Test Data C.Name C.Addr. C.DOB C.PhNo E-mail C.Name C.Addr. C.DOB C.PhNo E-mail

Expected Result It should clear all fields and cursor should be present in the first field.

Step-5 Enter valid It should display a data in meaningful Message corresponding such as “Customer Data fields and created with Customer click on Insert ID” Url It should display Login This Test Step-1 Open Brower, TC05_ enter Url. Page with User Name, case Customer Address, click Password objects and Ok, Info_Admin_ validates on Go Cancel functionalities. Verify Insert ‘Insert’ with invalid functionality Step-2 Enter should display valid User It with invalid data Information User Name Name Customer data and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on Add -It should display Add Customer page with C.Name, C.Addr., C.DOB, C.Ph.No., Email objects and Insert, Reset, Cancel functionalities. Step-4 Enter invalid C.Name It should display a data in C.Addr. meaningful Error C.DOB corresponding Message. C.PhNo fields and E-mail click on Insert Url It should display Login This Test Step-1 Open Brower, TC06_ enter Url. Page with User Name, case Customer Address, click Password objects and Ok, Info_Admin_ validates on Go Cancel functionalities. Verify Insert ‘Insert’ functionality Step-2 Enter with should display valid User It duplicate data with Information User Name Name Customer duplicate and Password & Pass page with Add, Search, word Logout functionalities. data click on Ok Step-3 Click on Add -It should display Add Customer page with C.Name, C.Addr., 42

Manual Testing

Suresh.B –9440163282

[email protected]

Test Case name

Test Case description

Step Name

Step-4

TC07_ Customer Info_Admin_ Verify Insert with missing mandatory fields

This Test Step-1 case validates ‘Insert’ functionality Step-2 with missing mandatory fields Step-3

Step-4

TC08_ Customer Info_Admin_ Verify Cancel

This Test Step-1 case validates ‘Cancel’ functionality Step-2

Manual Testing  

Step Description

Test Data

Expected Result

C.DOB, C.Ph.No., Email objects and Insert, Reset, Cancel functionalities. C.Name It should display a Enter duplicate data C.Addr. meaningful Error C.DOB in Message. C.PhNo corresponding E-mail fields and click on Insert Open Brower, Url It should display Login enter Url. Page with User Name, Address, click Password objects and Ok, on Go Cancel functionalities. should display Enter valid User It Information User Name Name Customer and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Click on Add -It should display Add Customer page with C.Name, C.Addr., C.DOB, C.Ph.No., Email objects and Insert, Reset, Cancel functionalities. Enter data in C.Name It should display a corresponding C.Addr. meaningful Error C.DOB fields by Message. C.PhNo missing some E-mail mandatory fields and click on Insert Open Brower, Url It should display Login enter Url. Page with User Name, Address, click Password objects and Ok, on Go Cancel functionalities. should display Enter valid User It Information User Name Name Customer and Password & Pass page with Add, Search, word Logout functionalities. click on Ok 43

[email protected] 

Suresh.B –9440163282

Test Case name

Test Case description

Step Step Name Description Step-3 Click on Add

Test Data --

Expected Result

It should display Add Customer page with C.Name, C.Addr., C.DOB, C.Ph.No., Email objects and Insert, Reset, Cancel functionalities. Step-4 Enter data in C.Name It should close current corresponding C.Addr. page and display C.DOB fields and click previous page. on Cancel

C.PhNo E-mail

Url It should display Login This Test Step-1 Open Brower, enter Url. Page with User Name, case Address, click Password objects and Ok, validates on Go Cancel functionalities. ‘Search’ functionality Step-2 Enter valid User It should display with valid User Name Name Customer Information data and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on -It should display Search Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. Step-4 Enter data in C.ID It should clear all fields corresponding C.Name and cursor should be fields click on C.DOB present in the first field. C.PhNo Reset valid C.ID It should display Search Step-5 Enter data in C.Name Results Page with corresponding C.DOB Customers Information fields and click C.PhNo and Edit, Delete, Cancel, on Search Home functionalities. Url It should display Login This Test Step-1 Open Brower, TC10_ enter Url. Page with User Name, case Customer Address, click Password objects and Ok, Info_Admin_ validates on Go Cancel functionalities. Verify Search ‘Search’ with invalid functionality Step-2 Enter valid User It should display with invalid data User Name Name Customer Information TC09_ Customer Info_Admin_ Verify Search with valid data

44

Manual Testing

Suresh.B –9440163282

[email protected]

Test Case name

Test Case description data

Step Name

Step Test Description Data and Password & Pass word click on Ok Step-3 Click on -Search

Expected Result

page with Add, Search, Logout functionalities. It should display Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. Step-4 Enter invalid C.ID It should display C.Name data in meaningful error C.DOB corresponding message. fields and click C.PhNo on Search

TC11_ Customer Info_Admin_ Verify Cancel

This Test Step-1 Open Brower, Url It should display Login case enter Url. Page with User Name, validates Address, click Password objects and Ok, ‘Cancel’ on Go Cancel functionalities. functionality Step-2 Enter valid User It should display User Name Name Customer Information and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on -It should display Search Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. Step-4 Enter data in C.ID It should close current corresponding C.Name page and display fields and click C.DOB previous page. on Cancel

TC12_ Customer Info_Admin_ Verify Update with valid data

Url It should display Login This Test Step-1 Open Brower, enter Url. Page with User Name, case Address, click Password objects and Ok, validates on Go Cancel functionalities. ‘Update’ functionality Step-2 Enter valid User It should display User Name Name Customer Information and Password & Pass page with Add, Search, word Logout functionalities. click on Ok

Manual Testing  

C.PhNo

45

[email protected] 

Suresh.B –9440163282

Test Case name

Test Case description

Step Step Name Description Step-3 Click on Search

Test Data --

valid C.ID data in C.Name corresponding C.DOB fields and click C.PhNo on Search

Step-4 Enter

Step-5 Select a Customer data click on Edit

Step-6 Enter data in corresponding fields click on Reset

-

Expected Result It should display Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. It should display Edit Page with C.ID, C.Name, C.Addr., C.DOB, C.Ph.No., E-mail objects and Update, Reset, Cancel, Home functionalities. It should clear all fields and cursor should be present in the first field.

C.ID C.Name C.DOB C.Addr. C.PhNo E-mail C.ID It should display “Update C.Name done” message. C.DOB C.Addr. C.PhNo E-mail

Step-7 Enter valid data in corresponding fields click on update Url It should display Login This Test Step-1 Open Brower, TC13_ enter Url. Page with User Name, case Customer Address, click Password objects and Ok, Info_Admin_ validates on Go Cancel functionalities. ‘Update’ Verify Update with functionality Step-2 Enter valid User It should display with invalid invalid data User Name Name Customer Information data and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on -It should display Search Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, 46

Manual Testing

Suresh.B –9440163282

[email protected]

Test Case name

Test Case description

Step Name

Step Description

Test Data

valid C.ID data in C.Name corresponding C.DOB fields and click C.PhNo on Search

Step-4 Enter

Step-5 Select a Customer data click on Edit

Step-6 Enter invalid data in corresponding fields click on update This Test Step-1 Open Brower, TC14_ enter Url. case Customer Address, click Info_Admin_ validates on Go ‘Update’ Verify Update with functionality Step-2 Enter valid duplicate data with User Name duplicate and Password data click on Ok Step-3 Click on Search

-

C.ID C.Name C.DOB C.Addr. C.PhNo E-mail

Url

User Name & Pass word

--

valid C.ID data in C.Name corresponding C.DOB fields and click C.PhNo on Search

Step-4 Enter

Manual Testing  

Expected Result Reset, Cancel functionalities. It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. It should display Edit Page with C.ID, C.Name, C.Addr., C.DOB, C.Ph.No., E-mail objects and Update, Reset, Cancel, Home functionalities. It should display meaningful error message.

It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. It should display Customer Information page with Add, Search, Logout functionalities. It should display Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. 47

[email protected] 

Suresh.B –9440163282

Test Case name

Test Case description

Step Step Name Description Step-5 Select a Customer data click on Edit

Step-6

TC15_ Customer Info_Admin_ Verify Update with missing mandatory fields

This Test Step-1 case validates ‘Update’ functionality Step-2 with missing mandatory fields Step-3

Step-4

Expected Result

-

It should display Edit Page with C.ID, C.Name, C.Addr., C.DOB, C.Ph.No., E-mail objects and Update, Reset, Cancel, Home functionalities. C.ID Enter It should display C.Name duplicate data meaningful error C.DOB in message. C.Addr. corresponding C.PhNo fields click on E-mail update Open Brower, Url It should display Login enter Url. Page with User Name, Address, click Password objects and Ok, on Go Cancel functionalities. Enter valid User It should display User Name Name Customer Information and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Click on -It should display Search Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. Enter valid C.ID It should display Search data in C.Name Results Page with C.DOB corresponding Customers Information fields and click C.PhNo and Edit, Delete, Cancel, on Search Home functionalities.

Step-5 Select a Customer data click on Edit

48

Test Data

-

It should display Edit Page with C.ID, C.Name, C.Addr., C.DOB, C.Ph.No., E-mail objects and Update, Reset, Cancel, Home functionalities. Manual Testing

Suresh.B –9440163282

[email protected]

Test Case name

Test Case description

Step Step Name Description Step-6 Enter data in corresponding fields by missing some mandatory fields and click on update TC16_ This Test Step-1 Open Brower, Customer case enter Url. Info_Admin_ validates Address, click Verify Cancel Cancel on Go functionality Step-2 Enter valid User Name and Password click on Ok Step-3 Click on Search

Test Data

C.ID It should C.Name meaningful C.DOB message. C.Addr. C.PhNo E-mail

Url

User Name & Pass word

--

valid C.ID data in C.Name corresponding C.DOB fields and click C.PhNo on Search

Step-4 Enter

Step-5 Select a Customer data click on Edit

Expected Result

-

display error

It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. It should display Customer Information page with Add, Search, Logout functionalities. It should display Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. It should display Edit Page with C.ID, C.Name, C.Addr., C.DOB, C.Ph.No., E-mail objects and Update, Reset, Cancel, Home functionalities.

Step-6 Enter data in corresponding fields and click on Cancel Manual Testing  

C.ID It should close current C.Name page and display C.DOB Previous Page. C.Addr. C.PhNo E-mail

49

[email protected] 

Suresh.B –9440163282

Test Case name TC17_ Customer Info_Admin_ Verify Home

Test Case Step Step Test Expected Result description Name Description Data This Test Step-1 Open Brower, Url It should display Login case enter Url. Page with User Name, validates Address, click Password objects and Ok, Cancel on Go Cancel functionalities. functionality Step-2 Enter valid User It should display User Name Name Customer Information and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on -It should display Search Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. C.ID valid Step-4 Enter It should display Search data in C.Name Results Page with corresponding C.DOB Customers Information fields and click C.PhNo and Edit, Delete, Cancel, on Search Home functionalities. Step-5 Select a Customer data click on Edit

-

It should display Edit Page with C.ID, C.Name, C.Addr., C.DOB, C.Ph.No., E-mail objects and Update, Reset, Cancel, Home functionalities.

Step-6 Enter data in corresponding fields and click on Home TC18_ This Test Step-1 Open Brower, Customer case enter Url. Info_Admin_ validates Address, click Verify Delete Delete on Go functionality Step-2 Enter valid User Name and Password click on Ok 50

C.ID It should close current C.Name page and display C.DOB Customer Info Page. C.Addr. C.PhNo E-mail

Url

It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. User It should display Name Customer Information & Pass page with Add, Search, word Logout functionalities. Manual Testing

Suresh.B –9440163282

[email protected]

Test Case name

Test Case description

Step Step Name Description Step-3 Click on Search

Test Data --

valid C.ID data in C.Name corresponding C.DOB fields and click C.PhNo on Search

Step-4 Enter

Step-5 Select a Customer data click on Delete TC19_ Customer Info_Admin_ Verify Cancel

-

Url This Test Step-1 Open Brower, enter Url. case Address, click validates on Go Cancel functionality Step-2 Enter valid User User Name Name and Password & Pass word click on Ok Step-3 Click on -Search

valid C.ID data in C.Name corresponding C.DOB fields and click C.PhNo on Search

Step-4 Enter

Step-5 Select a Customer data click on Cancel Manual Testing  

-

Expected Result It should display Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. It should remove customer’s information with “Customers Information was successfully deleted”. It should display Login Page with User Name, Password objects and Ok, Cancel functionalities. It should display Customer Information page with Add, Search, Logout functionalities. It should display Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. It should display Search Results Page with Customers Information and Edit, Delete, Cancel, Home functionalities. It should close current page and display previous page. 51

Suresh.B –9440163282

[email protected] 

Test Case name TC20_ Customer Info_Admin_ Verify Home

Test Case Step Step Test Expected Result description Name Description Data This Test Step-1 Open Brower, Url It should display Login case enter Url. Page with User Name, validates Address, click Password objects and Ok, Home on Go Cancel functionalities. functionality Step-2 Enter valid User It should display User Name Name Customer Information and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on -It should display Search Search Page with C.ID, C.Name, C.DOB, C.Ph.No., objects and Search, Reset, Cancel functionalities. C.ID valid Step-4 Enter It should display Search data in C.Name Results Page with corresponding C.DOB Customers Information fields and click C.PhNo and Edit, Delete, Cancel, on Search Home functionalities. Step-5 Select a It should close current Customer page and display data click on Customer Info Page. Home TC21_ This Test Step-1 Open Brower, Url It should display Login Customer case enter Url. Page with User Name, Info_Admin_ validates Address, click Password objects and Ok, Verify Logout on Go Cancel functionalities. Logout functionality Step-2 Enter valid User It should display User Name Name Customer Information and Password & Pass page with Add, Search, word Logout functionalities. click on Ok Step-3 Click on It should close current Logout page and display Login Page

52

Manual Testing

Suresh.B –9440163282

[email protected]

User Name User Name object allows alphabets lower case range from 4 to 8 characters.

Range Min= 4 Char Min-1= 3 Char Min+1= 5 Char Max= 8 Char Max-1= 7 Char Max+1= 9 Char

BVA & ECP for User Name BVA Expected Actual Result Pass Fail Pass Pass Pass Fail

ECP Valid [a-z]

Invalid [A-Z] [0-9] All Special characters

Password Password object allows alphabets lower case range from 6 to 10 characters. BVA & ECP for Password BVA ECP Range Expected Actual Result Valid Invalid [a-z] [A-Z] Pass Min= 6 Char [0-9] Min-1= 5 Char Fail All Min+1= 7 Char Pass Special Pass Max= 10 Char characters Max-1= 9 Char Pass Max+1= 11 Char Fail Customer Name Î Customer Name object allows alphabets. Î Range from 4 to 12 characters. Î First letter should be Upper Case. Î Mandatory. BVA & ECP for Customer Name BVA Range Expected Actual Result Pass Min= 4 Char Fail Min-1= 3 Char Pass Min+1= 5 Char Pass Max= 12 Char Max-1= 11 Char Pass Max+1= 13 Char Fail Manual Testing  

ECP Valid [a-z] [A-Z]

Invalid [0-9] All Special characters

53

Suresh.B –9440163282

[email protected] 

Customer Address Î Customer Address object allows alpha-numeric and some special Characters (“–“ “/” “#” “,” “.”) Î Maximum of 20 Characters. Î Mandatory. BVA & ECP for Customer Address BVA ECP Range Expected Actual Result Valid Invalid All Max= 20 Char Pass [a-z] Special Max-1= 19 Char Pass [A-Z] characters Max+1= 21 Char Fail [0-9] Except Some Spl. Characters mentioned –/#,. Customer DOB Î Customer DOB object allows Numeric Only. Î The format is MM/DD/YYYY. Î Date should be less than current system date. Î Mandatory. BVA & ECP for Customer DOB BVA ECP Range Expected Actual Result Valid Invalid All Max= 20 Char Pass [a-z] Special Max-1= 19 Char Fail [A-Z] characters Max+1= 21 Char Pass [0-9] Except Some Spl. Characters mentioned –/#,. Customer Ph.No. Î Customer Ph.No. object allows Numeric Only. Î Allows 10 digits only. Î Phone number is unique. Î Mandatory. BVA & ECP for Customer Ph.No. BVA ECP Range Expected Actual Result Valid Invalid Max= 10 Digits Pass [0-9] [a-z] Max-1= 19 Digits Fail [A-Z] Max+1= 21 Digits Pass All Spl. Characters 54

Manual Testing

[email protected]

Suresh.B –9440163282

TEST DATA DOCUMENT Project Name Reviewed by Module Name Created By Reviewed on Created on Sl. Test Case Step Data Data generated Comments No. Name Name required Stephttp://192.168.1.0 Url 1 /Customer Info 1.0 1) rama TC01_ User 2) rames Customer Name 3) gahesha 1 Info_Admin_ 4) reliance StepVerify Ok with 2 1) suresh Valid data 2) sureshb Password 3) sureshbug 4) sureshbuga Stephttp://192.168.1.0 Url 1 /Customer Info 1.0 1) ram TC02_ User 2) sureshbug Customer Name 3) ga*1 2 Info_Admin_ 4) ram@123 StepVerify Ok with 2 1) sures invalid data 2) sureshbugat Password 3) SURESH 4) sarvani@bu Stephttp://192.168.1.0 TC03_ Url 1 /Customer Info 1.0 Customer 3 Info_Admin_ Step- U.Name pava Verify Cancel 2 Password ganesh Stephttp://192.168.1.0 Url 1 /Customer Info 1.0 Step- U.Name pava TC04_ 2 Password ganesh Customer Ramu 4 Info_Admin_ Sita Verify Insert C.Name Ramakrishna Stepwith Valid data Koteswararao 5 Koti,D.No.-5/G C.Addr. Brundavancolony7/G-3  

Manual Testing  

55

[email protected] 

Suresh.B –9440163282

Sl. No.

Test Case Name

5

TC05_ Customer Info_Admin_ Verify Insert with invalid data

6

TC06_ Customer Info_Admin_ Verify Insert with duplicate data

7

TC07_ Customer Info_Admin_ Verify Insert with missing mandatory fields

8

TC08_ Customer Info_Admin_

56

Step Data Data generated Comments Name required C.DOB 05/25/1976 C.Ph.No. 9440163282 suresh_240878@ E-mail yahoo.com Stephttp://192.168.1.0 Url 1 /Customer Info 1.0 Step- U.Name pava 2 Password ganesh Sai C.Name Saisarvanibug Brundavancolony7/G*3 C.Addr. Brundavanacolony Step7/G-3 4 C.DOB 25/10/1976 C.Ph.No. +91-9440163282 suresh_240878# E-mail yahoo.com Stephttp://192.168.1.0 Url 1 /Customer Info 1.0 Step- U.Name pava 2 Password ganesh C.Name Koteswararao C.Addr. Brundavancolony7/G-3 Step- C.DOB 05/25/1976 4 C.Ph.No. 9440163282 suresh_240878@ E-mail yahoo.com Stephttp://192.168.1.0 Url 1 /Customer Info 1.0 Step- U.Name pava 2 Password ganesh C.Name Koteswararao C.Addr. Brundavancolony7/G-3 Step- C.DOB 05/25/1976 4 C.Ph.No. 9440163282 suresh_240878@ E-mail yahoo.com Step1

Url

http://192.168.1.0 /Customer Info 1.0 Manual Testing

Suresh.B –9440163282

[email protected]

Sl. No.

Test Case Name Verify Cancel

Step Data Name required Step2 Step4

9

TC09_ Customer Info_Admin_ Verify Search with valid data

Manual Testing  

Step1 Step2 Step5

Data generated

Comments

U.Name Password C.Name C.Addr. C.DOB C.Ph.No.

pava ganesh Koteswararao Brundavancolony7/G-3 05/25/1976 9440163282 suresh_240878@ E-mail yahoo.com http://192.168.1.0 Url /Customer Info 1.0 U.Name pava Password ganesh C.Name Koteswararao C.DOB 05/25/1976 C.Ph.No. 9440163282

57

[email protected] 

Suresh.B –9440163282

Review on Test Cases After completion of Test Case preparation, Test Engineer is conducting Peer Review and Test Lead is conducting Lead Review to estimate “Completeness and Correctness” of that document PM

TE-1

PL

TE-2

Peer Review After completion of review on Test Cases, Test lead is mapping Test Cases with Requirement Traceability Matrix Document. (RTM) RTM defines the mapping between requirements and Test Cases. Traceability Matrix Template Project Name Prepared By Prepared on Sl. No.

Requirement Description

Use Case Reference

Project Manager Reviewed By Reviewed on Last Updated on Test Scenario

Test Case Reference

TEST CASE EXECUTION After completion of Test Cases preparation and corresponding reviews, Testers are receiving initial build from the development people. During Test Case execution Testers are receiving modified build from the developers. To receive any type of build from the developers, Testers required a valid negotiation / communications with developers like as below.

58

Manual Testing

Suresh.B –9440163282

[email protected]

Developers

COMMON REPOSITORY / SOFT BASE 1.0

2.0

3.0

Client

VSS (Visual Source Safe) The versions have been maintained by these VSS

FTP (File Transfer Protocol) Deploy / Install Build Sanity Testing

Testers

EXECUTION LEVELS: Initial Build Stable Build Level ‘1’ Comprehensive Testing

Level ‘0’ Sanity Testing

Defect Effected Build

Modified Build Level ‘2’ Re-Testing Regression Testing

Bug Fixing

Complete Build Master Build

Level ‘3’ Test Closer (Test Lead)

U.A.T Manual Testing  

Golden Build

Sign off

59

[email protected] 

Suresh.B –9440163282

TEST HARNESS: Test Harness means ready to start testing. Test Harness = Test Environment + List of Test Cases. LEVEL ‘0’ TESTING After receiving initial build from the development people, Testers are conducting Level ‘0’ Testing to estimate stability of that build before start real testing. In this testing, Testers are concentrates on Core (Basic) functionalities. During this Testing they will concentrates on below factors. 1) Under standable. 2) Operatable 3) Observable 4) Controllable. 5) Consistency. 6) Automatable. 7) Maintainable. 8) Simplicity. From the above factors Level ‘0’ Testing is also known as “Oct-Angle Testing” or Sanity Testing or Build Verification Testing or Tester Acceptance Testing or Testability Testing. LEVEL ‘1’ TESTING It is also known as “Comprehensive Testing”. During this testing Testers are executing all P0, P1, P2, Test Cases (P0–High Priority, P1–Medium Priority, P2–Low Priority) to validate functionality. In this every Test Case has to be executed by Tester either in Manual or in Automation. Build

Test Cases Test Engineer

Build Test Cases Automation Testing

Manual Testing Test Engineer Automation Testing

60

Manual Testing

Suresh.B –9440163282

[email protected]

Execution Process Skip

Pass

Take all the Test Cases

Fail

Test Case Execution

Blocked Test Cases

Close

Partial Pass or Fail

Defect Report During test execution, Testers are reporting mis-matches to development Teas as “Defect” in Defect Report Document. Defect Report Format 1) Defect ID Unique for future reference. 2)

Summary Brief description of the defect.

3)

Features The name of the feature / functionality in which defect.

4)

Test Case Name Name of the Test Case (in which Test Case execution the defect is raised)

5)

Reproducible The defect is repeatable in every time execution. a. If Yes: It is reproducible, attach test procedure. b. If No: It is not reproducible, attach test procedure along with snap shots.

6)

Status Status of the defect. They are (2) types (i) New–Reporting for first time. (ii) Re-open–For re-reporting defects.

Manual Testing  

61

Suresh.B –9440163282

7)

[email protected] 

Severity (Seriousness with respect to Testers) It means seriousness of the defect with respect to Tester or seriousness of the functionality. They are classified into (3) Types such as (i) (ii) (iii)

High severity – Urgent to solve Medium severity – Mandatory to solve Low severity – Compulsory to solve

8)

Priority Importance of the defect with respect to customer or importance of the functionality. It is classified into (3) types such as (i) High Priority (ii) Medium Priority (iii) Low Priority

9)

Assigned to Name of the Developer

10)

Detected By Name of the Tester (Who detected the defect)

11)

Reported on Date and Time

12)

Build Version ID In which version of the build the defect is raised.

13)

Suggested to fix Suggestions to developer to fix the defects By Developers Î Fixed By: Name of the Programmer who fixed the defect. Î Resolved on Date and Time Î Resolution Type: Acknowledgment from the developers for the reported defect. Î Approved by Signature of the Team Lead / Project Lead.

62

Manual Testing

[email protected]

Suresh.B –9440163282

Types of defects 1) User interface defects (Low Severity) Spelling mistakes (High Priority) Improper alignment (Low Priority) 2) Input domain defect (Medium Severity) Input type is not taking valid type ((High Priority) Input type is taking invalid type also (Low Priority) 3) Error handling defect (Medium Severity) No error message for wrong operation (High Priority) Complex message in error message (Low Priority) 4) Calculation defect (High Severity) Wrong outputs (High Priority) 5) Load conditional defect (High Severity) Build is not supporting more than one user (High Priority) Build is not supporting customer expected load (Low/Medium Priority) 6) Hardware defect (High Severity) Build is not supporting any hardware devices (High Priority) Build is supporting hardware and wrong output coming from hardware (Low Priority) 7) Role conditional defect (High Severity) System crash, Showstoppers, Dead lock etc., 8) Version control system (High Severity) Mistake in version control 9) Source defects (Medium Severity) Mistake in Help Document (High Priority) What is defect Age? The time gap between defect reported on and defect resolved on. What is Build Internal period? The time gap between two consequent builds is called as Build Internal period.

Manual Testing  

63

[email protected] 

Suresh.B –9440163282

BUG LIFE CYCLE / DEFECT LIFE CYCLE

New Review the defect Reopen

Open

Rejected

Hold

Duplicate

Deferred

Fixed

Defect If defect is not fixed Close Hold:

The defect is not accepted, not rejected due to developer need more information about that defect.

Duplicate: The defect is rejected due to defect is previously accepted defect. Deferred: The defect is postponed to next version / release. LEVEL ‘2’ TESTING After receiving the modified build from the developers, Testers are performing Re-testing / Regression Testing to ensure whether the reported defects are properly rectified by the developers or not and to check whether there is any side effects occurred or not on dependent functionalities by solving the reported defects or by adding new requirements. Case Study Modified Build

High Severity All P0, P1, P2 Test Cases

64

Medium Severity All P0, some P1, & Selected P2 Test Cases

Low Severity Some P0 & Selected P1, P2 Test Cases

Enhancement All P0, P1, P2 Test Cases

Manual Testing

Suresh.B –9440163282

[email protected]

Case 1: Case 2: Case 3: Case 4:

If the development team resolved bug severity is high, then Testers are re-executing all P0, P1, P2 Test Cases on that modified build. If the development team resolved bug severity is medium then, Testers are re-executing all P0, some P1 and selected P2 Tests cases on that modified Build. If the development team resolved bug severity is low, then Testers are re-executing some P0 and selected P1 and P2 Test cases on that modified build. If the development team released modified build due to some change request then the Testers are re-executing all P0, P1, P2 Test Cases on that modified build.

LEVEL ‘3’ TESTING After completion of all test cases execution and corresponding bugs resolving, Testers are sending complete build to the Test lead along with FSR (Final Summary Report) After receiving Final Summary Report from the Testers, Test lead is conducting “Test Closure” to estimate that whether the Test Engineer meets exit criteria or not. In this Test lead category people will concentrate on below coverages. 1) Requirements Coverage: All the requirements with respect to functionality. 2) Bug density No. of defects in Module . X 100 No of defects in the Project 3) Analysis of deferred bugs: Whether the deferred bugs are reasonable or not to postpone. After completion of above like coverages Test lead is conducting Test Closure in below approach. Take High Bug density Module Effort Estimation

Do Regression

Do Regression

Plan Regression

Do Regression Manual Testing  

65

Suresh.B –9440163282

[email protected] 

User Acceptance Testing After completion of “Test Closure” the Project Manager collects feedback from the customers on developed software through “User Acceptance Testing”. They are two types such as β – Test α – Test (Beta Test) (Alfa Test) Æ Software Application. Æ Software Product. Æ By Real customer. Æ By Model customer. Æ At development site. Æ At customer site. Signoff After completion of User Acceptance Testing and corresponding modifications, the Project Management deliver that software / build to the client along with Software Delivery Note (S/w DN). It consists of (2) issues such as (i) User Manual. (ii) Known issues

66

Manual Testing