Generictestcasesguidelines 101201033527-phpapp01

1
Generic Test Cases Guidelines
 Krishna Kishore K

2
FORM OBJECTS - TEXT BOX
 VALIDATE IF LEADING SPACES ARE ENTERED IN A ALPHANUMERIC FIELD, THE SAME IS
TRIMMED BEFORE SAVING THE RECORD.
 VALIDATE IF TRAILING SPACES ARE ENTERED IN A ALPHANUMERIC FIELD, THE SAME IS
TRIMMED BEFORE SAVING THE RECORD.
 VALIDATE IF ONLY SPACES ARE ENTERED THE SAME IS NOT ALLOWED TO BE SAVED
 VALIDATE IF ANY PRIMARY KEY FIELD THAT IS GOING TO BE DISPLAYED IS NOT CASE
SENSITIVE
 VALIDATE IF FIELD LENGTH IS 20 AND DATA ENTERED IS 12 SPACES + 12 CHARACTERS.
THE RECORD IS NOT SAVED.
 ENTER VALID DATA WITHIN THE SPECIFIED RANGE
 ENTER THE LEAST NUMBER OF CHARACTERS AS DEFINED BY THE WIDTH
 ENTER THE MAXIMUM NUMBER OF CHARACTERS AS DEFINED BY THE WIDTH
 ENTER NUMBER OF CHARACTERS WHICH EXCEEDS THE WIDTH
 ENTER DATA SURROUNDED BY SINGLE QUOTES
 ENTER DATA SURROUNDED BY DOUBLE QUOTES
 VALIDATE IF MORE SPACES ARE ENTERED BETWEEN TWO STRINGS IN A ALPHANUMERIC
FIELD, THE SAME IS TRIMMED BEFORE SAVING THE RECORD.
 ENTER VALUE WITH SINGLE QUOTE AND '&' AND VALUES LIKE ~!@#$%^&*()_
 VERIFY CUT/COPY/PASTE IS SUPPORTED IN THE TEXT FIELD

3
FORM OBJECTS - NUMERIC FIELD
 VALIDATE FOR BOUNDARY CONDITIONS IN NUMERIC FIELDS.
 VALIDATE IF NEGATIVE NUMBERS IS NOT ACCEPTABLE IN NUMERIC FIELDS WHICH SHOULD
EXPECT POSITIVE NUMBERS.
 VALIDATE IF ANY VALUE IS BEING DISPLAYED FOR NUMERIC DATA, THE SAME IS DISPLAYED
ALONG WITH TWO DECIMAL PLACES UNLESS IT IS SYSTEM SPECIFIC. FOR E.G.: RS. 147
SHOULD BE DISPLAYED AS RS. 147.00
 ENTER A VALID NUMBER WITHIN THE SPECIFIED RANGE
 ENTER THE LOWEST NUMBER
 ENTER THE HIGHEST NUMBER
 ENTER A RATIONAL NUMBER (FRACTION) E.G., 2/5
 ENTER A NEGATIVE RATIONAL NUMBER (FRACTION) E.G. -2/5
 ENTER A SPACE IN THE FIRST POSITION AND THEN THE NUMBER
 ENTER A SPACE IN THE LAST POSITION AND THEN THE NUMBER
 ENTER NON NUMERIC VALUES LIKE !@#$%^&*()_

4
FORM OBJECTS - TOOL BAR & LIST
BOX
TOOL BAR
 THE TOOLBAR BUTTONS REQUIRE ONLY A SINGLE MOUSE CLICK TO ACTIVATE.
 THERE IS AN EQUIVALENT MENU ITEM FOR EVERY TOOLBAR BUTTON.
 ALL TOOLBAR BUTTONS SHOULD BE PROVIDED WITH A LABEL OR TOOL TIP.
 TOOLBAR BUTTONS ARE INITIALLY PLACED IN THE TOOLBAR AND THEN THE BUTTONS ARE
ACTIVATED/DEACTIVATED WHEN APPROPRIATE.
LIST BOX
 VALIDATE IF THE CONTENTS OF THE LIST BOXES IN THE SYSTEM ARE SORTED IN ASCENDING
ORDER.
 VALIDATE IF THE CONTENT SORTING IN THE LIST BOXES IS NOT CASE-SENSITIVE. I.E. THE LIST
SHOULD DISPLAY 'A' BEFORE 'A' AND 'A' BEFORE 'Z'.
 VALIDATE IF THE LIST BOXES HAVE 'ALL' OR 'PLEASE SELECT' OPTION AS REQUIRED.
 ENTER A VALUE IN THE DROP DOWN / LIST BOX
 SELECT A VALUE WITH THE MOUSE
 SELECT A VALUE WITH THE KEYBOARD
 SELECT MULTIPLE ITEMS FROM THE LIST BOX
 SCROLL BAR TO APPEAR AUTOMATICALLY, IF THERE ARE MORE THAN 8 ITEMS IN THE LIST BOX
 THE WIDTH TO EXPAND AUTOMATICALLY TO ACCOMMODATE THE LONGEST WORD/SENTENCE
 DEFAULT SELECTION
 VERIFY THAT OLD VALUE IS RETAINED WHEN USER ACTION/INPUT IS INVALID

5
RADIO/OPTION BUTTON, TEXT AREA
AND CHECKBOX
RADIO/OPTION BUTTON
 ALL RADIO BUTTONS HAVE TEXT LABELS MENTIONING THE ESSENCE OF THE BUTTON.
 USERS SHOULD NOT BE ABLE TO SELECT MORE THAN ONE RADIO BUTTON IN A GROUP.
 SELECT A BUTTON WITH THE MOUSE
 SELECT A BUTTON WITH THE KEYBOARD USING SPACE BAR
