Basics of Sdlc,Stlc

8/9/2019 Basics of Sdlc,Stlc

1/42

Page 1

Software Testing:

Why did you choose this Course?* 1. Scope of getting job is very high.

2. No need to depend up on any technologies.3. Testing remains forever4. I want to be consistent through out my life

Why explicitly the s/w companies arerecruited the test engineers?

1. One person cannot efficiently perform two tasks at a time2. Sentimental attachment.

Who can do the course?Any graduate can do this course at this point of time

What exactly we require to get a job?1. Stuff

2. Communication skills

3. Confidence4. Dynamism

Project:Project is some thing that is developed based on the particular

customers requirements and used by that customer only ( E.g.:Marriage laddu)

Product:It is some thing that is developed based on the companies specification and

used by the multiple customers (e.g.: Thirupathi laddu)Quality:Classical definition for quality: - Quality is defined as justification of all therequirements of customer in a product.

NOTE: Quality is not defined in the product; it is defined in the customers mind

Defect: - Defect is defined as deviation from the requirements

Latest definition for quality: - quality is defined as not only the justification of

requirements but also the presence of value (User friendliness)1


2/42

Page 2

Testing:Testing is processes, in which the defects are identified, isolated, subjected

for rectification & ensure that the product is defect free. In order to produce the

quality product in the end and hence customer satisfaction.

Bidding the Project:Bidding the project is defined as request for proposal, estimation and signing

off (Official agreement).

Kick Off Meeting:It is an initial meeting conducted in the software company soon after the

project is signed off. In order to discuss the overview of the project and to select a

project manager for the project.

Usually high level management, Project managers, team managers, quality

managers, team leads and quality leads will be involved in this meeting.

PIN (Project Initiation Note):-It is a mail prepared by the project manager and sent to the CEO of the soft

ware company in order to get the permission to start the project developments.

Software Development Life Cycle (SDLC):-SDLC contains six phases they are

1. Initial phase or requirements phase.

2. Analysis phase

3. Design phase

4. Coding Phase

5. Testing Phase

6. Delivery & Maintenance Phase.

I. Initial Phase or Requirements Phase :

(a) Tasks: Interaction with the customer and gathering the requirements.

(b) Roles: Business Analyst (B.A), Engagement Manager (E.M)

Process: First of all the business analyst will take an appointment from thecustomer, collects the templates from the company, meets the customer on

appointed day, gathers the requirements with the help of template and comes back

to the company with the requirements documents.

Once the requirement document has come to the company the

engagement manager will check whether the customer gives any extra requirements

or confused requirements. In case of extra requirements he deals the excess cost of

2


3/42

Page 3

the project. In case of confused requirements he is the responsible for prototype

demonstration and gathering the clear requirements.

Proof: The proof document of this phase is Requirements Document. This iscalled with different names in different companies.

1. FRS (Functional Requirements Specification)

2. CRS (Customer Requirement Specification)

3. URS (User Requirement Specification)

4. BDD (Business Design Document)

5. BD (Business Document)

6. BRS (Business Requirement Specification)

Some companies may maintain the over all business flow information in one

document and the detailed functional requirement information in the otherdocument

Templates: It is a pre defined format, which contains the predefined fields, andused for preparing a document in an easy, comfort and perfect manner.

Prototype: -Defined as a roughly & Rapidly developed model which is used fordemonstrating to the client, In order to gather the clear requirements and to win the

confidence of a customer.

II. Analysis Phase:

(a) Tasks:

1. Feasibility Study

2. Tentative planning

3. Technology Selection

4. Requirement Analysis

(b) Roles: System Analyst, Project Manager, and Team Manager.

Process

1. Feasibility Study: - It is detailed study of the requirements in order tocheck weather the requirements are possible or not.

2. Tentative Planning: In this section the resource planning and the timeplanning (scheduling) is done temporarily.

3


4/42

Page 4

3. Technology Selection: - The list of all the technologies that are requiredto accomplish this project. Successfully will be analyzed and listed out in this

section.

4. Requirement Analysis: - The list of all the requirements that arerequired to accomplish this project. Successfully will be analyzed and listed

out here in this section.

SRS- System requirement specification

Proof: - The proof of this phase is System Requirement Specification.

III. Design Phase: -

Tasks:

1. High level designing

2. Low level designing

Roles: High-level designing is done by the chief Architect & Low leveldesigning is done by the Technical Lead

Process: The Chief architect will be drawing some diagrams using unifiedmodeling language in order to divide the whole project in to modules.

The Technical lead will also draw some diagrams in order to divide the

modules in to sub modules.

The technical lead will also develop the PSEUDO code in order to make

developers comfortable while developing the actual code.

Proof: The proof document of this phase is Technical design document.

IV. Coding phase:

(a) Task: Developing or Programming

(b) Roles: Developers or Programmers

Process: Developers will develop the actual code by using the technical designdocument as well as following the coding standards like Proper indentation, color

coding, proper commenting and etc..,

Proof: The proof document of this phase is source code Document.

E.g.: The programmer will develop some programs every one will develop his

program in different colors but the soft ware companies will ask the developers to

develop the program according to the company standards using proper color,

coding, commenting. So as to understand it easily.4


5/42

Page 5

V. Testing Phase:

(a) Task: Testing

(b) Roles: Test engineers

Process:

1. First of all the test engineers will collect the requirements

