Generic test cases guidelines

38
1 Generic Test Cases Guidelines Krishna Kishore K

Transcript of Generic test cases guidelines

Page 1: Generic test cases guidelines

1

Generic Test Cases Guidelines

Krishna Kishore K

Page 2: Generic test cases guidelines

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

Page 3: Generic test cases guidelines

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 !@#$%^&*()_

Page 4: Generic test cases guidelines

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

Page 5: Generic test cases guidelines

5

RADIO/OPTION BUTTON, TEXT AREAAND 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

Page 6: Generic test cases guidelines

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

Page 7: Generic test cases guidelines

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

Page 8: Generic test cases guidelines

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.

Page 9: Generic test cases guidelines

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.

Page 10: Generic test cases guidelines

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.

Page 11: Generic test cases guidelines

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.

Page 12: Generic test cases guidelines

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

Page 13: Generic test cases guidelines

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

Page 14: Generic test cases guidelines

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.

Page 15: Generic test cases guidelines

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

Page 16: Generic test cases guidelines

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.

Page 17: Generic test cases guidelines

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.

Page 18: Generic test cases guidelines

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

Page 19: Generic test cases guidelines

19

Security Testing

Buffer overflowExtraneous access to usersExtraneous ports/servicesError Message RiskSQL InjectionAuthentication/AuthorizationPath Traversal TechniquesRenaming File ExtensionsGeneral SQLCross Site ScriptingMail Relay riskHidden FieldsSequential NumberingCookie Manipulation/ Encryption

Page 20: Generic test cases guidelines

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 gaincomplete control over it by having it execute an attacker'smalicious 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.

Page 21: Generic test cases guidelines

21

Extraneous access to users Application should restrict folder/files access to onlyauthenticated 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.

Page 22: Generic test cases guidelines

22

Extraneous ports/services Hackers use the easiest and most convenient way to exploitwell-known computer and Internet flaws. In most cases thefewer ports/services you have open/enabled, the feweravenues 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.

Page 23: Generic test cases guidelines

23

Error Message Risk Most of the applications provide more information thanrequired as part of the error message. The more theinformation given to the hacker the more hints we areproviding 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 matchthe user name, Permission denied etc.The ideal error message example: "An error has occurred in the

application. “

Page 24: Generic test cases guidelines

24

SQL InjectionSQL Injection is simply a term describing the act of passing SQL code into an application that was not intended by thedeveloper. SQL injection is usually caused by developers whouse "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

Page 25: Generic test cases guidelines

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, [email protected]’);EXEC sp_addlogin ‘Ender’-- [email protected]’);EXEC sp_adduser ‘Ender’- - [email protected]’);USE ApplicationTesting;GRANT SELECT ON Users TO Ender-- [email protected]’);shutdown - - [email protected]’);drop table customer - -

SQL Injection Continued….

Page 26: Generic test cases guidelines

26

Improper validation of the user’s authentication, results inapplication being vulnerable for unauthorized access/bypassLogins.

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

Page 27: Generic test cases guidelines

27

Path Traversal Techniques

a) Directory EnumerationDirectory enumeration is when a continual pattern ofdirectories can be predicted. An example is a directorytree that uses time such as days, weeks, or even monthsto 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 onthis system. A user could write a program that checkseach of these URLs starting from this URL:

http://www.unknownserver.com/users/1and then possibly find a directory that didn't give anaccess-denied message.

b) Reverse Directory TraversalReverse 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.

Page 28: Generic test cases guidelines

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.sys2) 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 LeakageTruncating 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….

Page 29: Generic test cases guidelines

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.htmEdit the URL in the browser to:http://localhost:8080/users/maryNote: 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….

Page 30: Generic test cases guidelines

30

Renaming File Extensions Network administrators and developers often leave backupfiles 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

3) 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

Page 31: Generic test cases guidelines

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: blankUserid : sa Password: saUserid : 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 masterSelect name, Password from sysloginswhere password is nullorder by name

Page 32: Generic test cases guidelines

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 masterSelect sysobjects.nameFrom sysobjects, sysprotectsWhere sysprotects.uid = 0AND xtype IN ('X','P')AND sysobjects.id = sysprotects.idOrder 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….

Page 33: Generic test cases guidelines

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

Page 34: Generic test cases guidelines

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 FieldsHidden 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.

Page 35: Generic test cases guidelines

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 URLhttp://www.unknownserver.com/users/userInfo.aspx?userID=5It 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.

Page 36: Generic test cases guidelines

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 encryption5) 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.

Page 37: Generic test cases guidelines

37

References

http://www.securityfocus.org http://www.spidynamics.org http://officehack/hack.htm http://www.sqlsecurity.com \\jusql28\SecurityLabs\ApplicationTesting\CourseMaterials-AppTest

Page 38: Generic test cases guidelines

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.