BLOG

20 Days Of Web Testing > Back to the beginning again

Why?

The security of an application/site doesn’t just concern the usual suspects of cross-site scripting, SQL injections and man in the middle attacks.

Something as simple as hitting the back arrow on a browser and seeing the previous persons information is a low key but effective security breach.

Say for example that you are in an Internet Cafe and you log in to your banking application. You log out, but leave the browser window open on the home page and you leave the cafe. It *could* be entirely possible that the next person to use the computer can see your details by simply clicking “back” on the browser.

Believe me this does happen.

 

How?

A very simple test would be to authenticate and enter your application. Then log out and hit the back button on the browser to see what happens.

Browsers often offer the ability to skip back a number of pages in one go. Try this and see what pages you can open.

 

Here are some examples of how this bug could cause problems:

  • You might be able to vote online for a candidate or topic. Then hit back and vote again. And again. And again. And again. And again.
  • You might be able to use a “one time only” coupon to discount a price over and over again by using the back button.
  • You might be able to see someone else’s personal data by going back through their browsing session.
  • You might be using a site where some client side JavaScript fires on page load even if the authentication fails. So although you have logged out, when the page reloads (and doesn’t let you back in) it might still fire some logic to perform an action.

 

Useful Hint

Holding down the back button often gives you a list of several previous pages to visit.

 

Useful Links

Stack Overflow question on disabling back capability (which you cannot by the way) – http://stackoverflow.com/questions/7816195/how-to-disable-back-button-in-browser-when-user-logout-in-classic-asp

IE security problem with the Back Button – http://www.wired.com/science/discoveries/news/2002/04/51899?currentPage=all

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Change the URL

Why?

A good test to run to find sneaky authentication bugs is to edit the URL of the site you are on to see if you can get access to stuff you shouldn’t be able to see.

You might also want to change the URL and see if you can alter the data being sent or received.

How?

Bypass Authentication

Firstly it would make sense to understand how the site hangs together and which pages lead to which other pages.

You can then start to build up a profile that will help you organize your thoughts about how to try and trick the application.

So log in to your application and perform some actions, like submitting some details or checking some sensitive data. On each page copy the URL and paste it to notepad (or other tool).

Once you’ve built up a profile and a list of URLs then log out. This should now terminate that session. To make extra sure you might want to clear the cache, delete cookies and re-open the browser.

Now paste in a saved URL and see what happens. As your session is closed you shouldn’t be able to gain access to anything that required authentication (like your sensitive data).

You may also want to try logging in as someone else and pasting in the same URLs. Some of the URLS may contain account/person specific information. Therefore you may need to authenticate to view the URL. See what happens when you are authenticated as someone else.

Can you see another account?

Are you asked to authenticate again?

Any clues as to whose account it is?

Change the URL

Another trick is to look for any information in the URL that could be changed.

For example:

www.thisisanexample.com/banktransfer/rate=12.33

 

An obvious test would be to change the rate value and see what happens. How about making the rate a negative value? What about no value?

At the time of writing this a large global bank is in the news over a basic URL error just like this. The URL shown to a logged in user contains an account ID for the user. By simply changing this number to another number, users were able to gain access to someone else’s bank account. It is such a simple test but so often over-looked. And this was a live issue for a giant bank handling millions of peoples money. It happens.

 

In a sense, the above two test ideas are worthy of a decent Exploratory Testing session or two.

Seek out information, note down what happens, look for clues, work on potential security breach angles, but more than anything, have a go and learn about the potential for URL hijacking.

 

Useful Hint

Using a recording tool like Selenium will give you each of the visited URLs in the script it creates whilst you work through the site.

It’s a good way of picking out the URLs of interest.

 

Useful Links

Selenium – http://seleniumhq.org/

OWASP – Direct Object References attacks 

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

iPads and Testing

We’ve just taken delivery of a couple of iPads for Testing and Development.

Whilst setting them up I wondered what sort of apps and tools other people use on them for their Testing.

At the moment we’ve got them set up for getting stuff on and off them quickly, so they have email accounts each and they share a Dropbox and Evernote account between them. (Some of us use Evernote for ET notes).

We’ve set up autoupload of images to Dropbox (for screenshots) and set up suitable sharing so we can see the notes and files arrive on our machines almost immediately.

There are a few good apps for monitoring systems and applications but I’ve not yet found anything else in the app store that I think would be great for our testing.

What are other people using? Anything?