TEXT AREA
 ENTER VALID DATA WITHIN THE SPECIFIED RANGE
 ENTER THE LEAST NUMBER OF CHARACTERS AS DEFINED BY THE WIDTH
 ENTER THE MAXIMUM NUMBER OF CHARACTERS AS DEFINED BY THE WIDTH
 ENTER MORE NUMBER OF CHARACTERS WHICH EXCEEDS THE WIDTH
 ENTER DATA WITH BLANK IN FIRST POSITION
 ENTER DATA WITH A BLANK IN THE LAST POSITION
 ENTER DATA SURROUNDED BY SINGLE QUOTES
 ENTER DATA SURROUNDED BY DOUBLE QUOTES
 SCROLL BAR APPEARANCE, VERTICAL AND HORIZONTAL SHOULD APPEAR WHEN THE VISIBLE
AREA IS FILLED WITH DATA.
CHECKBOX
 ALL CHECKBOXES MUST HAVE TEXT LABELS MENTIONING THE ESSENCE.
 ABLE TO CHECK/UNCHECK USING MOUSE CLICK
 ABLE TO CHECK/UNCHECK USING SPACE BAR

6
FORM OBJECTS - DATE FIELD
 VALIDATE IF THE DATE DISPLAYED IS IN STANDARD FORMAT OF THE SYSTEM.
FOR EG:DD/MM/YYYY
 DATE FIELDS SHOULD CONTAIN A CALENDAR POPUP.
 DATE FIELDS SHOULD TAKE THE FORMAT BASED ON THE LOCALIZATION.
 DATE FIELD WILL CONTAIN AN ICON THAT IS UNIQUELY IDENTIFIED THROUGH
OUT THE DATE FIELDS.
 ASSURE THAT LEAP YEARS ARE VALIDATED
 ASSURE THAT OLD VALUE IS RETAINED WHEN MONTH VALUE IS 0 AND ABOVE 12
 ASSURE THAT DAY VALUES 0 AND ABOVE THE LAST DAY OF THE MONTH ARE
UPDATED WITH THE LAST DAY OF THE MONTH
 IF THERE ARE OTHER DATES ON THE SAME RECORD, CHECK IF THEY ACCEPT
THE VALUES WHICH DOESN’T BREAK THE FUNCTIONALITY. EXAMPLE END DATE
SHOULD BE >= START DATE
 ASSURE THAT OUT OF CYCLE DATES ARE VALIDATED CORRECTLY & DO NOT
CAUSE ERRORS/MISCALCULATIONS.
 VERIFY THAT THE OLD VALUE IS RETAINED WHEN USER ACTION/INPUT IS INVALID
 VALIDATE WITH ALL POSSIBLE DATE FORMATS.
 VALIDATE WITH ALL POSSIBLE TIME FORMATS

7
LOCALIZATION / GLOBALIZATION
TESTING
 VERIFY DIFFERENT REGIONAL SETTINGS
 ENTER LOCALIZED DATA INTO TEXT FIELDS
 VERIFY DIFFERENT DATE FORMATS
 VERIFY DIFFERENT CURRENCY FORMATS
 VERIFY FIELD LENGTHS ARE NOT TRUNCATING VALUES
 VERIFY FIELD LENGTHS ARE NOT TRUNCATING VALUES
 VERIFY LOCALIZED FIELD LABELS ARE NOT BEING TRUNCATED
 ENTER DATA OF DOUBLE BYTE (UTF-16) CHARACTERS WHEN THE DATABASE
COLUMN HOLDS DATA IN UNICODE FORMAT. ALSO WHEN THE REQUIREMENT IS
OF ONLY UTF-8
 VERIFY THE CONTENT BEING DISPLAYED FOR MIXED LANGUAGES IF THE
APPLICATION IS INDEPENDENT OF BROWSER SETTINGS

8
PASSWORD FIELD AND EMAIL ID
FIELD TEST CASES
PASSWORD FIELD
 VALIDATE IF THE PASSWORD FIELD IS LEFT BLANK AND RECORD IS SAVED
 VALIDATE IF THE RE- ENTER PASSWORD FIELD IS LEFT BLANK AND RECORD IS SAVED.
 VALIDATE FOR ACCEPTANCE OF LEADING SPACES IN THE PASSWORD FIELD, THE SAME ARE
SAVED.
 VALIDATE FOR ACCEPTANCE OF TRAILING SPACES IN THE PASSWORD FIELD, THE SAME ARE
SAVED.
 VALIDATE IF ONLY SPACES ARE ALLOWED TO BE SAVED IN THE PASSWORD FIELD
 VALIDATE IF ONLY QUOTES ARE ALLOWED TO BE SAVED IN THE PASSWORD FIELD
 VALIDATE WHETHER LEADING SPACES IN THE RE- ENTER PASSWORD FIELD ARE SAVED.
 VALIDATE WHETHER TRAILING SPACES IN THE RE-ENTER PASSWORD FIELD ARE SAVED.
 VALIDATE IF ONLY SPACES ARE ALLOWED TO BE SAVED IN THE RE-ENTER PASSWORD FIELD
 VALIDATE IF ONLY QUOTES ARE ALLOWED TO BE SAVED IN THE RE-ENTER PASSWORD FIELD
 VALIDATE IF RE-ENTER PASSWORD AND PASSWORD FIELDS CONTAIN DIFFERENT DATA
 VALIDATE IF RE-ENTER PASSWORD AND PASSWORD FIELDS CONTAIN SAME DATA BUT
