4. Testing

In this project phase, it is important to check the system as a whole to make sure everything works as intended. Verification of individual development tasks should be already part of the developing phase.

Regression testing

When testing the implementation, you should:

  • Investigate and address all issues produced during the testing phase.
    • There are plenty of handful tools you can use for troubleshooting, for example debug etc.
  • Perform all tests in a production-like environment.

Non-functional testing

When running performance, load, and capacity tests, there are several things you need to consider:

  • Define your performance baseline.
    • What are the results of your tests and what is the goal?
  • Depending on the type of tests you would like to perform and what area are you testing (front-end, back-end, environment), select the most suitable testing tool (e.g. loadimpact.com, VS, WCAT).
  • Perform one change at a time and measure the impact of the change when addressing performance issues.
  • Focus on the optimizations or areas that can bring you the most significant results.
  • Perform all tests in a production-like environment.
    • The results of running tests on your local environment won't reflect how the website performs under heavy load on a hosting server. There are multiple variables involved, which may influence the performance, such as network connectivity between web and database server, hardware configuration of the server or file system options (e.g. blob storage) to name a few.
  • Keep the testing environment consistent so that you can compare test results directly.

Functional testing

When testing functionality of your web site, following are some important things to consider:

  • Test all use case scenarios with automated tests.
    • Automated browser testing - SeleniumHQ
    • Unit testing
    • Integration testing
  • Validate website code and accessibility for devices and browsers you are planning to support.
  • Security:
    • Check configuration, user accounts with empty passwords etc. on application level (KInspector).
    • Use 3rd party tools and services to perform penetration testing from the outside (e.g. Ammonite).
  • Scenario: Avoiding site outages

    A client did not spend enough time on testing to determine the right performance tier for their project size, implementation, and traffic. While they were running in Azure with no problems, the performance tier they were running on without issues was discontinued and they were forced to change tiers.

    Since they didn't have performance and load testing, they blindly chose a tier they thought would work, but during peak hours, the web site went down because the selected performance tier was not able to handle the load.

    The client immediately upgraded to a higher performance tier (via Azure management portal), but given the size of the database, the operation took some time and the web site was offline for several hours.

  • Scenario: Use case testing

    A partner didn't collect use cases at the beginning of the project and thus also failed to include testing of use cases into their workflow before delivering the finished website.

    One of the most important features was collecting visitor data for personalization and marketing automation in the later stages of the project. The partner decided to implement custom registration and online forms, which weren't mapping the data fields to contact fields. This meant the collected data wasn't available for Kentico's online marketing features.

    This caused a serious delay in delivering the project to the customer and the project went over the planned budget. If they had identified these use cases up front they would have been able to avoid the delay.

  • Scenario: Security vulnerabilities

    A client's web site started displaying links to malicious websites. The first thought was that there was a severe security issue with the out-of-the-box software.

    This however couldn't be confirmed and during the investigation, it was revealed that the custom code implemented by a solution partner contained a SQL injection vulnerability. The vulnerability was introduced in a custom search filter integration which used where conditions to filter out the search results.

    This where condition was not sanitized for malicious user input. The partner didn't include penetration tests into their project workflow which could have avoided this and other serious issues.