20 Days Of Web Testing > Automate the tedious

Why?

Sometime the testing of websites/applications can be fairly tedious if you have to constantly navigate to certain points in a form, or create certain sets of data to get to specific pages or configurations to start testing.

In these instances I always find it incredibly useful to create a Selenium IDE (record and playback) UI test or simple SQL scripts to populate the database.

It makes getting to your actual test “point” much easier and quicker.

How?

For Selenium UI tests add Selenium as an extension to Firefox and check out the online documentation on how to get started.

Simply record your navigation through the application and play back as necessary to get to where you need to be.

For example, I was once testing multiple users and cookie management and needed to log out and log in as different users with alarming regularity.

As such I created a simple automated script that would log one user out and then log the other in. This took away a huge amount of tedious button clicking. I wasn’t using Selenium to test the application, but I was using it to automate setup and tedious clicking.

 

Useful Hint(s)

Learning how to debug test scripts in Selenium IDE will make your script generation and playback more effective and quicker.

Apply caution though. If you find yourself building up an automated suite of tests and relying on them for regression then ask if this is really the right approach. Most of the time it won’t be.

You can often use SQL scripts to populate data ready for testing also.

 

Useful Links

SQLYog Tool – http://www.webyog.com/en/downloads.php

SQL Learning at W3 Schools – http://www.w3schools.com/sql/default.asp

Selenium Debugging – http://seleniumhq.org/docs/02_selenium_ide.html#debugging

Selenium – http://seleniumhq.org/

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Disable CSS

Why?

CSS, or Cascading Style Sheets is a mechanism for adding layout and style to a web page. It should be possible to change the CSS and change the whole look and feel of the website, assuming everything within the application has been coded with this in mind.

Yet some people, through either choice or necessity, use browsers that disable the CSS.

It keeps the site simple and ultimately more accessible for many people and tools.

As such it’s important to test the site with CSS removed.

You may be surprised about the flow and order of the site when the CSS is removed.

 

How?

The simplest way I have found is to open the site in Firefox with the web developer add-on installed.

The add-on has an option in the menu to disable CSS. The site will then be rendered with no styling.

You could also use Firebug or a number of other tools.

With the CSS removed you will typically have a very simple looking site, like the one pictured below:

Image of the Social Tester Site with CSS removed

Image of the Social Tester Site with CSS removed

 

With the CSS enabled, it looks like this:

Image of the Social Tester Site with CSS enabled

Image of the Social Tester Site with CSS enabled

Useful Hint

Firebug has a CSS tab which shows you the CSS for the site. What happens when you change some of the CSS markup?

 

Useful Links

W3C standards and advice for CSS – http://www.w3.org/Style/CSS/

Firebug Firefox Extension – http://getfirebug.com/

Web Developer Add-One – https://addons.mozilla.org/en-us/firefox/addon/web-developer/

 
—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Explore the competition

Why?

A great way to generate test ideas, check compliance/claims and to see what systems your users may have previously used is to check out the competition.

Have a look at what your competitor’s products/services offer and bring some of that learning back to your testing.

There are heated discussions in the testing world about whether a tester should “recommend” enhancements or suggestions to the site under test.

My answer is “Yes. Absolutely”.

I think any tester not contributing their knowledge and insight (assuming it’s welcome) to making the product better is missing out on adding great insight.

Testing isn’t about happy path checking, ticking boxes and not stepping off the pre-defined path.

Testing is about adding value, insight, experience and knowledge.

These insights, if they could improve the product, should very much be aired and communicated..

If there is a chance to improve the software, make it more usable, compete in the market place and generally make a more successful product then isn’t that adding value?

Don’t always assume that someone else is checking out the competition or has the customer experience at the front of their mind.

 

Information you glean from comparing products could generate new test ideas, ways to improve features or ways to make your product stand out from the crowd. It’s therefore a good testing technique to aid you.

Matching competitors on a like for like basis is not always a good business strategy though, sometimes going around/under/over them is better.

However, you could start to glean some interesting use cases from their product information or think of your own product in new ways.

It’s also a good way of understanding more about the domain you are working in.

 

How?

A quick Internet search should bring you back some of your competitor’s sites where you should be able to read the marketing material, maybe sign up for a free trial and generally get to know a little more about the product/domain.

 

Useful Hint

You may find your product/site listed on ‘alternative’ sites such as www.alternativeto.net.

Sites like this show you alternatives to products so it might be a good way to see what the competition are doing and what people think of their products.

 

