Testing high-traffic websites | TestFort

Tough Parts of Testing Web Sites with High-Traffic

You are here

If you are considering on developing a really high-traffic website you will require appropriate QA and Testing, considering huge volumes of people, your potential customers or any other source of oncome that is, will be trying to view your site. And they will be doing it constantly. When we say big, we mean BIG: like a website for an international corporation like Nice or McDonalds, or news portals such as CNN and BBC, etc. I believe every single person in such companies realize why their web presence has to maintain flawless. But few realize how to achieve such results.

Testing such websites is a practice only few may be trusted with considering all the risks and the high stakes. Here are several pitfalls we, from personal experience, know and would wish to point out:

  • Globalization: High-Traffic websites are usually visited from multiple corners of the globe and surely keeping all content in English is a) pointless, b) not friendly, c) harmful to business, even. You will have to support numerous local languages and you will have to test whether everything is OK in this field. Design, code and test your site in such a way it can be localized with ease. This means all your content and products will have to be translated and customized to meet new markets from different regions. This is more than simple functional testing, much more as you will have to verify both globalization and every single requirement foreign markets present.
  • Unit testing: Components that matter to integration must be tested. Functionality AND performance should be unit tested, unlike the times where functionality tests only may be enough. All components that form or are required for performance matters have to be analyzed and tested.
  • Double check on Cross Site Scripting: test for XSS. No HTML or scripts may be accepted by your website or web app. Otherwise you may be hacked or attacked.
  • AJAX: This tech requires really strong or even additional controls. Usually they are asynchronous, bidirectional and complex, and those three make a fine reason to test AJAX harder. More to that matter, AJAX is weak with handling errors, authentication and session management. Also pay attention to these security flaws, when designing test cases:
    • App internals are exposed
    • The possible attack surface is increased, hence more inputs are required to ensure security
    • Third-party resources may access the client and no encoding security mechanisms take place
    • No precise line between server and client-sides

Surely challenges never end here, however these are some of the most vital ones few QA teams are paying enough attention to.