© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott COMP6325 Advanced Web Technologies Dr. Paul Walcott The University of the West Indies Session 2 – An Introduction to Web-based Testing Summer 2008

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Objectives  In this session the student will: Discuss infamous software error case studies Describe black-box, white-box and gray-box testing Defend testing axioms Analyse testing approaches Plan the testing process Test websites

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Why do we need to test software? (Patton 2006)  Case studies: Disney Lion King, (p. 10) NASA Mars Polar Lander, 1999 (p. 11)

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott What do Testers do? Find bugs as early as possible and get them fixed!

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott What are the characteristics of a good Tester?  They are explorers  They are troubleshooters  They are relentless  They are creative  They are perfectionists  They exercise good judgment  They are tactful and diplomatic  They are persuasive (Patton 2006, p. 21)

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing axioms  It is impossible to test a program completely Large number of inputs & outputs  “Testing is a risk-based exercise (p. 39)” Because you do not test everything  Testing does not reveal that bugs do not exist

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing axioms cont’d  You do not fix all the bugs you find  The software tester tends not to be the most popular members of the project team

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Debate  Create two teams and debate, for and against the following “If you find a lot of bugs that means that there are many more”

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches  Three types of testing approaches are: White box Black box Gray-box Testing

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Black Box Testing (functional testing)  The tester treats the system as a black box Predefined inputs should have predefined outputs

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d White Box Testing (clear box testing)  The tester examines the program code for clues which helps him to test effectively  Static white box testing methods includes: Peer reviews Walkthroughs Inspections

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Gray Box Testing (clear box testing)  Utilises the black-box approach with clues gained from looking at the code (white box). Unlike white box, the full set of code is not examined

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Test to Pass  When a new system has been created, use a minimum set of test to determine whether the system does what it is supposed to In use case analysis this would be the main success scenario

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Test to Fail  This is when you attempt to break the software In use case analysis these will be the extensions

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Test Boundary Conditions  When testing boundaries look for data types Numeric Character Position Quantity Speed Location Size

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Test Boundary Conditions  Consider the following characteristics of these types: First/Last Min/Max Start/Finish Over/Under Empty/Full Shortest/longest, and so on

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Data Entry Testing  Data input boxes should be able to handle: Defaults Empty Blank Null Zero None

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Testing approaches cont’d Data Entry Testing  Data input boxes should be able to handle: Invalid data Wrong data Incorrect data Garbage data

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing  A web page comprises of (Patton 2006, p.212): Text Graphics and photos Hyperlinked text and graphics Rotating advertisements Fields in which users enter data

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d  Treat the website like a black box and test: Test the text (documentation)  Audience  Terminology  Content and subject matter  Correctness Test the hyperlinks Test the graphics  Do they load properly  IS formatting consistent on a browser resize Change size of text

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d Test the forms  Just like testing fields in other software Include boundary conditions testing Test other objects on the page  Flash movies – play, stop, previous, next  Hit counters  Site searches

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d  Treat the website like a gray box Look at the HTML code

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Activity  Select a website and perform black box and gray box testing

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d  Treat the website like a white box. Look at: Dynamic content Database-driven Web pages Programmatically created web pages Server performance and loading  Tools such as Apache’s ab can be used

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Activity  Install the Apache server  Use the ab utility to performance benchmark a web server (located in the bin directory of the Apache installation) ab –n 1000 –c 5  N – number of requests sent  C – the number of concurrent requests

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d Configuration testing  It is important to consider the hardware and software platforms that will be used: Hardware  PC, Mac, and so on Browser software and version Browser plug-ins Browser options  For example, security options – enabling scripts

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d Configuration testing Video resolution and colour depth Text size Internet connection speeds

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d Usability testing There are many things that may be considered in usability testing. These include:  Scrolling text, marquees and constantly running animations  Long scrolling pages  Non-standard link colours  Outdated information

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Website testing cont’d Usability testing  Overly long download times  Lack of navigational support  Orphan pages Purpose of page should be clear and should link back to the home page  Complex web addresses  Using frames For a complementary treatment of usability, look at ses/comp ses/comp3210

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Test Planning  The purpose of a test plan is: To prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan. IEEE Standard for Software Test Documentation

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Test Requirements  A test requirement identifies what needs to be tested Each test requirement has one or more test cases

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Test Cases  A Test case comprise of a: Pre-condition Test Post condition  For further information on testing see (Patton 2006)

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott Conclusion  In this session The importance of testing was emphasised Testing axioms were presented Different approaches to testing analysed, and Methods of testing websites were detailed

© 2008 Dr. Paul Walcott – The University of the West Indies: Cave Hill CampusDr. Paul Walcott References Patton, R., “Software Testing”, Second Edition, Sams Publishing, 2006