Useful Links

www.alternativeto.net

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Change the locale

Why?

The locale of the browser can play a large part in the rendering of the product and the way that it functions.

It’s a simple test idea that could highlight potential multi-language issues, especially if your site actively supports multiple languages.

 

How?

The process of changing your browser locale is different in each browser but a quick web search should give you the information you need.

 

For example, in Firefox on MAC:

Firefox > Preferences > Content > Languages

 

This will give you a dialogue where you can change the language locale of the browser.

Your browser locale (language) settings will steer your browser to look for “locale specific” content in the sites it loads.

So if your site is intended to be used in English and French markets and will change the language of the landing page(s) depending on the browser locale detected, then try removing all locales and see what happens.

How about adding en-us instead of en-gb – does it still render in English?

You can quickly start to build up a number of tests and further areas to explore.

 

Useful Hint(s)

Try using a Browser Extension to make changing locale easier.

The locale of the browser and the language of the Operating System are two different things.

 

Useful Links

Quick Locale switching extension – https://addons.mozilla.org/en-US/firefox/addon/quick-locale-switcher/

Changing Windows language – http://msdn.microsoft.com/en-us/library/ms144258.aspx

Changing MAC Language – http://support.apple.com/kb/HT2490#l6

 

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Client and server watching

Why?

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?

How?

There are three core tools I see most seasoned Web Testers relying on.

 

Charles Proxy

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.

 

Fiddler

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.

 

Firebug

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

 

Useful Hint

There is another extension called Fire Cookie that extends Firebug’s capabilities to Cookie management.

 

Useful Links

Charles Proxy – http://www.charlesproxy.com/

Fiddler – http://fiddler2.com/fiddler2/

Firebug – http://getfirebug.com/

Firecookie – https://addons.mozilla.org/en-US/firefox/addon/firecookie/

 

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > UX

Why?

UX is becoming a bit of a buzzword recently and is typically associated with usability and design.

In my mind, UX is bigger than that. UX is, as the name suggests, about User Experience.

For me, that’s about the bigger picture and involves more than just the product.

Customer Support, release notes, documentation, supporting docs/sites/help, performance, security, ease of use, usability, accessibility, fit for purpose etc. It’s a big topic.

 

How?

On the surface there are simple things we can think about regarding UX as Testers. Not all of the elements of UX will be applicable to your context but there is no harm in thinking about some or all of the following:

Customer Support

  • Is it available?
  • Do your support team know the details around the product?
  • Is there sufficient support/help available to them?
  • Do they need it?
  • Are the support contact details correct?
  • Is there online help?
  • Is the help correct, accurate and accessible?

Release Notes

  • Are there any release notes?
  • Are they accurate?
  • Are they complete?
  • Are they written for the right audience (too technical, not technical enough)?

Error Tolerant

  • Is the system error tolerant?
  • Are the error messages relevant?
  • Does the system help the user recover from any errors?

Documentation

  • Is it there?
  • Is it needed?
  • Is it accurate?

Performance

  • Is the site performing as per requirements/needs of the customer?
  • Do we even know this information?

Security

  • Is the customer’s data safe?
  • Do they know it is?
  • Are they re-assured that it is safe?
  • Can we prove it is safe?

Usability and Ease of Use

  • Is the product easy to use?
  • Can people find what they want quickly?
  • Is it consistent across all screens/pages?
  • Is it consistent with expectations?
  • Is the site behaviour typical based on other systems/sites/applications?

Accessibility

  • Is the site accessible by people with accessibility requirements?
  • Does it need to be?

Useful Hint

There are a number of resources about design and user behaviour on the web from designers and others working in this exciting domain.

They can offer some amazing insights in to how the design of the product can encourage actions and outcomes.

As a Tester, don’t be afraid to seek out information from sources that aren’t considered “testing” specific.

Useful Links

UX on Wikipedia – http://en.wikipedia.org/wiki/User_experience_design

UX Booth – http://www.uxbooth.com/

UX Mag – http://uxmag.com/

Design with Intent – http://architectures.danlockton.co.uk/

 

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > See the source

Why?

The source of the web page is often a great place to find bugs, areas for further exploration and potential security flaws and leakage of information.

When I talk about the source I am referring to the source code for the page you are testing. The source code is what’s making the page work and as such contains snippets of information about how the application and page is put together.