DIFFERENT CASES(AS IN ONE IS CAPITAL AND OTHER IS SMALL CASE)
EMAIL ID FIELD
 VALIDATE IF AT LEAST ONE @ AND '.' ARE PRESENT IN EMAIL ID FIELD
 VALIDATE IF SPACES TRIMMED IN THE BEGINNING AND END OF EMAIL ID FIELD
 VALIDATE IF ONLY SPACES ALONG WITH @ AND . IS NOT ALLOWED TO BE SAVED IN EMAIL ID
FIELD
 VALIDATE IF EMAIL ID FIELD IS UNIQUE FOR A RECORD DEPENDING ON THE USABILITY.
 VALIDATE IF EMAIL ID FIELD IS CASE INSENSITIVE
 VALIDATE IF EMAIL ID FIELD ACCEPTS QUOTES
 VALIDATE DUPLICATE EMAIL ID FOR A SPECIFIC DOMAIN.

9
PARAMETER SCREEN & REPORTS
TEST CASES
 VALIDATE FOR BLANK INPUTS IN THE ‘FROM’ RANGE FIELD IS ACCEPTABLE.
 VALIDATE FOR BLANK INPUTS IN BOTH ‘FROM’ RANGE FIELD AND ‘TO’ RANGE FIELD IS
ACCEPTABLE
 VALIDATE FOR BLANK INPUTS IN ‘TO’ RANGE FIELD IS ACCEPTABLE.
 VALIDATE IF VALUE IN ‘TO’ RANGE FIELD IS SMALLER THAN ‘FROM’ FIELD IS NOT ACCEPTABLE.
 VALIDATE IF VALUE IN ‘TO’ RANGE FIELD IS SMALLER THAN ‘FROM’ FIELD IS NOT ACCEPTABLE.
 VALIDATE IF DATE RANGE FIELD DISPLAYS MAXIMUM VALUE PROVIDED IN SELECTION BOX IN
'TO' DATE FIELD AND MINIMUM VALUE IN THE FROM DATE FIELD. AS PER THE REQUIREMENT
OF THE QUERY.
 VALIDATE IF BLANK SCREEN IS SUBMITTED THEN ALL THE RECORDS ARE DISPLAYED.
 VALIDATE IF THE RESULT PAGE DISPLAYS THE NO. OF RECORDS FOUND FOR THE QUERY.
 VALIDATE IF THE RESULT PAGE DISPLAYS NEW QUERY LINK TO GO BACK TO THE QUERY
PAGE
 VALIDATE IF STANDARD NO. OF RECORDS IS DISPLAYED ON A SINGLE RESULT PAGE OF THE
REPORT.
 VALIDATE IF THE BUTTON ON THE PARAMETER SCREEN IS LABELED AS 'SEARCH'.
 VALIDATE IF NEXT AND PREVIOUS BUTTONS ARE PRESENT ON A PAGE, THE SAME IS LABELED
AS 'NEXT' AND 'PREV' AND IS POSITIONED ON THE RIGHT HAND SIDE AND LEFT HAND SIDE OF
THE SCREEN RESPECTIVELY.
 VALIDATE IF THE ALPHANUMERIC DATA & LABELS DISPLAYED IN THE REPORT IS LEFT
ALIGNED.
 VALIDATE IF THE NUMERIC DATA & LABELS DISPLAYED IN THE REPORT IS RIGHT ALIGNED.
 VALIDATE IF THE NUMERIC DATA & LABELS REPRESENTING ID FIELDS OR LINKS IS
DISPLAYED AS LEFT ALIGNED.

10
MULTI-USER TEST CASES
 SUBMISSION OF A FORM FROM TWO DIFFERENT MACHINES
 VALIDATE IF THE TWO DIFFERENT USERS ACCESS THE SAME RECORD FROM
DIFFERENT MACHINES.
 VALIDATE IF THE SAME USER IS ALLOWED TO ACCESS THE SAME RECORD
FROM DIFFERENT MACHINES.
 VALIDATE IF IN CASE OF MULTI-USER OPERATIONS, IF ANY UNIQUE KEY OR
PRIMARY KEY IS VIOLATED, APPROPRIATE ERROR MESSAGE IS SHOWN TO
ONE OF THE USER.
 VALIDATE FOR THE CHANGES IN MASTER DATA, WHEN THE SAME IS BEING
USED IN THE TRANSACTION FROM THE OTHER TERMINAL
 VALIDATE IF TWO DIFFERENT USERS TRY TO DELETE SAME RECORD FROM