document and try to understand all the requirements

2. While understanding it at all they get any doubts they will

list out all of them in a review report.

3. They will send the review report to the author of therequirements document for clarifications.

4. Once the clarifications are given and after understanding

all the requirements clearly, they will take the test case

template and writes the test cases.

5. Once the first build is released then they will execute the

test cases

6. If at all any defects are found. They will list out all of them

in a defect profile template then

7. They will sent the defect profile document to the

development department and then will be waiting for the

next build to be released.

8. Once the next build is released then they re-execute the test

cases.

9. If at all any defects are found they will update the profile

document and sent it to the development department and

will be waiting fro the next build to be released .

10. This process continuous till the product is defect free.

Proof: The proof of the testing phase is Quality Product.

Test Case: (def) Test case is an idea of a test engineer based on the customersrequirements in order to test a particular feature or a function.

5


6/42

Page 6

VI. Delivery & Maintenance Phase:

Delivery:

(a) Task: - Installing the application in the clients environment

(b) Rolls: -Deployment engineer or Senior test engineers.

Process: - The senior test engineer or deployment engineer will be going to theclients place and install the application in their environment with the help of the

guidelines provide in the deployment document.

Maintenance:

After delivering the software while using if at all any problem occurs

then that problem becomes a task, based on that problem corresponding roles will

be appointed, the roles will defined the process and solve that problem.

Some clients may request for the continuous maintenance in such situations a

group of people from the software company will be continuously working on the

clients place and taking care of the soft ware.

************************^^^^^^^^^^^^^^^^^^^************************

Where exactly the testing comes in to picture?Which sort of testing you are expecting?How many sorts of testing are there?There are two sorts of testing.

1. UN-Conventional testing

2. Conventional testing

1.UN-Conventional Testing: -Unconventional testing is a sort of testing done bythe quality assurance people, in which they test each and every out come document

right from initial phase of the SDLC (Software development life cycle)

2.Conventional Testing: It is sort of testing done by the test engineers on theapplication in the testing phase of SDLC.

6


7/42

Page 7

Testing Methodology or Testing techniques:There are three methods of testing

(a) Black-Box Testing

(b) White-Box Testing

(a) Grey-Box Testing

(a) Black-Box Testing: If one performs testing only on the functional part of

an application with out having any structural knowledge then that method oftesting is known as Black-Box testing, usually the test engineers perform it.

(b) White-Box Testing: If one performs testing on the structural part of anapplication then that method of testing is known as white box testing, usually

the developers or white box testers perform it.

(c) Grey-Box Testing: If one performs testing on both the functional part aswell as the structural part of an application then that method of testing as

known as grey box testing using the test engineers who have structural

knowledge will perform gray- box testing.

Levels of Testing:There are five levels of testing

1. Unit Level Testing

2. Module Level Testing

3. Integration Level Testing

4. System Level Testing

5. User Acceptance Testing (U.A.T)

1.Unit Level Testing: -

It is a level of testing in which one will perform testing on the units. It is a

white box testing and usually developers or white box testers will perform.

7


8/42

Page 8

2.Module Level Testing: -

Module: Module is defined as a group of related functionalities to perform a majortask

It is a level of testing in which one will perform testing on the modules. It is a black

box testing and usually test engineers perform it.

3.Integration Level Testing: -

It is a level of testing in which the developers will develop some interfaces to

integrate the modules and test whether the interfaces are working fine or not. It is a

white box testing usually developers or white box tasters perform.

The developers may follow one of the following approaches while integrating

the modules.

1.Top-down approach

2.Bottom up approach

3.Hybrid or Sandwich approach

4.Big-bang approach

1.Top-down approach: - In this approach one will develop the parent modulesfirst and then integrate them with the related child modules

2.Bottom-up approach: - In this approach one will develop the child modulesfirst and integrate them to the parent modules

3.Hybrid approach Or Sandwich approach:- This is a mixed approach ofboth the top down and bottom up approaches

4.Big bang approach:-In this approach one will wait till all the modules areready and finally they will integrate all the modules at a time

STUB: - While integrating the modules in top down approach if at all anymandatory module is missing (not completed) then that module is replace with

a temporary program known as STUB

DRIVER: -While integrating the modules in bottom up approach. If at all anymandatory module is missing (not completed) then that module is replaced with atemporary program known as DRIVER

4.System Level Testing:

It is a level of testing in which one will install the complete application in to

the environment and then perform testing on it. At this level different types of

testing will be done one among those is system integration testing.

8


9/42

Page 9

5.System integration Testing: -

It is a type of testing in which once the complete application is developed one

will perform an action at one module and checks for the reflections at the

corresponding modules. It is a black box testing and usually test engineers

perform.

6.User- Acceptance Testing: -

It is the level of testing in which one will perform the same system testing in

the presence of the user in order to make him accept the application. It is a black

box testing and usually Test engineer performs it.

Environment: - Environment is a combination of three layers (e.g.: Yahoo)

a. Presentation layer

b. Business layer

c. Data base Layer

System: The application installed in to an environment combinable called as system.

a. Presentation Logic: The logic that is used for viewing application isknown as presentation logic

b. Business Logic: - The logic that is used for performing the operations onthe application is known as business logic.

c. Data Base Logic: - The logic that is used for sharing and retrieving thedata is known as database logic.

Types of Environment: - There are Four types of environments

a. Stand alone environment or One-tier environment