There could be comments, usernames and passwords, hints referring to methods and implementations that could be useful from a security point of view. There could be rants and raves and loose comments about the company or the customers. There could be joke comments or comments alluding to partially implemented code.

 

There could be secret URLs and credentials in there too.

Image : The Page Source to The Social Tester website shown in Page Source Visualisation Firefox extension

 

How?

When your site is open in your browser click “View” on your browser menu bar and then choose “View Source” (note: This is true for most browser but some may operate differently or call it something other than “View Source”)

The page source will open in a window. Simply reading through it may reveal some interesting areas to explore further.

 

Useful Hint

Right clicking on the web page typically provides you with a context menu to view the page source too.

 

Useful Links

Andréas Prins article on Hidden Treasures – http://www.thetestingplanet.com/2010/12/hidden-treasures-for-everyone/

Firefox Extension to visualise page source – https://addons.mozilla.org/en-US/firefox/addon/view-source-chart/

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Tab order

Why?

There are many people using and operating websites without using the mouse.

If the tab order of the page is not logical then it makes using the keyboard a chore, illogical and in some cases impossible.

Testing tab orders seems like a simple check to do, but always consider the way your page renders, refreshes elements or uses neat tricks to hide content based on selections; these things may all affect the overall order of the tabbing.

 

How?

For example, if you have a form that has 10 questions on it then the tab order should be fairly logical.

When you press the tab button you should move forward through all ten fields in a logical order (typically left to right, top to bottom, but this will vary for each design) often including any buttons or help icons etc.

However, if that same form reveals questions 11 and 12 if the user answers “Yes” to question 2 then ensure that this too is reflected in the tab order.

In some instances questions 11 and 12 may be missing from the tab order.

 

Useful Hint

Hitting SHIFT and TAB will do a reverse tab in most environments. Reverse tab is just as important as forward tab.

 

Useful Links

Tabbing in HTML guidelines – http://www.w3.org/TR/html4/interact/forms.html#h-17.11.1

Web Aim guide to changing tab orders – http://webaim.org/techniques/keyboard/tabindex

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Multiple tabs and windows

Why?

Opening the application in more than one tab or window can often lead to interesting security bugs, data refresh issues or multiple cookie confusion.

An often-overlooked test is the multiple tabs/windows in the same session test.

What you are doing here is essentially seeing how the application copes with the same and/or different user operating under the same session token, but on different pages or tabs.

Many sites use Cookies (a small file stored on your computer) to store session IDs and other supporting data, hence it is often possible to find bugs around confused data, sessions or security access.

This can manifest itself as incorrect data display issues, security loopholes and actions not being performed as expected.

 

How?

Here’s a simple example to seek out security flaws.

 

Open Firefox and in one tab log in to your secure application.

Then right click on a page in your site and open that new page in a new tab.

Both tabs are now considered to be in the same session.

 

Now log out of the application in Tab 2 and try to perform some actions in Tab 1.

 

Has it logged you out or let you perform an action?

In most situations it should have logged you out.

 

In many instances it is possible to log in to two different accounts in the same browser and end up sharing data across both tabs because of cross authentication issues.

 

It’s not just about authentication though.

What about adding things to a shopping basket in multiple tabs – do they persist in the basket?

What about state changes in your application across several tabs?

Can I login across several browsers in different sessions?

Can I trick browser side validation and restrictions by performing actions across a number of tabs?

 

The best way to test in multiple browser tabs and sessions is to explore the application with multiple tabs open, checking what effect a change in one tab can have on the other.

As you explore around look for data, states and actions that might be confused by bad cookie management, session management and cross tab problems.

Always have some developer tools open so you can see what requests and responses are being communicated and what the content of these is. A tool to show your cookies and their contents will be undoubtedly useful too, something like Firecookie (a Firefox extension).

Burpsuite security tool is especially useful if you want to start hijacking the session and manipulating stuff.

 

Useful Hint

In several of the modern tabbed browsers it is possible to open up multiple tabs and then drag a tab out of the main browser “window” to create two ‘Windows” operating under one session. This makes it easier to switch and view the two tabs whilst testing using CTRL and Tab (or CMD and Tab on Mac)

Not all browsers may treat a new “window” as the same session.

 

Useful Links

Good site about cookies and sessions – http://www.allaboutcookies.org/cookies/session-cookies-used-for.html

Session Hijacking – http://en.wikipedia.org/wiki/Session_hijacking

Security implications of cookies – http://it.toolbox.com/blogs/securitymonkey/successful-hacking-with-xss-cookies-session-ids-11098

