Web Application Testing Checklist

1. FUNCTIONALITY 1.1 LINKS 1.1.1 Check that the link takes you to the page it said it would. 1.1.2 Ensure to have no orphan pages (a page that has no links to it) 1.1.3 Check all of your links to other websites 1.1.4 re all referenced web sites or e!ail addresses hyperlinked" 1.1.# $f we have re!oved so!e of the pages fro! our own site% set up a custo! 4&4 page that redirects your visitors to your ho!e page (or a search page) when the user try to access a page that no longer e'ists. 1.1.( Check all !ailto links and whether it reaches properly 1.2 FO !S 1.2.1 cceptance of invalid input 1.2.2 )ptional versus !andatory fields 1.2.3 $nput longer than field allows 1.2.4 *adio buttons 1.2.# +efault values on page load,reload( lso ter!s and conditions should be disabled) 1.2.( $s Co!!and -utton can be used for .yper/inks and Continue /inks " 1.2.( $s all the datas inside co!bo,list bo' are arranged in chronolgical order" 1.2.0 re all of the parts of a table or for! present" Correctly laid out" Can you confir! that selected te'ts are in the 1right place" 1.2.2 +oes a scrollbar appear if re3uired" 1." #ATA $% IFICATION AN# $ALI#ATION 1.3.1 $s the 4rivacy 4olicy clearly defined and available for user access" 1.3.2 t no point of ti!e the syste! should behave awkwardly when an invalid data is fed 1.3.3 Check to see what happens if a user deletes cookies while in site 1.3.4 Check to see what happens if a user deletes cookies after visiting a site 2. A&&LICATION S&%CIFIC FUNCTIONAL 2.1 #ATA INT%( ATION 2.1.1 Check the !a'i!u! field lengths to ensure that there are no truncated characters" 2.1.2 $f nu!eric fields accept negative values can these be stored correctly on the database and does it !ake sense for the field to accept negative nu!bers" 2.1.3 $f a particular set of data is saved to the database check that each value gets saved fully to the database. (i.e.) -eware of truncation (of strings) and rounding of nu!eric values. 2.2 #AT% FI%L# C)%CKS 2.2.1 ssure that leap years are validated correctly 5 do not cause errors,!iscalculations. 2.2.2 ssure that 6eb. 22% 27% 3& are validated correctly 5 do not cause errors, !iscalculations. 2.2.3 $s copyright for all the sites includes 8ahoo co9branded sites are updated 2." NU!% IC FI%L#S 2.3.1 ssure that lowest and highest values are handled correctly. 2.3.2 ssure that nu!eric fields with a blank in position 1 are processed or reported as an error. 2.3.3 ssure that fields with a blank in the last position are processed or reported as an error an error. 2.3.4 ssure that both : and 9 values are correctly processed. 2.3.# ssure that division by ;ero does not occur. 2.3.( $nclude value ;ero in all calculations. 2.3.0 ssure that upper and lower values in ranges are handled correctly. (<sing -= ) 2.* AL&)ANU!% IC FI%L# C)%CKS %'UI %!%NTS

2.4.1 <se blank and non9blank data. 2.4.2 $nclude lowest and highest values. 2.4.3 $nclude invalid characters 5 sy!bols. 2.4.4 $nclude valid characters. 2.4.# $nclude data ite!s with first position blank. 2.4.( $nclude data ite!s with last position blank.

". INT% FAC% AN# % O )AN#LIN( ".1 S% $% INT% FAC% 3.1.1 =erify that co!!unication is done correctly% web server9application server% application server9 database server and vice versa. 3.1.2 Co!patibility of server software% hardware% network connections ".2 %+T% NAL INT% FAC% 3.2.1 .ave all supported browsers been tested" 3.2.2 .ave all error conditions related to e'ternal interfaces been tested when e'ternal application is unavailable or server inaccessible" "." INT% NAL INT% FAC% 3.3.1 $f the site uses plug9ins% can the site still be used without the!" 3.3.2 Can all linked docu!ents be supported,opened on all platfor!s (i.e. can >icrosoft ?ord be opened on @olaris)" 3.3.3 re failures handled if there are errors in download" 3.3.4 Can users use copy,paste functionality"+oes it allows in password,C==,credit card no field" 3.3.# re you able to sub!it unencrypted for! data" ".* INT% NAL INT% FAC% 3.4.1 $f the syste! does crash% are the re9start and recovery !echanis!s efficient and reliable" 3.4.2 $f we leave the site in the !iddle of a task does it cancel" 3.4.3 $f we lose our $nternet connection does the transaction cancel" 3.4.4 +oes our solution handle browser crashes" 3.4.# +oes our solution handle network failures between ?eb site and application servers" 3.4.( .ave you i!ple!ented intelligent error handling (fro! disabling cookies% etc.)" *. CO!&ATI,ILITY *.1 , OWS% S 4.1.1 $s the .A>/ version being used co!patible with appropriate browser versions" 4.1.2 +o i!ages display correctly with browsers under test" 4.1.3 =erify the fonts are usable on any of the browsers 4.1.4 $s Bava Code,@cripts usable by the browsers under test" 4.1.# .ave you tested ni!ated C$6s across browsers" *.2 $I#%O S%TTIN(S 4.2.1 @creen resolution (check that te't and graphic align!ent still work% font are readable etc.) like 1&24 by 0(2% (&&'2&&% (4& ' 42& pi'els etc 4.2.2 Colour depth (2#(% 1(9bit% 329bit) *." CONN%CTION S&%%# 4.3.1 +oes the site load 3uickly enough in the viewerDs browser within 2 @econds" *.* & INT% S

4.4.1 Ae't and i!age align!ent 4.4.2 Colours of te't% foreground and background 4.4.3 @calability to fit paper si;e 4.4.4 Aables and borders 4.4.# +o pages print legibly without cutting off te't"

Use- Inte-.ace Testing Checklist

1. US% INT% FAC% 1.1 COLO S 1.1.1 re hyperlink colors standard" 1.1.2 re the field backgrounds the correct color" 1.1.3 re the field pro!pts the correct color" 1.1.4 re the screen and field colors adEusted correctly for non9editable !ode" 1.1.# +oes the site use (appro'i!ately) standard link colors" 1.1.( re all the buttons are in standard for!at and si;e" 1.1.0 $s the general screen background the correct color" 1.1.2 $s the page background (color) distraction free" 1.2 CONT%NT 1.2.1 ll fonts to be the sa!e 1.2.2 re all the screen pro!pts specified in the correct screen font" 1.2.3 +oes content re!ain if you need to go back to a previous page% or if you !ove forward to another new page" 1.2.4 $s all te't properly aligned" 1.2.# $s the te't in all fields specified in the correct screen font" 1.2.( $s all the heading are left aligned 1.2.0 +oes the first letter of the second word appears in lowercase" EgF 1." I!A(%S 1.3.1 re all graphics properly aligned" 1.3.2 re graphics being used the !ost efficient use of file si;e" 1.3.3 re graphics opti!i;ed for 3uick downloads" 1.3.4 ssure that co!!and buttons are all of si!ilar si;e and shape% and sa!e font 5 font si;e. 1.3.# -anner style 5 si;e 5 display e'act sa!e as e'isting windows 1.3.( +oes te't wrap properly around pictures,graphics" 1.3.0 $s it visually consistent even without graphics" 1.* INST UCTIONS 1.4.1 $s all the error !essage te't spelt correctly on this screen" 1.4.2 $s all the !icro9help te't(i.e tool tip) spelt correctly on this screen" 1.4.3 >icrohelp te't(i.e tool tip) for every enabled field 5 button 1.4.4 4rogress !essages on load of tabbed(active screens) screens 1./ NA$I(ATION 1.#.1 re all disabled fields avoided in the A - se3uence" 1.#.2 re all read9only fields avoided in the A - se3uence" 1.#.3 Can all screens accessible via buttons on this screen be accessed correctly" 1.#.4 +oes a scrollbar appear if re3uired" 1.#.# +oes the Aab )rder specified on the screen go in se3uence fro! Aop /eft to botto! right" Ahis is the default unless otherwise specified. 1.#.( $s there a link to ho!e on every single page" 1.#.0 )n open of tab focus will be on first editable field 1.#.2 ?hen an error !essage occurs does the focus return to the field in error when the user cancels it"

1.0 USA,ILITY 1.(.1 re all the field pro!pts spelt correctly" 1.(.2 re fonts too large or too s!all to read" 1.(.3 re na!es in co!!and button 5 option bo' na!es are not abbreviations. 1.(.4 ssure that option bo'es% option buttons% and co!!and buttons are logically grouped together in clearly de!arcated areas 1Croup -o'1 1.(.# Can the typical user run the syste! without frustration" 1.(.( +o pages print legibly without cutting off te't" 1.(.0 +oes the site convey a clear sense of its intended audience" 1.(.2 +oes the site have a consistent% clearly recogni;able 1look959feel1" 1.(.7 +oes <ser cab /ogin >e!ber rea with both <serGa!e,E!ail $+ " 1.(.7 +oes the site look good on (4& ' 42&% (&&'2&& etc." 1.(.1& +oes the syste! provide or facilitate custo!er service" i.e. responsive% helpful% accurate" 1.(.11 $s all ter!inology understandable for all of the siteHs intended users"

(UI Testing Checklist

4urpose of this C<$ Aesting Checklist is to help you understand how your application can be tested according to the known and understood standards for C<$. Ahis checklist can give so!e guidance to the develop!ent and IE% both the tea!s. +evelop!ent tea! can !ake sure that during the develop!ent they follow guidelines related to the co!pliance% aesthetics% navigation etc. but onus of testing C<$ is on the IE tea! and as a tester it is your responsibility to validate your product against C<$ standards followed by your organi;ation. Ahis C<$ test checklist can ensure that all the C<$ co!ponents are thoroughly tested. $n the first part of this checklist% we will cover ?indows co!pliance standard and so!e test ideas for field

specific tests. Win1o2s Co3pliance Stan1a-1s

Ahese co!pliance standards are followed by al!ost all the windows based application. ny variance fro! these standards can result into inconvenience to the user. Ahis co!pliance !ust be followed for every application. Ahese co!pliances can be categori;ed according to following criteria i. Compliance for each application a. pplication should be started by double clicking on the icon. b. /oading !essage should have infor!ation about application na!e% version nu!ber% icon etc. c. >ain window of application should have sa!e caption as the icon in the progra! !anager. d. Closing of the application should result in J re you sure"K !essage. e. -ehaviour for starting application !ore than once !ust be specified. f. Ary to start application while it is loading g. )n every application% if application is busy it should show hour glass or so!e other !echanis! to notify user that it is processing. h. Gor!ally 61 button is used for help. $f your product has help integrated% it should co!e by pressing 61 button. i. >ini!i;e and restoring functionality should work properly Compliance for each window in the application a. ?indow caption for every application should have application na!e and window na!e. @pecially% error !essages. b. Aitle of the window and infor!ation should !ake sense to the user. c. $f screen has control !enu% use the entire control !enu like !ove% close% resi;e etc. d. Ae't present should be checked for spelling and gra!!ar. e. $f tab navigation is present% A - should !ove focus in forward direction and @.$6A:A in backward direction. f. Aab order should be left to right and top to botto! within a group bo'. g. $f focus is present on any control% it should be presented by dotting lines around it.

ii.

h. i. E. k.

<ser should not be able to select greyed or disabled control. Ary this using tab as well as !ouse. Ae't should be left Eustified $n general% all the operations should have corresponding key board shortcut key for this. ll tab buttons should have distinct letter for it.

iii.

Text boxes a. >ove !ouse to te'tbo' and it should be changed to insert bar for editable te't field and should re!ain unchanged for non9editable te't field. b. Aest overflowing te'tbo' by inserting as !any characters as you can in the te't field. lso test width of the te't field by entering all capital ?. c. Enter invalid characters% special characters and !ake sure that there is no abnor!ality. d. <ser should be able to select te't using @hift : arrow keys. @election should be possible using !ouse and double click should select entire te't in the te't bo'. Radio Buttons a. )nly one should be selected fro! the given option. b. <ser should be able to select any button using !ouse or key board c. rrow key should set,unset the radio buttons. Check boxes a. <ser should be able to select any co!bination of checkbo'es b. Clicking !ouse on the bo' should set,unset the checkbo'. c. @pacebar should also do the sa!e Push Buttons a. ll buttons e'cept )L,Cancel should have a letter access to the!. Ahis is indicated by a letter underlined in the button te't. Ahe button should be activated by pressing /A b. Clicking each button with !ouse should activate it and trigger re3uired action. c. @i!ilarly% after giving focus @4 CE or *EA<*G button should also do the sa!e. d. $f there is any Cancel button on the screen% pressing Esc should activate it. Drop down list boxes a. 4ressing the arrow should give list of options available to the user. /ist can be scrollable but user should not be able to type in. b. 4ressing Ctrl964 should open the list bo'. c. 4ressing a letter should bring the first ite! in the list starting with the sa!e letter. d. $te!s should be in alphabetical order in any list. e. @elected ite! should be displayed on the list. f. Ahere should be only one blank space in the dropdown list. Combo Box a. @i!ilar to the list !entioned above% but user should be able to enter te't in it. List Boxes a. @hould allow single select% either by !ouse or arrow keys. b. 4ressing any letter should take you to the first ele!ent starting with that letter c. $f there are view,open button% double clicking on icon should be !apped to these behaviour. d. >ake sure that all the data can be seen using scroll bar.

iv.

v.

vi.

vii.

viii.

i'.

Testing &lan
Aest plan is probably one of the !ost significant docu!ent for software testing proEects. Aest plan !ay contain infor!ation related to scope% environ!ent% schedule% risk% resources% e'ecution% reporting% auto!ation% co!pletion criteria etc. Aest plan is usually created by Aest >anager% Aest /ead or senior testers in the tea!. -efore start preparing Aest 4lan% infor!ation should be captured fro! various stakeholders of the proEect. $nfor!ation captured fro! stake holder is reflected in the Aest 4lan. Aypically%

every Aest 4lan contain infor!ation about following activities. $nfor!ation about these activities can be gathered fro! various stakeholders by asking 3uestions that are re3uired for your Aest 4lan. Scope !anage3ent4 -efore starting Aest 4lanning activity% scope of the test activities should be known. 8ou should have infor!ation on what features will be tested and what will not be tested. 8ou should also have infor!ation on what areas your tea! is owning" re you taking care of all the types of testing that is re3uired for the product including 4erfor!ance% @ecurity% globali;ation etc. +efining scope for your testing proEect is very i!portant for the !anage!ent as well. $f scope is properly defined% every one will have clear understanding about what is tested and what is not. e.e-ence4 8ou should clearly define docu!ents you are referring to prepare test plan. ny changes in the docu!ents you are referring should be reflected in your plan. isk !anage3ent4 Aest strategy is derived fro! the risk analysis. *isk will be different fro! one proEect to another and so your Aest strategy. *isk associated with a desktop ta' calculation software will be different fro! pay!ent gateway or life support syste!. $n your testing strategy% you need to !ake sure that all the potential risks are captured and !anaged by your testing activities. 8ou should% along with the other stake holders define what are the potential risk in the proEect" ?hat will be the i!pact if these risks are !ateriali;ed" ?hat is the !itigation plan for these risks and how your testing activities are !aking sure that these risks are !anaged properly. Test %n5i-on3ent4 8ou should have infor!ation on what will be the environ!ent for the testing. Ahis infor!ation is captured fro! stake holders by asking the!% ?hat type of environ!ent will be supported by product" ?hat is the priority for these environ!ent" 6or e'a!ple% $f product is supported on all the platfor! and data for user distribution says that 2& percent are on ?indows% 1# percent are on /inu' and # percent are on >ac. 6ro! this data you can !ake out which platfor! will be tested !ore. $nfor!ation captured here will be useful for planning hardware and software re3uire!ent for your Aest /ab. C-ite-ia #e.inition4 Criteria for Entry and E'it should be clearly defined for every activity of your testing proEect. 8ou should have well defined entry,e'it criteria for starting% stopping% suspending and resu!ing test activities. 8ou should also have criteria defined for specifying when testing is co!plete. %sti3ation6 Sche17ling an1 eso7-ce !anage3ent4 >ostly% testing proEect follows develop!ent activities. @o for esti!ation and scheduling you should have infor!ation on the develop!ent plan and !ilestone. )nce you have infor!ation on the develop!ent plan% you can schedule your testing activities accordingly. *esources in testing proEects include hardware% software and people !anage!ent. Testing Tools an1 A7to3ation4 8ou should have infor!ation about what tools you are using to !anage your testing activities. 8ou should have infor!ation on the configuration !anage!ent for test artifacts% test case !anage!ent tool% defect tracking syste!% tools for auto!ation etc. $deally% test auto!ation should be treated as separate proEect and you should have brief infor!ation here along with the link to auto!ation plan. %8ec7tion an1 epo-ting4 $n this section you should have infor!ation on how e'ecution will be !anaged for the various testing activities. ?hat kind of reports you are planning to generate fro! the data that you gather fro! test activities. Ahis should have infor!ation on the various !atri'es and how they should be interpreted. elease C-ite-ia4 Ahis should clearly state release criteria for the product. Criteria defined here should be clear and !easurable. 6or e'a!ple instead of saying product should be stable% you can say Go 41 defect should be reported for at9least two weeks% Go regression defect sho