b. Client server environment or Two-tier Architecture

c. Web environment or Three-tier Architecture

d. Distributed environment or N-tier Architecture

9


10/42

Page 10

a. Stand Alone environment: -

In this type of environment all the three layers that is presentation

layer, Business layer& Database layer will be present in a single tier.

This type of environment is suitable for single user application.

One-Tier Architecture

PL

BL One tier ArchitectureDBL

b. Client server environment:

In this type of environments there will be two tiers, one tier is for

clients and other tier is for database servers. The presentation layer

and the business layer will be present in each and every client . The

database layer will be present in the database server. This type of

environment is suitable for multi user application in a single or a

limited area.

Two tier Architecture

PL+BL DBL

PL+BL

PL+BL

Clients Server

c. Web environment: - In his type of environment three tiers will be there. One is

for clients the middle one is for application server and the other one is for

database servers. Presentation layer will be present at clients, Business layer

will be present in the application server, and database layer will be present at

the database servers. This type of environment is suitable for the applications

that are used all over the world by limited number users

Three-tier Architecture:

1


11/42

Page 11

PLDBL

BLPL

DBL

PL

Web server: -It is software, which provides web services to the clients.

E.g.: - Internet Information service (IIS).

Example for Application servers: Tomcat, Web logic, websphere etc..,

d. Distributed environment: -It is similar to the web environment but the number of application

servers are increased and represented in individual tiers in order to

distribute the business logic so that the logic will be distributed.

N-tier Architecture:

PL DBL

BL BL BL

PL

PL

PL

1

A l Server Database server

Apl server1 Apl server2 Apl server2 Database serv


12/42

Page 12

******************^^^^^^^^^^^^^^^^^^^^^^^********************************

Software Development Models: -

1.Water Falling Model

Advantages:It is a simple model

Project monitoring & maintenance is very easy

Drawbacks:Con not accept the new requirements in the middle of the project

1

INITIAL

ANALYSE

DESIGN

CODING

TESTING

DEL&MAINT

Sys.design

S/w design

Implementation

Black box testing

Delivery toclient

Req.gathering BRS

SRS

TDD, GUI

Unit test

Int. test

Mod Test

Sys.Test.

UAT

UTR

UTR

UTR

UTR

UTR


13/42

Page 13

(b) Prototype Model: -

Advantages: -Whenever the customer is not clear with the requirements this is the best

suitable model for gathering the clear requirements.

Drawbacks: - It is not a complete model Prototype has to be built on companies cost User may limit his requirements by sticking to the prototype.

(B) Evolutionary Model: -

Advantages: -Whenever the customer is evolving the requirements this is the best

Suitable model.

Drawbacks: - Cannot define the dead lines

Project monitoring & maintenance is very difficult

No Transparency (No clear)

1

Unclear Req

Prototype

SRS Doc

Base lined

Client environment

confirmation

H/W rotot e

S/WProtote e

BRS DOC Base

Lined

H/W rotot e

H/W rotot e

REQ.areRefined

Initial Req

Dev.

Application User

validation

User

accept

Appl is Base line

Feed back with

new Req.

N

Y


14/42

Page 14

Spiral Model: -

Advantages: -This is the best suitable for developing the highly risk based project

(scientific projects)

Drawbacks: - Risk analysis and estimation is not an easy task

It is a costly model

It is a time consuming model

(C) Fish Model: -

Advantages: -This is the best suitable for developing the highly risk based

project(scientific

projects)

Drawbacks: -o Time consuming Model

o Costly model

1

Risk Root cause

analysis

EstimationContingencies

Defining the objectives/WA/Constraints

Refining &

Planning for the

next cycle

Implementation

SRS HLD

LLD SCD

eq. Gathering

RSeview

SRS Review TDD Review White boxtesting

Black Box

testing

Anal sis Desi n Codin

Delivery &

Maintenance

Test S/W

Changes

Sys testing


15/42

Page 15

Verification: -It is a process of checking conducted on each and every role of the

organization in order to check whether they are working according to the guidelines

or not right from the starting of the process till the ending of the process

Validation: -It is a process of checking conducted on the developed product in

order to check whether it is working according to the requirements or not.

(D) V-Model: -

BRS Preparing proj plan

SRS Preparing Test plan

Req.Phase testing

Design Phase testing

TDD Program phase testing

Test SCD

S/W Build System testingTest management Process

Testing User acceptance testing

Port Testing

S/W efficiency

DRE=A/A+BDRE=A/A+BDelivery & Maintenance Test S/W changer

Advantages; -AS verification and validation as well as test management process is done the

out come will be a quality product.

Drawbacks: -o Time consuming mode

1

Design &

coding

Verification

Validation

Initial& design

Phase


16/42

Page 16

o Costly model

DRE: Defects removal efficiency

End of the Basic part

Testing part to be continued.

1.Build Acceptance Testing Or Build Verification Testing Or

Sanity Testing: -

It is a types of testing in which one will conduct over all testing on the

released build in order to check whether it is proper for further detailed testing or

not. Even some companies call it as smoke testing, but some companies says that

just before releasing the build the developers will conduct the overall testing on the

build that is known as smoke testing and once the build is released what ever thetest engineers do in order to accept the build is known as B.A.T or B.V.T or Sanity

Testing.

2.Regression Testing: -

It is a type of testing in which one will perform testing on the already tested