Burpsuite – http://portswigger.net/burp/

Firecookie – https://addons.mozilla.org/en-us/firefox/addon/firecookie/

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Cross Browser

Why?

There are a growing number of browsers entering the market (including those for tablet and mobile devices) which means your website under test needs to be working well for your supported browsers.

The existing mainstream browsers (Internet Explorer, Firefox, Chrome, Opera, Safari) are also updating themselves very frequently and often without the end user being aware of the update.

This makes testing against this growing number of browsers essential but also increasingly more time consuming.

As with all testing though, ensure you check what is supported and what isn’t by your own product/company. One of the most successful ways to reduce browser testing is to stop supporting older browsers. This is a good strategy for some companies, but not possible for all.

It obviously doesn’t make these old browsers bug free (or even guaranteed to work) but it does mean you can ignore potential problems with these older versions and focus on the version you actively support.

How?

Spread The Risk

One approach could be to run your everyday tests against a mixture of browser environments.

For example, you may be testing a simple web application where the user can log in, generate some reports, send the reports and then log out. The system also has a simple “management” system where sys admins or managers can view who is changing what.

To get a wider coverage you could test your log on functionality in one browser, test the send report functionality in another browser and then the audit trail functionality using a third browser.

This is an effective way of covering different combinations of browsers at the same time as doing your day-to-day testing. The above example won’t highlight a bug with the audit trail functionality in the first and second browser though. So there are plenty of gaps for bugs to slip through, however the time it saves may make this a good option.

 

Let someone else do it

For appearance issues there are many online tools like Browser Shots, which will load your page in any of the supported browsers (they support a great many versions), take a screen shot and then make these screen shots available to you.

This is great for websites, but applications that require credentials or have a huge number of pages are somewhat more difficult. It will also only check for look and feel issues.

 

 

The Browser Shots homepage

 

Check against standards

You could validate your site against an HTML standards checker. Checking against HTML standards will give you more confidence the site works across many browsers, but there are still some browsers that will render pages differently.

A good standards checker is at the W3.org page.

 

Automate

You could automate your checking using something like Selenium, and then use a tool like Selenium Grid to test against several browsers.

This has infrastructure requirements and is obviously reliant on an automation suite existing (or going to be brought in to existence).

It will also only check what you have told it to check.

Automated checks are great for functionality but will not tell you about layout issues between browsers.

 

Fight Layout Bugs

You could write some automated tests to check the layout issues your site may face in different browsers.

Fighting Layout Bugs is an open source Java project providing an automated way of checking for potential layout bugs. As it’s Open Source you can add back to the project.

 

Manually Test It

You could manually test against each version by installing all of the browser versions on different machines. To make this less of a chore it would be worthwhile using Virtual Machines.

These can then be cloned and re-used by others, or centralized somewhere for multiple users to access. This too relies on infrastructure.

It also requires significant time and effort from a Tester, but gives you the human analysis of cross browser compliance.

 

Categorize

You could narrow the browsers down to engines.

Chrome and Safari use WebKit. Firefox uses Gecko. Internet Explorer uses the Trident rendering engine. Opera uses the Presto rendering engine.

You could therefore “assume” that testing on Chrome will cover off Safari. This may be an assumption too far for many though.

 

Emulate it

You could use tools that attempt to emulate the different browsers. There are a number of tools on the market, as well as some inbuilt tools within the browsers themselves to render older versions.

A few words of caution though, they are not wholly accurate in my experience, but they *may* provide insights that are useful.

 

Outsource Selenium

If you have a suite of Selenium tests but do not have the infrastructure or experience in house to get a grid up and running then you might find services like Sauce Labs and Testing Bot quite useful.

 

I’ve not even touched on different operating systems or mobile devices but as you can see there are a number of ways to approach the cross browser issues.

Cross browser support may be your biggest pain-point, especially with the rapid rate of release that most of the browser companies are now adopting.

In my experience a nice selection of a number of the above works well.

 

Useful Hint

Some browsers come with compatibility modes, which allow you to emulate different versions.

Some browsers, like Chrome, have developer tools for rendering pages in different browser and Operating Systems.

 

Useful Links

Compatibility Mode page on Wikipedia – http://en.wikipedia.org/wiki/Compatibility_mode_(software)

IE9 Browser Compatibility article – http://blogs.msdn.com/b/ie/archive/2010/10/19/testing-sites-with-browser-mode-vs-doc-mode.aspx