DIFFERENT MACHINES. (VALIDATE IF A USER TRY TO DELETE SAME RECORD
FROM DIFFERENT BROWSERS.

11
LOGIN RELATED TEST CASES
 VALIDATE FOR SUBMISSION OF BLANK LOGIN SCREEN.
 VALIDATE FOR CANCELLATION ON BLANK LOGIN SCREEN.
 VALIDATE FOR THE FOCUS ON THE FIRST TEXT FIELD IN THE LOGIN SCREEN
AFTER INVOKING THE SCREEN
 VALIDATE FOR THE FOCUS ON THE LOGIN BUTTON IN THE LOGIN SCREEN AFTER
INVOKING THE SCREEN
 VALIDATE FOR SIMULTANEOUS LOGGING OF DIFFERENT TYPES OF USERS WITH
THE SAME USER NAME AND PASSWORD.
 VALIDATE IF THE USER NAME FIELD IS LEFT BLANK AND USER CLICKS ON LOGIN
 VALIDATE IF THE PASSWORD FIELD IS LEFT BLANK AND USER CLICKS ON LOGIN.
 VALIDATE IF AFTER CHANGING THE PASSWORD AND SAVING THE RECORD, THE
USER IS ALLOWED TO LOGIN.
 VALIDATE IF THE USER DOES NOT LOG OFF NORMALLY, HE IS ALLOWED RE-
LOGIN.
 VALIDATE IF ONLY THE USER NAME IS ENTERED RIGHT AND THE PASSWORD IS
ENTERED WRONG.
 VALIDATE IF ONLY THE PASSWORD IS ENTERED RIGHT AND THE USER NAME IS
ENTERED WRONG.
 VALIDATE IF PASSWORD IS CASE SENSITIVE.
 VALIDATE IF USERNAME IS CASE SENSITIVE.

12
FUNCTIONALITY
 VALIDATE IF THE BUSINESS REQUIREMENTS ARE BEING MET
 VALIDATE FOR ACCURACY OF THE CALCULATED FIELD. ALSO WHILE VALIDATING FOR PAGE
TOTAL VALIDATE ACROSS PAGES.
 VALIDATE FOR USAGE OF DATA ACROSS MODULES. ADDRESS BOOK ENTRIES CAN USED IN
EMAIL AND APPOINTMENTS MODULE
 VALIDATE FOR APPROPRIATENESS OF FIELD SIZE FOR STORING THE DATA, I.E. FIELD SIZE OF
12 IS NOT APPROPRIATE FOR STORING NAME LIKE 'BALASUBRAMANIAM‘
 VALIDATE FOR COMPLIANCE WITH THE DESIGN DOCUMENTS AND SPECIFIC PROJECT RELATED
LEGAL ISSUES AND STANDARDS
 VALIDATE FOR UNAUTHORIZED ACCESS OF THE SYSTEM. BOTH WITH PASSWORD SECURITY
AND ACCESS LEVEL SECURITY
 IF ANY FIELD HAS MULTIPLE VALIDATION RULE, VALIDATE FOR VALIDITY OF EACH OF THEM
 VALIDATE FOR INCLUSION OF ZERO'S IN COMPLEX CALCULATIONS
 VALIDATE FOR HANDLING OF SPECIAL CHARACTERS LIKE SINGLE QUOTES IN SEARCH
OPERATIONS
 VALIDATE FOR APPLICATION ACCESS WHEN THE DATABASE SERVER IS DOWN
 VALIDATE FOR DIV BY 0, CAN TEST FORCE THIS CONDITION
 VALIDATE FOR STORING OF PASSWORD IN ENCRYPTED FORMAT
 VALIDATE FOR VALIDITY OF PASSWORD EXPIRY RULE

13
FORM LEVEL TEST CASES
 IS THE SPELLING AND GRAMMAR CORRECT?
 ARE THE NON UPDATEABLE FIELDS HAVING A GRAY BACKGROUND ?
 IS THE GENERAL SCREEN BACKGROUND THE CORRECT COLOR?
 ARE THE FIELD PROMPTS THE CORRECT COLOR?
 ARE THE FIELD BACKGROUNDS THE CORRECT COLOR?
 ARE ALL THE FIELD PROMPTS SPELT CORRECTLY?
 IN READ-ONLY MODE, ARE THE FIELD PROMPTS THE CORRECT COLOR?
 IN READ-ONLY MODE, ARE THE FIELD BACKGROUNDS THE CORRECT COLOR?
 ARE ALL THE SCREEN PROMPTS SPECIFIED IN THE CORRECT SCREEN FONT?
 IS THE TEXT IN ALL FIELDS SPECIFIED IN THE CORRECT SCREEN FONT?
 ARE ALL THE FIELD PROMPTS ALIGNED PERFECTLY ON THE SCREEN?
 ARE ALL THE FIELD EDIT BOXES ALIGNED PERFECTLY ON THE SCREEN?
 ARE ALL GROUP BOXES ALIGNED CORRECTLY ON THE SCREEN?
 IS THE SCREEN RESIZABLE?
 IS THE SCREEN MINIMIZABLE?
 ARE ALL THE ERROR MESSAGES SPELT CORRECTLY ON THE SCREEN?
 ARE THE DIALOG BOXES HAVING A CONSISTENT LOOK AND FEEL
 VALIDATE FOR SUBMISSION OF BLANK FORM
 VALIDATE FOR CANCELLATION OF BLANK FORM
 VALIDATE FOR USER FORM COMPATIBILITY ON DIFFERENT SCREEN RESOLUTIONS
 VALIDATE FOR DATA LOSS WHEN THE SCREEN IS MINIMIZED BEFORE SAVING THE RECORD

14
FORM LEVEL TEST CASES
 VALIDATE FOR DATA LOSS WHEN THE USER SWITCHES FOCUS BETWEEN APPLICATIONS
BEFORE SAVING THE RECORD
 VALIDATE WHETHER ALL MANDATORY FIELDS ARE HIGHLIGHTED
 VALIDATE WHETHER RECORD IS ALLOWED TO BE SAVED IF DATA IS ENTERED ONLY IN THE
OPTIONAL FIELDS.
 VALIDATE FOR EACH MANDATORY FIELD, IF IT IS LEFT BLANK AND RECORD IS SAVED.
 VALIDATE FOR UNIQUENESS IN UNIQUE FIELDS DURING ADD.
 VALIDATE FOR UNIQUENESS IN UNIQUE FIELDS DURING UPDATE.
 VALIDATE IF RECORD IS ALLOWED TO BE SAVED WITH MAX DATA IN ALL FIELDS
 VALIDATE FOR DATA RETENTION WHEN THE BROWSER BACK AND FORWARD KEYS ARE
PRESSED
 RE SUBMISSION OF USER FORM AFTER DELETING DATA FROM ALL THE MANDATORY
FIELDS IN UPDATE MODE.
 RE SUBMISSION OF USER FORM AFTER DELETING DATA FROM ALL THE OPTIONAL FIELDS
IN UPDATE MODE.
 VALIDATE FOR SAVING OF DATA IN THE UPDATE MODE.
 VALIDATE IF NO OF RECORDS IS DISPLAYED ACROSS THE SYSTEM ON A SINGLE PAGE
BASED ON THE REQUIREMENTS.
 VALIDATE IF THE ERROR MESSAGES DISPLAYED TO THE USER IN CASE OF ERROR, USES
THE SAME FONT THAT IS USED ACROSS THE SYSTEM
 VALIDATE IF ABBREVIATIONS USED IN CASE OF INTERNAL CODIFICATION IS NOT DISPLAYED
AS A CODE TO THE USER BUT AS FULL DESCRIPTION OF THE CODE. (E.G. DESCRIPTION
'CREDIT CARD' INTERNAL CODE 'C')
 VALIDATE IF STATUS OF AN ENTITY IN THE SYSTEM IS DISPLAYED, THE SAME IS DISPLAYED
AS DISABLED/ENABLED OR TRUE/FALSE OR ANY OTHER RELEVANT STATUS AS PER THE
STANDARD OF THE SYSTEM.

15
USABILITY
 VERTICAL SCROLL DOES NOT GO BEYOND TWO PAGES.
 PREFERABLY, THERE SHOULD BE NO HORIZONTAL SCROLLING.
 PAGE SIZE SHOULD NOT EXCEED 65KB.IN EXCEPTIONAL CASES IT CAN GET TO 100K.REDUCING
PAGE SIZE GIVES BETTER PERFORMANCE ON THE WEB.
 TRANSACTIONAL BUTTONS SHOULD BE PLACED AT THE BOTTOM OF THE SCREEN ALSO IF THE
SCREEN HAS VERTICAL SCROLL BAR. (DEPENDS ON BUSINESS REQUIREMENT THOUGH)
 THERE SHOULD BE GAP BETWEEN THE LABEL AND CONTROLS. (SINGLE  )
 THERE SHOULD BE GAP BETWEEN CONTROL AND CALENDAR. (SINGLE  )
 CALENDAR IMAGE SHOULD BE MIDDLE ALIGNED TO THE CONTROL.
 MAX. LENGTH OF THE CONTROLS SHOULD MATCH WITH THE DATABASE FIELD LENGTH.
 VALIDATE FOR DISPLAY OF SYSTEM STATUS, IF BUSY THEN THE HOUR GLASS SHOULD BE
DISPLAYED
 VALIDATE FOR CONSISTENCY ACROSS THE MODULE
 VALIDATE FOR THE DISPLAY OF CHARACTERS AS LEFT ALIGNED AND NUMERIC FIELD RIGHT
ALIGNED
 VALIDATE FOR ACCESSIBILITY OF THE SCREEN FROM ALL THE OPTIONS PROVIDED I.E. MENUS,
TOOLBAR

16
USABILITY
 VALIDATE FOR THE CONTROL GOING BACK TO THE ERROR FIELD AFTER THE DISPLAY OF
ERROR MESSAGE
 VALIDATE FOR TOOL TIPS ON COMMAND BUTTONS
 VALIDATE FOR USER BEING IN CONTROL OF THE OPERATIONS BEING PERFORMED
 DOES THE TAB ORDER SPECIFIED ON THE SCREEN GO IN SEQUENCE FROM TOP LEFT TO
BOTTOM RIGHT? THIS IS THE DEFAULT UNLESS OTHERWISE SPECIFIED.
 ARE ALL READ-ONLY FIELDS AVOIDED IN THE TAB SEQUENCE?
 ARE ALL DISABLED FIELDS AVOIDED IN THE TAB SEQUENCE?
 IS THE CURSOR POSITIONED IN THE FIRST INPUT FIELD OR CONTROL WHEN THE SCREEN IS
OPENED?
 WHEN AN ERROR MESSAGE OCCURS DOES THE FOCUS RETURN TO THE FIELD IN ERROR
WHEN THE USER CANCELS IT?
 DOES THE SCREEN HAVE A CANCEL OPERATION FOR THE USER TO CANCEL THE
TRANSACTION
 IS THE SCREEN MODAL. i.e. IS THE USER PREVENTED FROM ACCESSING OTHER FUNCTIONS
WHEN THIS SCREEN IS ACTIVE AND IS THIS CORRECT?
 CAN A NUMBER OF INSTANCES OF THIS SCREEN BE OPENED AT THE SAME TIME AND IS THIS
CORRECT?
 CLICK A LINK BEFORE A PAGE IS DOWNLOADED COMPLETELY.
 VERIFY WHETHER A PAGE IS DISPLAYED PROPERLY UPON CLICKING A LINK FOR CERTAIN
NUMBER OF TIMES CONTINOUSLY.
 VERIFY WHETHER LOGGING AND VERSION CHECKING IS HAPPENED FOR NON-WEB
BASED UI.
 VERIFY WHETHER ALL UI’S ADHERE TO CORPORATE SECURITY SITE GUIDELINES.
THE GUIDELINES CAN BE FOUND AT http://itweb/polices/app_dev_host.htm.
 VERIFY WHETHER USER FRIENDLY ERROR MESSAGE IS DISPLAYED.

17
DATABASE-IMPORTING DATA
IMPORTING DATA FROM A FILE
 VERIFY BY PASSING MORE NUMBER OF COLUMNS THEN SPECIFIED.
 VERIFY BY NOT PASSING THE MANDATORY FIELDS.
 VERIFY BY PASSING MORE NUMBER OF CHARACTERS THEN SPECIFIED IN THE DESTINATION
DATABASE FOR A PARTICULAR COLUMN.
 VALIDATE DATA FOR LEADING AND TRAILING SPACES FOR THE ALPHANUMERIC COLUMNS.
 VERIFY DATA BY PASSING CHARACTERS FOR A COLUMN OF DATATYPE INTEGER. ALSO VERIFY
BY PASSING VALUES MORE THEN 2,147,483,647
 VALIDATE FOR DIFFERENT DATE FORMATS ALONG WITH TIME
 VALIDATE FOR THE FILE FORMATS
 VALIDATE FOR DIFFERENT DELIMITERS
IMPORTING DATA FROM A DATABASE
 VERIFY WHETHER SOURCE AND DESTINATION COLUMNS HAVE SAME COLUMN SIZE AND
DATATYPE.
 VERIFY WHETHER DESTINATION TABLE IS EXISTING WITH THE SPECIFIED COLUMNS.
 VERIFY WHEN A JOB IS STOPPED WHILE IT IS EXECUTING WHETHER IT IS ROLLED BACK OR IT
IS STARTING FROM THAT POINT
 VALIDATE DATA AGAINST THE RULES SPECIFIED FOR EACH COLUMN/TABLE
 VERIFY WHETHER PROPER ERROR MESSAGE IS DISPLAYED WHEN DATABASE SERVER
(DESTINATION SERVER) GOES DOWN WHEN SOURCE DATABASE SERVER IS HAVING ACTIVE
CONNECTION.

18
XML INPUT PARAMETERS
VALIDATION AND PERFORMANCE
XML INPUT PARAMETERS VALIDATION
 VERIFY PASSING PARAMETERS WITH LEADING AND TRAILING SPACES.
 VERIFY PASSING EMPTY PARAMETERS.
 VERIFY PASSING PARAMETERS OF DIFFERENT DATATYPES. FOR EX: PASS PARAMETERS OF
DATATYPE STRING FOR DATATYPE OF INTEGER
PERFORMANCE
 VALIDATE FOR THE RESPONSE TIME BY SCALING UP THE SIMULTANEOUS USER ACCESS AS
SPECIFIED IN BENCH MARKS.
 VALIDATE FOR THE RESPONSE TIME BY SCALING UP THE DATABASE RECORDS, FROM 10000,
50000, 60000 RECORDS OR AS SPECIFIED IN THE REQUIREMENTS
 VALIDATE FOR RESOURCE UTILIZATION WHEN MULTIPLE USERS ACCESS THE SYSTEM
 VALIDATE FOR RESOURCE UTILIZATION WHEN THE SYSTEM HAS BEEN OPERATIONAL FOR
MULTIPLE DAYS

19
Security Testing
Buffer overflow
Extraneous access to users
Extraneous ports/services
Error Message Risk
SQL Injection
Authentication/Authorization
Path Traversal Techniques
Renaming File Extensions
General SQL
Cross Site Scripting
Mail Relay risk
Hidden Fields
Sequential Numbering
Cookie Manipulation/ Encryption

20
Buffer overflow
Buffer overflow happens when something very
large is placed in an input box far too small for it to fit in.
Buffer overflows are used to crash the system, or to gain
complete control over it by having it execute an attacker's
malicious code.
Test cases:
1) Verify App doesn't crash/break when you cut and paste huge documents into
every input field of the application.
2) Verify all input fields have boundary checking.