functionalities again and again.

It is usually done in two scenarios.

1. Whenever the testers has raised the defects, rectified by the developers and next

build is released to the testing department then the test engineers will test the

defect functionality as well as the related functionality once again.

2. When ever some new features are incorporated by the developers, next build is

released to the testing department then the test engineers will once again test the

related functionalities of the new features in order to confirm that they are

working same as previous.

Note: - Testing the new functionalities for the first time is known as new testingbut not Regression Testing.

1


17/42

Page 17

3.Re-Testing: -

It is a type of testing in which one will test the same functionality again and

again with different sets of values in order to come to a conclusion whether it is

working or not.

4. - Testing (Alpha Testing): -It is a type of user acceptance testing in which the test engineers will test the

application in our company, in the presence of the customer.

Advantage: - If at all any defects are found then there is a chance of rectifyingthem immediately.

5. -Testing (Beta): -It is a type of user acceptance testing done in the clients

place either by the end-users or by the third party testing experts before actual

implementation.

Drawback: If at all any defects are found then there is no chance of rectifying them

immediately.

6. Static Testing: -

It is a type of testing in which one will perform testing on the application or

application related factors with out performing any action.

Eg:- Documentary testing, GUI testing, Code reviews and etc.,

7. Dynamic Testing: -

It is a type of testing in which one will perform in the application or its

related factors by doing some actions

Eg: - Functionality testing.

8.Installation Testing: -

It is a type of testing in which one will install the application in to the

environment by following the guide lines provided in the installation document and

if the installation is successful then he will come a conclusion that the given guide

lines are correct other wise he will come to a conclusion that the given guidelines are

not correct.

1


18/42

Page 18

9.Compatibility Testing: -

It is a type of testing in which one may have to deploy the application in to

the multiple number of environments prepared with different combinations of

environmental components in order to check whether the application is compatible

with all that environments. This type of testing is usually done to products.

10. Monkey Testing: -

It is a type of testing in which one will perform abnormal action on the

application intentionally in order to check the stability of the application.

11.Usability Testing: -

It is a type of testing in which one will check whether the application is user

friendly or not and it can be comfortably used by the end user or not.

12. Exploratory Testing: -

It is a type of testing in which one will (Domain Experts) perform testing on

the application with out having the knowledge of requirements but by exploring the

functionality.

13.End-To- End Testing: -

It is a type of testing in which one will perform testing on all the end- to-end

scenarios of the application.

14.Port Testing:-

It is a type of testing in which one will deploy the application in to the clients

environment and check whether it is compatible with that environment or not.

15.Reliability Testing: -It is a type of testing in which one will perform testing on the application

continuously for long period of time in order to check the stability of the application

16.Security Testing: -It is a type of testing in which one will concentrate on the following areas of

the application

a). Authentication Testingb). Direct URL Testing (Uniform Resource Location)c). Fire Wall Leakage Testing.

1


19/42

Page 19

(a) Authentication Testing: -It is a type of testing in which one will enter different combinations of user

names and passwords and try to access the home page in order to check whether

only the authorized persons are accessing the application or not.

(b) Direct URL Testing: -It is a type of testing in which one will enter the URL of an unauthorized

page directly in the browser and try to access that page in order to check whether it

is been accessed or not.

(c) Firewall Leakage Testing : -It is a type of testing in which one will enter as one level of user and try to

access the other level of unauthorized pages in order to check whether the firewalls

are working properly or not.

17. Mutation Testing: -

It is a type of testing in which one will perform testing on something by doing

some changes to it.

18. ADHOC Testing: -

It is a type of testing in which one will perform testing on the application inhis own style after understanding the requirements clearly.

The SoftWare Testing Life Cycle Contains SixPhases

They are

Test Planning

Test Development

1


20/42

Page 20

Test Execution

Result Analysis

Bug Tracking

Reporting

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, efficient and optimized way.

Optimization: -Optimization is a process of utilizing the available input resources to their

max and getting maximum possible output.

1.0 Introduction1.1 Objective1.2 Reference Document

2.0 Coverage Of Testing2.1 Features To BeTesting

2.2 Features Not ToBe Testing

3.0 Test Strategy3.1 Levels Of Testing3.2 T ypes of testing

2


21/42

Page 21

3.3 Test design techniques3.4 Configurationmanagement3.5 Test metrics3.6 Terminology

3.7 Automation Plan3.8 List of automated tools

4.0 Base criteria4.1 Acceptance criteria

4.2 Suspension criteria

5.0 Test Deliverable

6.0 Test Environment

7.0 Resource Planning

8.0 Scheduling

9.0 Staffing& Training

10.0 Risks & Contingencies

11.0 Assumptions

12.0 Approval Information

1.0 Introduction: -

1.1 Objective: -The Purpose of the document is clearly described here in this section

1.2 Reference Document: -The list of all the documents that are refereed to prepare the test plan will be

listed out her in the section.

2.0 Coverage Of Testing: -2.1 Features to be tested: -

The list of all the features that are to be tested in this phase will be clearly

mentioned here in this section.

2


22/42

Page 22

2.2 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 section

a. Out of scope features

b. Low risk features

c. The functionalities that are planned to be incorporated in future

d. The features that are to be skipped based on the time constraints.

3.0 Test Strategy: -Test strategy is defined as an organizational level term, which is used for

testing all the projects in the organization.

