TEST CASE DESIGN DOCUMENT

1 (6)

Instant Messaging - Mumbai

QA Team

20-10-2010

Change History
Version

Date

Handled by

Comments

0.1

08-11-2010

QA team

Initial draft version

Table of Contents
Feature .....................................................................................................................................................2
1.1 Testers Understanding of this feature:.............................................................................................2
1.2 Community specific:.........................................................................................................................2
1.3 Client Architecture: .........................................................................................................................2
1.4 Gateway specific:.............................................................................................................................2
1.5 Dependancies: ................................................................................................................................3
1.6 UI related areas: .............................................................................................................................4
1.7 Identifying Impact areas/List impacted areas:..................................................................................4
1.8 Alternate flow to test this feature:.....................................................................................................4
1.9 Testing Techniques:........................................................................................................................4
1.9.1 Boundry conditions ..................................................................................................................4
1.9.2 Equivalance partitioning............................................................................................................4
1.9.3 Error Guessing..........................................................................................................................5
1.10 Non Functional Requirements:......................................................................................................5
1.10.1 Security Test:..........................................................................................................................5
1.10.2 Performance Test:..................................................................................................................5
1.11 Negative Test Condition:................................................................................................................5
1.12 Interferance with Other Applications: ............................................................................................5
1.13 Reference links/documents:...........................................................................................................5
1.14 Tool dependency: .......................................................................................................................6
1.15 Developers Comments: ................................................................................................................6

TEST CASE DESIGN DOCUMENT

2 (6)

Instant Messaging - Mumbai

QA Team

20-10-2010

FEATURE
<Add Request>
1.1

Testers Understanding of this feature:

Tester will write the description of his/her understanding of the feature after reading/going through
requirnment documents/UI flows.
Ex:
<Add Request should be received on multiple screen of IM>
<Select Later on Add Request on every screen of IM>
< On select Later on Add Request it should get listed in conversation tab as pending request>
<Accept Add Request on every screen of IM>
<On Rejecting Add Request contact should not get add>
<On Accepting Add Request contact should get add>
<On contact get add successfully its presence status should be displayed>
1.2

Community specific:

If there is any limitation or feature addition which is specific to community, then it should be documented.
Ex:
Yahoo, Msn: On accepting Add Request presence authorizes screen should display
ICQ, OVI, GTalk: On acceptiing Add Request a confirmation pop up should display.
AIM: Add Request not supportive.
1.3

Client Architecture:

Provide an architectural diagram on how Add Request interacts with Client & Server.
Will help out to get a clear flow on the process.
1.4

Gateway specific:

If the feature requires validation of server logs then possible use cases/scenarios should be captured.
Ex:
Avtaar image is changed. Server logs must be validated- test cases must have coverage what
request/responses are sent/receive and what should be the expected result.

TEST CASE DESIGN DOCUMENT

3 (6)

Instant Messaging - Mumbai

QA Team

20-10-2010

On Add contact check List-Manage Request,List-Manage Response, Get Presence Request, Get
Presence Response..
1.5

Dependancies:

This is self explanatory.

- Enviornment
Try to Receive Add Request on non network coverage area.
- Phone
Network Operator:
Receive Add Request through various operators Vodafone, Airtel, Docomo, Uninor etc.
Receive Add Request through Wifi.
Receive Add Request on changing Network from GPRS to WIFI, WIFI to GPRS.

Profile:
Try to Receive Add Request on device set to Flight, Meeting, Silent & Normal.
In Flight mode & Offline mode set on WIFI and verify Add Request receive.

Battery:
Check Battery consumption on receive of Add Request.
Receive Add Request on device battery drains.

Memory Full:
Receive Add Request when Phone memory is full [IM client should be installed in PM]
Receive Add Request when Device memory is full.[ IM client should be installed in DM]

Mode:
Check add Request on Landscape & Portrait mode of the device on every screen if device
supports.

Touch Mode:
One Touch device:
On Receive of Add Request single tap on Accept should open New contact request screen.
On Receive of Add Request single tap on .Later, Add Request should be listed in Conversation
group as Pending add request
Multiple Touch devices:
On Receive of Add Request tap once to place focus on Accept button, again tap on Accept
should open New contact request screen.
On Receive of Add Request tap once to place focus on Later button, again tap on Later, Add
Request should be listed in Conversation group as Pending add request

Input mode: NA
Abc:
abc:

TEST CASE DESIGN DOCUMENT

4 (6)

Instant Messaging - Mumbai

QA Team

20-10-2010

123
Predection:
- System related
- Access Related
- Third Partys
1.6

UI related areas:

UI releated test cases should also be captured if not required then it should be marked as NA say server
side testing will not have any UI coverage.
Ex:
Button size and icon should be as per branding specific.
On presence authorizes screen community portal tab should be as per branding specific.

1.7

Identifying Impact areas/List impacted areas:

All the impact areas should be identified and test cases should have coverage around all the impacted
areas.
1.8

Alternate flow to test this feature:

Various possible scenarios by which the feature can be tested.

Ex:
On receive Add Request in contact list screen minimize client, on relaunch Add Request should be listed
in conversation tab as pending add request.
1.9

Testing Techniques:

1.9.1

Boundry conditions

Receive Add Req from lengthy Buddy name.

Receive Add Req from minium Buddy name
1.9.2

Equivalance partitioning

Send Add Req to buddy with zero character length.

Send Add Req to buddy with acceptable character length.
Send Add Req to buddy with character length more than acceptable level.

TEST CASE DESIGN DOCUMENT

5 (6)

Instant Messaging - Mumbai

QA Team

1.9.3

20-10-2010

Error Guessing

.Send Add Req to buddy with special characters.

1.10

Non Functional Requirements:

1.10.1

Security Test:

What are the contents of a Add Request should be shown, stored or communicated with/without
encryption.
1.10.2

Performance Test:

Load, Stress & Volume related test cases.

Receive 5 Add Request at a time.
Receive 5 Add Request at regural interval. [Send Add Req after 15 mins, 30 mins, 1 hr]

1.11

Negative Test Condition:

All negative testing scenarios should be captured.

Ex:

On receive of Add Request switch of the device.

Switch on the device login Add Reuest should be received again.

On receive of Add Request remove battery of device.

Switch on the device login Add Reuest should be received again.

1.12

Interferance with Other Applications:

List all the application on the device which may interrupt application while client is under test.
Ex:
-Interrupts
Receive file through Bluetooth on Add Request.
-Interactions
Receive Add Request on play of music.
Receive Add Resuest on play of video.
1.13

Reference links/documents:
Wiki.com

TEST CASE DESIGN DOCUMENT

6 (6)

Instant Messaging - Mumbai

QA Team

1.14

20-10-2010

Tool dependency:

Analysis what all test cases for relevant feature would be automated on client.
1.15

Developers Comments:

To encourage testers to talk with developer and get more insight about the code wriiten, this will help
tester in visualizing more and logical scenarios.