21
Extraneous access to users
Application should restrict folder/files access to only
authenticated users.
Test cases:
1) Verify folder permission granted in IIS has the least privilege possible.
2) Verify global.asa file is readable to only minimal users and is set to "script
and read only" at the IIS server level.
3) Verify include files are not within the web root directory structure and also
ensure to set permissions on the directory where the files are.
4) Verify Java script include files are not available for direct download unless
required by the application.
5) Verify remote access to a server is permitted to Authenticated Users only
While enabling remote connections on a server, ensure that the "Access this
computer from the network" is set to Authenticated Users instead of
everyone.

22
Extraneous ports/services
Hackers use the easiest and most convenient way to exploit
well-known computer and Internet flaws. In most cases the
fewer ports/services you have open/enabled, the fewer
avenues an attacker can use to compromise your network.
Test cases:
1) Verify that all unused ports at the firewall or external packet-filtering device are
blocked, disabled, closed and the unnecessary ports from Internet facing NIC's are
unbound.
2) Verify that unnecessary protocols remain disabled.
3) Verify that services that are not required are not running and services that must run
should be given access to only those who absolutely require it.

23
Error Message Risk
Most of the applications provide more information than
required as part of the error message. The more the
information given to the hacker the more hints we are
providing for him to hack the application.
Test Cases:
1) Verify that user is not able to access the code through error messages. Sometimes
on the web site if there is a failure there is a message asking do you want to debug,
on clicking yes the user is able to view the code. Look for those instances.
2) Verify that only generic error messages are displayed to the user and unnecessary
information like user identity, system info, access info etc are not displayed.
Bad error message example: Password doesn’t match
the user name, Permission denied etc.
The ideal error message example: "An error has occurred in the application. “

