Generic test cases guidelines

15,332 views

Published on

Published in: Education
5 Comments
11 Likes
Statistics
Notes
No Downloads
Views
Total views
15,332
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
542
Comments
5
Likes
11
Embeds 0
No embeds

No notes for slide
  • [RF – Is this a part of test case 3) or a separate test case regarding any directory (not only for include files) in general?]
  • [RF - Does Scale tool check for open ports and enabled services? If so, we might want to mention that.]
  • The first single quote entered by the user closed the string and SQL Server eagerly executes the next SQL statements in the batch including a command to create a new login, add a new user to the local accounts database and grant permissions to the user.  If this application were running as 'sa' and the MSSQLSERVER service is running with sufficient privileges we would now have an account with which to access this machine.  Also note the use of the comment operator (--) to force the SQL Server to ignore the trailing quote placed by the developer's code.
    [RF 1 – I sent the comment for this in the email on Friday.]
    [RF 2 – I think a list of sample strings for email field are kind of redundant. It may be better to list only 1 or 2 and then add a section to list a sample of combinations of characters to use. – which one to use is depending on the query a developer is trying to create.
    These are a sample list the instructor gave us in the class.

    --
    ‘OR
    OR’
    ‘AND’
    ‘Value, Value, Value’
    ]
  • [RF 1 – I moved the following explanation from the slide to this comment section.]
    First will bold the text and the second will end table.
    [RF 2 – Don’t you think this test case is too generic and doesn’t tell you what has to be done to verify this?
    Also, test case 1) is executed for all possible input in addition to input boxes in the UI so that we can make sure that the app is not relying only the client side validation and validation is done on the server side. So test case 2) is a basic concept for test case 1) thus we should mention it, but shouldn’t be a test case. – what do you think?]
    [RF 3 – We may want to add a sample test string which is practical for testing and we can use as standard test script.]
  • [RF 1 – Comment sent in email.]
    [RF 2 – Same as the first comment. Wouldn’t it be better to separate this into two test cases – One for mail relay feature and the other for SQL mail capability.]
  • [RF – I changed the title to Sequential Numbering. I hope it’s ok with you.]
    [RF 1 – This sentence doesn’t have to be in the slide if we need to reduce the text in the slide. This can be verbal explanation.]
    [RF 2 – This also can be removed from the slide. This should be verbal explanation.]
  • [RF 1 – Test case 1) and 2) are the same and may not be accurate. We might want to say simply: ‘Verify encryption is used if sensitive information is passed between client and server.’ or something like that. We can provide samples of sensitive information verbally.]
    [RF 2 – Test case 3) and 4) are the same.
  • Generic test cases guidelines

    1. 1. 1 Generic Test Cases Guidelines  Krishna Kishore K
    2. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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. 19. 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. 20. 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. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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. 37. 37 References  http://www.securityfocus.org  http://www.spidynamics.org  http://officehack/hack.htm  http://www.sqlsecurity.com  jusql28SecurityLabsApplicationTestingCourseMaterials-AppTest
    38. 38. 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.

    ×