Ad hoc testing tips
Govind_Baliga 1200008P2J Comments (14) Visits (13136)
a) Use of special characters in field entries, such as forms & search forms. You will be surprised how some of these characters (~!@
c) Manipulating URLs by using the URL from one session and pasting in another session or changing the values in the URL to gain access to certain use cases that you normally wouldn't be able to do it via UI. A URL that is being used by a non-authorized or unauthenticated user should be handled gracefully without exposing or violating security.
d) Changing the display resolution to different settings and/or changing the browser font size and validating the UI aspects of the site.
e) For once, avoid using the mouse and focus navigating through the site by just using the keyboard. This is mostly done as part of accessibility testing; however, you can validate the tab order and focus on the objects in any given page.
f) Concurrent transactions that do the exact same steps of a given functionality by using 2 separate sessions on different machines. Let's say, if a system requires you to create a group name that is unique; how will it handle if you were to try to create a group with the same name on two separate sessions? Validating to eliminate redundancy or duplicate data caused by concurrent transaction.
g) Attempting to enter & save data that is more than the maximum required rules and/or negative values in fields such as dates, age, etc.
h) Cross-browser testing. What may work on Firefox may not work on Internet Explorer or certain versions of IE. The more coverage we have on variety of browsers/OS, the more chances of finding defects.
i) Change browser settings by deleting all or some cookies that are being used in the current session, and/or deleting browser cache to run regression tests. Session timeouts should also be gracefully handled if the system detects an idle session.
j) Sometimes new versions of the URLs are introduced without retiring the old ones. So it's important that the correct proxy rules are in place to handle redirects from old to new URLs.
k) Saving a form twice for the same action. For example, if you were to register a user on a website after filling the required fields, click on the Register link multiple times and then check the database to see if multiple records get created or just one.
l) Decoupling deleted data from previously associated data. If a user deletes a forum entry, it should not only be deleted from forums, but also be removed from that user's profile (posts), search and other modules that previously utilized that data.
m) Navigating through the workflow and utilizing browser "Back" button to make sure if the user is correctly being navigated to the correct page that the user previously visited.
These are just some of the ad hoc testing techniques that we conduct in order to cover corner-case scenarios & validating if the system indeed handles gracefully. If you have any other ways that you use as part of exploratory testing, please feel free to share.