24
SQL Injection
SQL Injection is simply a term describing the act of passing
SQL code into an application that was not intended by the
developer. SQL injection is usually caused by developers who
use "string-building" techniques in order to execute SQL code.
Test cases:
1) Verify that there is no obvious SQL Injection Vulnerability by passing a ‘, --, ‘OR, OR’,
‘AND’in an input field.
Eg. Enter ‘ in UserName field of your application. The application should not throw
an error or if an error is thrown, it should be generic and not provide any
information to the user/hacker.
An example of a bad error is:
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before
the character string '' AND UPPER(LTRIM(RTRIM(customer.password))) =''.
/sqltraining/ExampleCheck.asp, line 34

25
2) Verify that user cannot successfully do SQL injection from any input fields.
For example, If the following code is used to execute a query (VBScript/ASP sample):
Command_string = “INSERT INTO” + USERTABLE + “(Username,Password,Email)” + “
VALUES(“’+username + “’,”’ + password + “’,”’+ email + “’)”;
A user can enter, the following in the email field,
 bob@bob.com’);EXEC sp_addlogin ‘Ender’--
 bob@bob.com’);EXEC sp_adduser ‘Ender’- -
 bob@bob.com’);USE ApplicationTesting;GRANT SELECT ON Users TO Ender--
 bob@bob.com’);shutdown - -
 bob@bob.com’);drop table customer - -