Test Plan: -It is defined as a project level term, which is used for testing a particular

project in the organization.

Note: - Test strategy is common for all the projects but the test plan isspecific for a particular project

3.1 Levels of Testing: -The list of all the levels of testing that are followed by that company are listed

out here in this section

3.2 Types of Testing: -The list of all the types of testing that are followed in that company will be

listed out here in this section.

3.3 Test Design Techniques: -Technique: -

Technique is some thing i.e., used for accomplishing a complex task in an

easy manner.

A list of all the techniques that are used by that company while developing

the test cases will be listed out here in this section.

Eg: - BVA (Boundary value analysis)ECP (Equivalence Class Partition)

3.4 Configuration Management:- To be discussed later

3.5 Test Metrics: -The list of all the metrics that are maintained in that company will be listed

out here in this section

3.6 Terminology: -

2


23/42

Page 23

The list of all the terms and the meaning that are used in that company will

be listed out here in this section

3.7 Automation Plan: -The list of all the areas that are plan for automation in that company will be


3.8 List Of Automated Tools: -The list of all the automated tools that are used in that company will be listed

out here in this section.

4.0 Base Criteria: -

4.1 Acceptance Criteria: -When to stop testing feeling that enough testing has been done on the

application is clearly described here in this section.

4.1 Suspension Criteria: -When to suspend testing suddenly (abruptly) will be clearly mentioned here

in this section.

5.0 Test Deliverable: -

The list of all the documents that are to be prepared during the testing phase

will be listed out here in this section.

Eg: Test case, defects profile document.

6.0 Test Environment: -

The customer specified environment would be clearly described here in this

section. The same environment will be simulated in the company and will be used

for testing purpose.

7.0 Resource Planning: -

Who has to do what is clearly described here in this section.

8.0 Scheduling: -

The starting dates and the ending data of the each and every tasks is clearly

planned here in this section.

9.0 Staffing& Training: -

How much staff is to be recruited and what kind of training is to be provided

is clearly described here in this section.

2


24/42

Page 24

10.0 Risks & contingencies (Solution Plans): -

The list of all the potential risks and the corresponding solution plans will be


Example:

Risks:i. Unable to deliver the software with in dead lines.

ii. Employees may leave the organization in the middle of the

project

iii. Customer may impose the dead lines.

iv. Unable to test all the features with in the time.

v. Lack of expertisation

Contingencies (solution Plans):

i. Proper plan ensurance.ii. Employees need to be maintained on the bench.

iii. What not to be tested has to be planned in case of imposed

dead lines.

iv. Severity & Priority based testing.

v. Proper Training needs to be provided.

11.0 Assumptions: -

The list of all the assumptions that are to be assumed by the test engineer will

be listed out here in this section.

12.0 Approval Information: -

Who has to approve what is clearly described here in this section.

USE CASES

2

Screen Shots

LLI (Low-level

Information)

HLI (High level

Information)

FRS (Functional Requirement Specification)


25/42

Page 25

Use Cases:Use case is a description of functionality of certain features of an application

in terms of actors, actions& responses

Input information required for preparing the use case Document: -

i. Screen shot

ii. Functional requirements

iii. Special requirement/Business rules/Validation

iv. Template

i). Screen Shot: -

User name

Password

Connect to

ii). Functional Requirements: -a. Login screen should contain user name, password, Connects To fields

and Login, Clear, Cancel buttons.

b. Connect to is not a mandatory field but when ever user requires it

should allow him to select a data base option.

c. Up on entering valid user name, valid password and clicking on login

button corresponding page must be displayed.

d. Up on clicking on the clear button the information present in all the

fields must be cleared and the cursor must be available in the user

name field

e.Up on clicking on the cancel button login screen must be closed.

iii). Special requirement/Business ruled/Validation: -

. Initially whenever the login screen is Invoked Login, clear buttons mustbe disabled. . Cancels Button must be always enable. . Up on entering user name and password the login button must beenabled. . Up on entering some information in to any of the fields the clear buttonmust be enabled

2

Lo in Clear Cancel


26/42

Page 26

. The Tabbing order must be user name, Password, Connect to, Login,clear, cancel.

iv). Use Case Template:Name Of The Use Case :

Brief Description of Use Case :

Actors Involved :

Special Requirements :Pre Condition :

Post-Conditions :

Flow of Events :

v). Use Case Document:

Name of the use case: Login use case.

Brief Description of use case: It Describes the functionalities of all thefeatures present in the login screen.

Actors Involved: Normal user, Admin User.

Special Requirements: There are two types of special requirements

1.Explicit requirements2.Implicit requirements

1.Explicit Requirements: -The Requirements that are directly given by the customer are known

as explicit requirement.

2.Implicit Requirement: -The requirements that are analyzed by the business analyst feeling

that they will add the value (user friendliness) to the application are known

as implicit requirements.

List of Explicit requirements: -

2


27/42

Page 27

Initially whenever the login screen is Invoked Login, clear buttons

must be disabled.

Cancels Button must be always enable.

Up on entering user name and password the login button must be

enabled.

Up on entering some information in to any of the fields the clear

button must be enabled

The Tabbing order must be user name, Password, Connect to, Login,clear, cancel.

List of Implicit Requirements: -

Initially whenever the login screen is invoked the cursor must be available in

the user name field

Upon entering invalid username, valid password and clicking on log in

button an error message should be displayed Invalid username Please try

