Testing Policy at LCN

Hello to all, the Development Team Leader here. No doubt if you’ve been reading some of Mark’s recent blog posts you know that Auto-renew and express checkout has had a large delay in it’s release. Now that it has been deployed, I thought I would run through the testing procedure that we go through before classifying code as “ready for deployment”.

The first step to any new feature is sitting down as a company and working out exactly what we want from this new feature. While not strictly testing, it ensures that all departments are on the same page when it comes to the new feature. We try to work out as many problems as we can before any development gets started.

While the development team are coding a new feature, we use Behavior Driven Development (BDD) to test the whole code base. BDD relies on a quick feedback cycle and our BDD suite can test the whole code base in a couple of minutes. When we make a change to the code that breaks something, we only want a single BDD test to fail (makes it easier to track down what we’ve broken) and as such, the BDD tests are very focused.

Once all the small bits of the new feature are coded and tested, we need to ensure that all they all mesh together correctly. We use an automated testing platform called Selenium to test that the front end of the site works in multiple browsers. The first step in this, is ‘recording’ some tests. There is a Firefox plug-in for Selenium which records the clicks that you make whilst navigating through a site. Once you have completed the click through, you can save the clicks that you have made and replay them on many different browsers. Selenium helps makes sure that no matter what browser you use, we can be sure that you can do what you need to.

With a full suite of passing Selenium tests, the development team demo the changes to management. We generally get some good feedback from them that we, as developers, usually miss. Most of the time, the changes suggested are quite quick to make and after the changes are made, the site is deployed to an internal demo server. The whole company is notified about the demo server so that they can click through the changes. This last step not only ensures that the majority of the site gets checked in multiple browsers by real users, it also ensures that the support team know about the changes and can walk you through the site when you call up for help.

With everyone in the company now happy with the new feature, we deploy the code to the live servers.