There are many times as a Tester when it is useful to see what is happening behind the scenes when testing a website.
When interacting with a website there may be some logic happening in your browser (client side) and/or server. Information is flowing between the two. It’s this logic and information that’s so crucial to you as a Tester.
The web pages may also use CSS to make the site look and feel the way it does.
When you click on a link or perform an action the client (your browser) sends a request to the webserver, or does some client side logic (like a calculation).
Either way, actions that a user does are causing something to happen behind the scenes. Most users don’t care, but Testers should.
As an example, here is a simple “log on” mapped out with specific actions.
- User: Opens a browser and navigates to the web site by typing in the URL
- Browser: The browser client requests the log on page from the web server
- Server: The server receives the request and responds with the relevant web page.
- Browser: The browser displays the page in the browser to the user
- User: The user fills in the required details (username and password) and hit’s the “log in” button
- Browser: The browser client sends these log in details to the server securely (like username, password, page requests)
- Server: The server checks the credentials and sends a response, often with a new page for the browser to go to, or display.
- Browser: The client takes the command and does some stuff (like loading a page, throwing an error message etc)
This is a simple example for demonstration purposes. Yet even a simple log in generates messages and logic in a number of places.
In more complex examples there could be browser side logic taking place, or the server may be calling out to another web service somewhere too.
It makes sense then to look behind the scenes and understand how your application/site is working and what messages it is sending and receiving.
Mapping out this information will give you a great starting block to explore the system. You can build up a profile, which may include potential test ideas, weaknesses, strengths and potential gaps.
Some things of interest might be:
- Is the data being sent and received correctly?
- Is the layout working as expected?
- Are the response times satisfactory?
- How do timeouts affect the site?
- Are there any errors in the code?
- What happens if I pass in X?
- What happens if I remove X?
- What happens if the message is lost completely?
- Is the site generating lots of traffic for something fairly simple?
There are three core tools I see most seasoned Web Testers relying on.
Charles Proxy is a great tool for sniffing web requests (i.e. watching and potentially intercepting requests.)
One of the most useful features of Charles Proxy is the ability to “Throttle” the bandwidth of the traffic between the client (your browser) and the webserver.
Despite a rather dubious name Fiddler is a must have tool for testers.
In a sense it does the same sorts of actions as Charles Proxy but offers a rich interface and command line to get really technical with requests and responses.
I use the Firefox browser a lot for web testing because of the vast array of extensions available. One of the must have day-to-day extensions is Firebug.
Firebug does loads of things but the main uses for me have been:
- Observing the traffic taking place between client and server
- Alerting me to code and message errors
- Showing me the speeds at which the pages are loading
- Inspecting elements on the web page for automation
- Changing the CSS and seeing how it renders on the page
There is another extension called Fire Cookie that extends Firebug’s capabilities to Cookie management.
Charles Proxy – http://www.charlesproxy.com/
Fiddler – http://fiddler2.com/fiddler2/
Firebug – http://getfirebug.com/
If you want to talk Testing – catch me later this year at EuroSTAR conference.