Sauce Labs – http://saucelabs.com/

Testing Bot – http://testingbot.com/

Browsers and Rendering Engines – http://en.wikipedia.org/wiki/Web_browser_engine

Selenium Grid – http://selenium-grid.seleniumhq.org/

Standards Checker – http://validator.w3.org/

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Http and https

Why?

When transmitting private and confidential data over the Internet it should always be secured and encrypted so that prying eyes on the network cannot see the data being sent.

This mechanism typically uses the https protocol.

 

Hypertext Transfer Protocol Secure (HTTPS) is a widely-used communications protocol for secure communication over a computer network, with especially wide deployment on the Internet. Technically, it is not a protocol in itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. – Wikipedia

 

If you are transmitting data and you are using the http protocol then it is not secure.

Hence, anyone can intercept the message and read the contents. Perfect for a “man in the middle” attack.

And that’s where you, as a Tester, come in.

 

How?

The easiest way to check whether the site you are connected to is secure is to check the browser address bar and look for https.

A padlock to symbolize that the connection is secure will also be shown.

There are a growing number of add-ons, extensions and tools for checking secure connections.

 

If the site is not HTTPS secured then you can use a web proxy tool to intercept the messages between the web client (browser) and the web server.

You can intercept the messages using tools such as Burpsuite (and many others).

Messages can be intercepted in both directions between the web server and the client, and the client and the webserver.

 

Once you have intercepted the messages using a proxy tool you can then do a number of different tests and attacks.

You could extract information from the message and see whether there is anything personal or private in it. It may provide minor clues or snippets of information that could be used for Social Engineering attacks.

You could delete the message and see what happens to the system. Do you lose information, lose states, break the client, break the server, handle it gracefully, or do nothing?

You could forward the message to the server with different values. There are countless examples where the price of goods to be purchased is included in the message unencrypted. A quick change and you could get goods for whatever price you want.

Intercepting messages is not just about security breaches and attacks.

There are loads of examples in most web systems where missing messages can cause grief.

Explore and learn from each test that you do and you will soon build up experience of what works and what doesn’t. I often find that each test leads to new ideas when using proxies to intercept messages.

 

Useful Hint

In many “test environments” https security may not be enabled and configured (but it will be on live) so double check before generating bugs.  Just make sure it’s on when the site goes live.

 

Useful Links

Good security for web checklist – http://www.techrepublic.com/blog/security/ensure-basic-web-site-security-with-this-checklist/424

Differences between http and https – http://www.virtu-software.com/ask-doug/QandA.asp?q=7

Another differences post – http://www.wisegeek.com/what-is-the-difference-between-http-and-https.htm

Burpsuite – http://portswigger.net/burp/

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.

 

20 Days Of Web Testing > Is the HTML valid?

Why?

HTML is the main underlying markup language of websites and other web delivered content.

Poorly constructed HTML can lead to bugs, rendering issues, browser compatibility issues and poor accessibility compliance, so it’s a good area to look for when web testing.

Adherence to standards can also help to ensure your site is future proof too.

There are many sites that don’t adhere to the typical HTML standards including some high profile sites. Reasons for non-compliance to standards are often cited as speed and cross browser support (which is ironic since HTML standards are aimed at ensuring cross browser conformance) but that’s something I’m not digging deeper in to here.

I’m struggling to find a WordPress template that adheres to accessibility and html standards also – I’m working on it 🙂

 

Suffice to say that it would be prudent to run a basic HTML compliance check using one of the many tools available.

It will give you a starting point for discussion anyway, whether your business decide to fix the issues or not.

 

How?

Tools like HTML Validator Firefox extension will help you validate as you test.

There are also several validators online that give you quick feedback on the validity of the HTML under test.

These validators will give you information on what part of the HTML is failing validation and also pointers as to what can done about it.

 

Useful Hint

How about encouraging the programmers on your team to install development IDE compliance checkers if they are available. This is the ultimate early warning against HTML validation errors.

 

Useful Links

Good post on why you should validate – http://www.stevefenton.co.uk/Content/Blog/Date/201108/Blog/Do-I-Need-To-Validate-My-HTML

The W3C validator – http://validator.w3.org/

HTML Validator – https://addons.mozilla.org/en-US/firefox/addon/html-validator/

FireWeasel – https://addons.mozilla.org/en-US/firefox/addon/fireweasel/

—-

If you want to talk Testing – catch me later this year at EuroSTAR conference.