again

Upon entering valid username, In valid password and clicking on login

button an error message should be displayed Invalid Password Please Tryagain

Upon entering Invalid username, Invalid password and clicking on login

button an error message should be displayed Invalid user name and

password Please try again

Pre-Conditions: Login screen must be available

Post-Conditions: Either home page or admin page for the valid user and errormessage for the invalid users

Flow of Events: There are three flows for the application1). Main Flow2).Alternative Flow

3). Exceptional Flow

1.Main Flow:

Action Response

2


28/42

Page 28

1.Actor invokes the application.

2.Actor enters valid user name, Valid

password and clicks on login button.

3.Actor enters valid user name, validpassword, selects a database option and

clicks on login button.

4.Actor enters invalid user name Valid


5.Actor enters valid user name, Invalid


6.Actor enters both user name and

password invalid and clicks on loginbutton.

7.Actor enters some information in to any

of the fields and clicks on clear button.

8.Actor clicks on the cancel button.

1.Login Screen is displayed with the following fields

Username, Password, Connect to, Login, Clear&

cancel.

2.Either home page or admin page is displayed

depending up on the actor entered by authenticating.

3.Authenticates,Either home page or admin page isdisplayed depending up on the action entered with

mentioned data base connection.

4.Go to Alternative flow table 1



7.Go to Alternative glow table 4

8.Go to Alternative flow table 5.

1.Alternative flow table 1: -(Invalid User name)

Action ResponseActor enters invalid user name, valid

password and clicks on login button

Authenticates an error message is

displayed Invalid User name Please Try

again.

2.Alternative Flow Table 2: -(Invalid Password)

Action ResponseActor enters valid user name, invalid



displayed Invalid User Password Please

Try again.

3.Alternative Flow Table 3: - (Invalid User name & Password)

2


29/42

Page 29

Action ResponseActor enters invalid user name, invalid



displayed Invalid User name and

password Please Try again.

4.Alternative Flow Table 4: - (Clear Click)Action ResponseActor enters some information in any of

the fields and clicks on clear button

All the fields are cleared and cursor is

placed in the user name fields

5.Alternative Flow Table 4: -(Cancel click).

Action ResponseActor Clicks on the cancel button. Login screen is close

Identify the module to which the use case belongs.

Security module.

Identify the functionality of the use case with respect to the total

functionality

Authentication

Identify the functional points and prepare the functional point document.

Identify the input required to perform testing

Valid & invalid Inputs

Identify the actors involved in the use case

Normal user & Admin user.

Identify whether the use case is linked with any other use case.

Home page and Admin page use cases

Identify the pre conditions

Login Screen mist be available

Identify the post conditions

2


30/42

Page 30

Either home page or admin page for valid users and error message for

invalid users

Understand the main flow of the application

Understand the alternative flow of the application

Understand the special requirements

Document the test cases for the main flow

Document the test cases for the alternative flow

Document the test cases for the special requirements

Prepare the cross-reference matrix.

Functional Point: -The point where an user can perform some action is known as

functional point.

Testing Process: -FRS FPD MTCD DTCD DPD

FRS- Functional Requirement SpecificationFPD-Functional Port Document

MTCD-Master Test Case Document

DTCD-Detailed Test Case DocumentDPD-Defect Profile Document

Cross Reference Document: -(Traceably Document)

It is a document, which contains a table of linking information used for

tracing back for the reference in any kind of ambiguous (confusion) or questionable

situation.

Common Tracebility Matrix

3

VLD

FPD MTCD DTCD DPD

2

8

7

22

3

5

28 1

5

47

UN-EntryPW-Entry

Login Click

Cancel ClickClear Click

Validate Logincheck

Validate Cancel

CheckValidate Clear

Check

12

3

45

6

7

VLD


31/42

Page 31

Requirement Tracebility Matrix

TCID REQ ID

1

2

3

4

5

6

7

8

1

1

1

2

2

2

2

2

Defects Tracebility Document

DID TCID

1

2

3

4

5

6

28

32

65

96

48

52

Types Of Test Cases:There are Two types of test cases if we see broadly they are:

1. GUI Test Cases2. Functional Test Cases

The Functional cases are further divided in to Two types

(a) Positive Test Cases,(b) Negative Test Cases.

Guide Lines fo developing the GUI Test Cases:

Check for the availability of all the objects

Check for the alignments of all the objects up on customer requirements

Check for the consistency of all the objects

Check for the spellings and grammar

Apart from the above guide lines any thing else that can be tested just by

looking without doing any actions will fall under GUI test cases

Guide Lines for Positive Test Cases:

3


32/42

Page 32

A test engineer should have positive mind set up

He should consider the positive flow of the application

He should use only the valid Input

Guidelines for developing Negative Test Cases:

A test engineer should have negative mind set up

He should consider the negative flow of the application

He should use at least one invalid input per a set of data

Test Case Template: -

(a) Test Objective

(b) Test scenario

(c) Test procedure(d) Test Data

(e) Test Cases

(a) Test Objective: -The main purpose of the document is described here in this section

(b) Test Scenarios: -The list of all the scenarios that are to be tested will be listed out here

in this section.

(c)Test Procedure: -DEF: It is a functional level term, which describes how to perform

testing on the functionalities of the application.

The plan for testing the functionalities is briefly described here in this

section

(d) Test Data: -The date that is required for testing is made available here in this