SQL Injection Continued….

26
Improper validation of the user’s authentication, results in
application being vulnerable for unauthorized access/bypass
Logins.
Test Cases:
1) Verify bypassing of the login procedure by using a bookmark, history entry, or a captured
URL.
2) Verify that the unauthorized users are blocked from the system.
3) Verify that the expiration user accounts expire as expected.
4) Verify that the user is not able to view/update unauthorized information.
5) Verify that the application implements and enforces frequent password changing. Ensure
the new password works and the old password is deactivated.
6) Ensure only limited number of consecutive failed logins are allowed in the application.
Verify if this feature is configurable by a user in a configuration file or a registry key? If
yes, ensure only Admin has privileges to make the change.
7) Verify the application allows only strong passwords.
8) Verify that the user names and passwords are stored in the encrypted format either in the
database or configuration files, such as .INI files).
Authentication/Authorization

27
Path Traversal Techniques
a) Directory Enumeration
Directory enumeration is when a continual pattern of
directories can be predicted. An example is a directory
tree that uses time such as days, weeks, or even months
to group data.
Test Cases:
1) Anytime URL is found to be categorized, attempt to predict variations of what related URLs might also
be valid.
1a) For example if the url is
http://www.unknownserver.com/pictures/august/index.htm
Try to access different URL’s by changing the name of the months from January through
December.
1b) Given the URL:
http://www.unknownserver.com/users/4858567
It is quite possible that there are millions of other users on
this system. A user could write a program that checks
each of these URLs starting from this URL:
http://www.unknownserver.com/users/1
and then possibly find a directory that didn't give an
access-denied message.
b) Reverse Directory Traversal
Reverse directory traversal is the process of editing the URL in your web browser to attempt to access areas of
the web server that were not secured. By adding ../'s to existing URLs, and adjusting the amount of
directories to traverse, an attacker might gain access to a system files.

28
Test cases:
1) Try accessing different directories by reverse directory traversal; try to see if the
user can access the system root.
An example of this is the following URL:
Original - http://www.unknownserver.com/users/mary
Modified -http://www.unknownserver.com/users/mary/../../../../../config.sys
2) Try to access the directories by providing hexadecimal representation for /../
(this is to try out the reverse directory traversal technique in case the developer
has input validation only on the characters /../)
%5c%2c%2c%5c
3) http://www.?.com/users/../users/../users
c) Truncating Paths - Data Leakage
Truncating paths is a method to find directories that may not have been intended
for users to browse, and also to possibly gain browser access where no direction
from hyperlinks is available.
Path Traversal Techniques Continued….

29
Test Cases:
1) Edit the URL to try out different directories to view unauthorized information.
Given the following URL as a example
http://localhost:8080/users/mary/index.htm
Edit the URL in the browser to:
http://localhost:8080/users/mary
Note: Both Truncating Paths and reverse directory traversal are very related, the
difference is that by truncating paths the user can navigate only upto the main
website root but by reverse directory traversal method the user could navigate
beyond the website root even to the system root.
Generic test case that applies to all Path
Traversal techniques:
1) Ensure that directory browsing is turned off.
Path Traversal Techniques Continued….

30
Renaming File Extensions
Network administrators and developers often leave backup
files and scripts on the web server. These files commonly
contain information that can be used to breach a site's
security. Extension checking involves replacing extensions on
files, and then looking for older or backup versions stored on
the site.
Test cases:
1) Ensure that directory browsing is turned off.
2) Try to access the URL appending the file names with the following extensions
.bak, .log, .test, .old, .list, .backup
1) Try to access the URL appending the file names with the combinations of the
above extensions
For e.g. .bak.old, .log.old, .test_old

31
General SQL
Here are some general SQL related security test cases that testers should keep in mind.
Test cases:
1) Try the following userid’s and passwords to login into sql server
Userid : sa Password: blank
Userid : sa Password: sa
Userid : sa Password: Password
2) Verify that the sa passwords in the database are not easily-guessable.
3) Verify that no login Ids have passwords that are the same as the login.
4) Drop master..Xp_cmdshell if you can do without it. If it has to be used, permission should be
granted only to people who absolutely need it.
5) Take the time to audit for logins with null passwords. Use the following code to check for null
passwords:
Use master
Select name, Password from syslogins
where password is null
order by name

32
6) Check access permissions for all non-“sa”s on stored procs and extended stored procs. Use
the following query to periodically query which procedures have public access:
Use master
Select sysobjects.name
From sysobjects, sysprotects
Where sysprotects.uid = 0
AND xtype IN ('X','P')
AND sysobjects.id = sysprotects.id
Order by name
7) Unless administrative privileges are required by the SQL Server, SQL server services should
run in the context of normal user accounts.
General SQL Continued….

33
Cross Site scripting
This issue occurs when dynamically generated web pages display input that is not properly validated. This allows an
attacker to embed malicious script into the generated page, allowing the attacker to execute script on the machine
of any user that views the malicious page. To avoid cross site scripting all important validations should be done on the
server side rather than on the client.
Test Cases:
1) Verify that special characters and keywords like < > “ ‘ % ; ) ( & + and SCRIPT are filtered/blocked from all
input (input boxes, URLs and cookies.)
For example , in an input field enter

<b>some text</b>

<script>alert(‘hello’);</script>
Sample Strings:

<

<b>

<SCRIPT>

<SCRscriptIPT>

<<SCRIPT>>

34
Mail Relay risk and Hidden Fields
When an e-mail server is not configured to restrict how e-mail is routed, it is allowed to process a mail message where
neither the sender nor the recipient is a local user. Then spammers or hackers can take advantage of this to do mass
mailing or to slow your server down. Leaving mail capability open gives a potential attacker another means of
delivering potential trojans, viruses, or simply launching a particularly nasty denial of service attack.
Test Cases:
1) Verify that Mail relay is disabled if not required.
2) Disable SQL Mail capability unless absolutely necessary.
3) If Mail relay is required, by the application, verify that the service is configured so that the
"MAIL FROM" can not be different than the domain in which the server resides.
Hidden Fields
Hidden fields are fields that are used to store state information as data is passed back and forth between the
client and server.
Test Cases:
1) Ensure that secure information like userid’s, passwords and any other sensitive information
are not stored in the hidden fields by looking at view source on the web application.

35
Sequential Numbering
Sequential numbering is when an application increments
numbers for any of its key fields which, can be easily
discovered and exploited by hackers.
Test Cases:
1) Make sure that Authentication/Authorization are not based on unmasked
sequential number only (example: UserID = 1, 2, 3……)
Not only hackers but also users with access to the site
may guess and enter the numbers to retrieve
information they are not supposed to see.
For example:
Given the URL
http://www.unknownserver.com/users/userInfo.aspx?userID=5
It is quite possible that there are millions of other users on this system. Try
changing the url by incrementing the UserID value and see if it can be
accessed.

36
Cookie Manipulation/ Encryption
Cookie manipulation is when a user changes the contents of a cookie on the client. These changes
could allow the user access to areas on a website that were prohibited previously.
Test Cases:
1) Verify cookie doesn’t contain any sensitive information
2) Verify user can not gain access or escalated permission to the web site by modifying the
cookie.
For example:
A system that uses cookies and has auto-login feature, logon as a valid user and modify
the value of any key logon fields like username/userid in the cookie, changing it to
an arbitrary name/number (same number of bytes as earlier) to impersonate them.
3) Verify encryption is used if sensitive information is passed between client and server.
4) Verify that cookie is actually encrypted if the web site is using encryption
5) Verify system logs off user after certain period of time (session time out)
6) Verify logout option expires user’s session
7) Verify password or any other sensitive information is not displayed even to admin in clear
text format.

37
References
 http://www.securityfocus.org
 http://www.spidynamics.org
 http://officehack/hack.htm
 http://www.sqlsecurity.com
 jusql28SecurityLabsApplicationTestingCourseMaterials-AppTest

38
INSTALLATION TESTING
 VALIDATE FOR FUNCTIONING OF THE SYSTEM WITH DIFFERENT OPERATING SYSTEM AS
STATED IN THE REQUIREMENT DOCUMENT
 VALIDATE FOR INSTALLATION ON A CLEAN MACHINE
 VALIDATE FOR PROMPTING, IN CASE OF INSUFFICIENT SPACE FOR INSTALLATION
 VALIDATE THAT UNINSTALL OPERATION REMOVES ALL TRACES OF THE PROGRAM
 VALIDATE FOR CANCELLATION OF INSTALLATION OPERATION MIDWAY. RE-INSTALL THE
INSTALLATION PROCESS SHOULD COMPLETE SMOOTHLY
 VALIDATE FOR INSTALLATION IN THE DEFAULT DIRECTORY
 VALIDATE FOR INSTALLATION IN THE USER DEFINED DIRECTORY AND WORKING OF ALL MAIN
OPERATION
 VALIDATE FOR INSTALLATION WITH LOGIN FILE PATH, PATH'S WITH SPACES
 VALIDATE FOR MIGRATION OF DATA FROM THE OLD SYSTEM
 VALIDATE FOR INSTALLATION OF APPLICATION ON ONE MACHINE AND DATABASE ON ANOTHER
MACHINE
 VALIDATE FOR PRINTING ON DIFFERENT TYPE OF PRINTERS
 VERIFY WHETHER ALL THE TABLES/VIEWS HAS BEEN CREATED WELL BEFORE AS SPECIFIED IN
THE FUNCTIONAL SPEC'S
 VERIFY WHETHER ALL THE CONSTRAINTS AND INDEXES HAS BEEN CREATED AS SPECIFIED IN
THE FUNCTIONAL SPEC'S
 VERIFY WHETHER ALL THE COMMAND LINES PROCESSES INCLUDED AS A SERVER CHECK. THE
SERVER CHECK SHOULD BE CUSTOMIZABLE.
 VERIFY WHETHER THE BUILD PROCESS ABLE TO RESTART FROM THE FAILURE
MODE.
 VERIFY WHETHER THE LONG BUILD PROCESS ARE MONITORED AND LOGGED
EXACTLY.

Generictestcasesguidelines 101201033527-phpapp01

More Related Content

Recently uploaded (20)

Featured (20)

Generictestcasesguidelines 101201033527-phpapp01

Editor's Notes