section

(e) Test Cases: -

The format of a test case template is given below

TCID TC

TYPE

DESCRIPTION EV AV Result Severity Priorit

y

Reference

3


33/42

Page 33

Test case Table

TCID TYPE Description Expected Value Actual Value Result Severity Priority Refere

1 GUI

Check for the availabilityof all the objects as per

the Login Obj Tab

All the objects must beavailable as per the

login obj tab

All the objectsare available as

per theloginobj tab Pass

2 GUICheck for the constancyof all the objects

All the objects must beconsistent with eachother

All the objectsare consistentwith each other Pass

3 GUI

Check for the spellings ofall the objects as per the

Login obj TabLogin ObjTab.xls

All the objects must bespelled properly as per

the login obj tab

All the objectsare spelledproperly Pass

4 GUI

Check for the enable

property of login, clearand cancel buttons

Initially login, clearmust be disabled and

cancel button must beenabled

Login, clear and

cancel buttonsare enabled Fail

5 GUICheck for the initialposition of the cursor

Initially the cursor mustbe positioned in theuser name field

Initially thecursor is presentin the usernamefield Pass

6 Positive

Enter some information into user name andpassword field and checkfor the enabled property oflogin button

Login button must beenabled

Login button isenabled Pass

7 Positive

Enter some info in to any

of the fields and check forthe enabled property ofclear button

Clear button must beenabled Clear button isenabled Pass

8 Positive

Enter user name,

Password as per the VITand click on login button

Corresponding pagemust be displayed as

per the VIT

Correspondingpages aredisplayed as pervalid in putstable Pass

9 Positive

Enter username,

Password as per the VITand select a data base

option and click on login

Corresponding pagemust be displayed as

per the VIT With thementioned data baseconnection

Correspondingpages aredisplayed as perthe VIT with thementioned data

base connection Pass

10 Positive

Enter some information into any of the fields andclear button

All the fields must becleared and the Cursorshould be placed in theuser name fields

All the fields arecleared but thecursor is notplaced in theuser name field. Fail

11 Positive Click on the cancel button

Login screen should beclosed Login screens

closed Pass

3
http://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Login%20Obj%20Tab.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Valid%20Inputs%20Table.xls


34/42

Page 34

12 PositiveCheck for the tabbingorder of all the objects

Tabbing order must beas follows User name,Password, Connect to,Login, Clear, Cancel

Tabbing order isas followsUsername,Password,Connect toLogin, clear,Cancel Pass

13 Negative

Enter username,Password as per the IVITand click on login button

Corresponding

messages should bedisplayed as perIVIT

Corresponding

error messagesare not displayed

as perIVIT Fail

14 Negative

Enter some informationonly in to the user namefield and check for theenabled property of loginbutton

Login button must bedisabled

Login button isenabled Fail

15 Negative

Enter some informationonly in to the passwordfield and check for theenabled property of loginbutton

Login button must bedisabled

Login button isenabled Fail

LOGIN OBJ TAB

Sno Obj Name Type

1 User name Text Box

2 Password Text Box

3 Connect To Combo box

4 Login Button

5 Clear Button

6 Cancel Button

Valid Inputs Table

Sno User Name Password Expected Page Actual value Result

1 Suresh qtp Admin Admin Pass

2 Raja rani Home page Home page Pass

3 Chiru mbbs Home page Home page Pass

4 Praveen puppy Home page Home page Pass

5 NTR illu Home page Home page Pass

6 Admin Admin Admin Admin Pass

3
http://opt/scribd/conversion/tmp/scratch30051/Invalid%20Input%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Invalid%20Input%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Invalid%20Input%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Invalid%20Input%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Invalid%20Input%20Table.xlshttp://opt/scribd/conversion/tmp/scratch30051/Invalid%20Input%20Table.xls


35/42

Page 35

A test Engineer will do the following during the test execution

1. He will perform the action that is described in the description column

2. He will observe the actual behavior under the actual value column.

3. He will document the observed value under the actual value column.

In this phase the test engineer will compare the expected values with the actual

values and if both are matched they will document the result as pass other wise they

will document the result as fail.

Bug Tracking is a process in which the defects are identified, Isolated and managed

Defect ID: -

3

Valid Inputs Table (IVIT)

Sno User Name Password Expected Page Actual value Result

1 Suresh1 qtp Invalid User name Plz try again Admin Fail

2 Raja2 rani Invalid User name Plz try againInvalid User name Plz try

again Pass

3 Chiru DADAInvalid password Plz try

againInvalid password Plz

try again Pass

4 Praveen TOPIInvalid password Plz try

againInvalid password Plz

try again Pass

5 NTR1 illu4Invalid user name &

password Plz try againInvalid user name &

password Plz try again Pass

6 Admin5 Admin6Invalid user name &

password Plz try againInvalid user name &

password Plz try again Pass


36/42

Page 36

The lists of defect numbers are mentioned here in this section.

Defect Description: -What exactly the defect is clearly described here in this section.

Steps for reproducibility: -The list of all the steps that are followed by the test engineer to identify the defectwill be listed out here in this section.

Submitter: -The name of the test engineer who has submitted the defect will be mentioned here

in this section.

Date Submission: -The date on which the defect is submitted is mentioned here in this section.

Version No: -Corresponding Version number is mentioned here in this section.

Build No: -Corresponding build number is mentioned here in this section.

Assigned To: -The development lead will fill the developers name for whom the defect is assigned.

3


37/42

Page 37

Priority Status

3

efect Id

DefectDescription

Steps forReproducibility Submitter

Date OfSubmission

VersionNO

BuildNo

Assignto Severity

Initially Login, clearbuttons are

enabled instead ofbeing disabled

Not Applicable

Sri Balaji 11-Feb-08 1.0.0 1

Upon Clicking onclear button all thefields are cleared

but the cursor is notplaced in the user

name field

1.Enter someinformation in to anyof the fields2.Click on clearbutton3.Observe that thecursor is not placedin the usernamefields after clearingall the fields


Upon enteringSuresh1 as

username and qtpas password andclicking on login

button admin pageis displayed instead

of error message

1.Enter Suresh1 into the user namefield 2.Enterqtp in to thepassword field3.Click on loginbutton4.Observe adminpage is displayedinstead of errormessage.


Up on entering theinformation only into the user name

field login button isenabled instead of

being disabled

1.Enter someinformation in tousername field2.Check for the

enabled property oflogin button.

3.Observe that loginbutton is enabledinstead of being

disabled.Sri Balaji 14-Feb-08 1.0.0 1

Upon entering theinformation only into the password

field login button isenabled insteadbeing disabled

1.Enter someinformation in tho

password field2.Check for theenabled property of

login button3.Observe that login

button to enableinstead of being

disabledSri Balaji 11-Feb-08 1.0.0 1


38/42

Page 38

Defect- Id: -The list of defect numbers are mentioned here in this section

Defect Description: -What exactly the defect is clearly described here in this section

Steps for reproducibility: -The list of all the steps that are followed by the test engineer to identify

the defect will be listed out here in this section

Submitter: -The name of the test engineer who has submitted the defect will be

mentioned here in this section.

Date Of Submission: -The date on which the defect is submitted is mentioned here in this

section.

Version No: -Corresponding Version number is mentioned here in this section.

Build No: -Corresponding build number is mentioned here in this section.

Assigned To: -The development lead will fill the developers name for whomthe defect

is assigned.

Severity: -How serious the defect is defined in terms of severity, Severity is

classified in to four types:

1.Fatal (Sev1) or S1 or 1

2.Major (Sev2) or S2 or 2

3.Minor (Sev3) or S3 or 3

4.Suggestion (Sev4) or S4 or 4

1.Fatal:If at all the problems are related to the navigational blocks or unavailability

of functionality then such type of defects are treated to be fatal defect.

3

Main Menu

Val1

Val2

Result

Next

UNAVAILABL

E

Next

ADD

Next


39/42

Page 39

2.Major: -If at all the problems are related to the working of major functionalities

then such types of defects are treated to be major defects.

3.Minor: -If at all the problems are related to the Look & Feel of the application

then such type of defects are treated to be minor defects

4.Suggestions: -If at all the problems are related to the value of the application then such

type defects are treated to be suggestions.

+Ve integer Box

3

Val1

Val2

Result

20

-10

ADD

Val1

Val2

Result

BAD

Somealphabets

Invalid

Entry

Plz Try

again


40/42

Page 40

Priority: -Priority defines the sequence in which the defects has to be rectified. It is

classified in to four types

1.Critical (Pri1) or P1 or 1

2.High (Pri2) or P2 or 2

3.Medium (Pri3) or P3 or 3

4.Low (Pri4) or P4 or 4Usually the Fatal defects are given critical priority, Major defects are given

High priority, Minor defects are given Medium Priority and suggestions are given

Low Priority, But depending up on the situations the priority will be changing.

I - Case:Low severity-High Priority Case: -

Up on customer visit to the company all the look and feel defects are

given highest priority.

II - Case:High severity Low Priority Case: -

When ever 80% of the application is released to testing department as

20% is missing the test engineers will treat them as Fatal defect but the development

lead will give least priority for those defects as features are under development.

4


41/42

Page 41

Bug Life Cycle: -

No

Build #1

Build #2

Yes

No

Yes

No

4

REQ

DEV

M1

TESTING

Is

defect

is

really

verifie

d

Is it

Really

Defe

ct

If

Defect

Rectif

ation

Fixed for

verification

OP

EN

STOP TESTING

HOL

D

Testers

error

As per

design

Clos

ed

Ne

w

RE

ope

n


42/42

Page 42

Status: -

New: - When ever the defect is found for the first time the test engineer will set the

status as New.

Open: -When ever the developer accepts the raised defect then he will set the status

as open.

Fixed for verification Or Fixed for rectified: - When ever the developer rectifies theraised defect then he will change the status to fixed.

Re open and Closed: -When ever the defects are rectified, next build is released to

the testing dept then the test engineers will check whether the defects are rectified

properly or not. If the defect is rectified properly then the test engineer will set the

status as Closed. If the defect is not rectified properly then the test engineer will

set the status as Re open.

Hold: - When ever the developer is confused to accept or reject the defect then he

will set the status of the defect as hold.

Testers Error or Testers Mistake Or Rejected: - When ever the developer is

confirmed it is not at all a defect then he will set the status of the defect as

Rejected.

As Per Design: - When ever the test engineer is not aware of new requirements and

if he raises defects related to the new features then the developer will set the status

As Per Design.

Note: This is a rare case not usually Occurs

Documents

Basics of Sdlc,Stlc