General Guidance When Testing Your CMS Website

When it comes to building a website, a CMS is a great enabler for a client to have. The ability to control what appears on the site with minimal developer intervention on a regular basis is empowering and can help save money in the long term.

While this is great, how do we go about testing CMS websites? Assuming you aren’t planning to build your CMS from scratch, by leveraging your CMS of choice, you are effectively abstracting away a lot of the content management side of things.

Generally you’d expect the latest stable release of the CMS to handle most of what a user can throw at it, with the obvious faults patched away with hotfixes and newer revisions. This comes with benefits for the development side, too – your team does not have to test this side of things.

Quality Assurance (QA)

However, this raises some questions. What kind of Quality Assurance (QA) do we require on these kinds of projects? Can we write tests for any of this? Recently our team has had some lengthy discussion involving some of our more recent Kentico and Umbraco projects – these are some of my thoughts on the matter.

When it comes to QA, our team is able to perform testing, but they must also play the role of content editor. The client may perform stress testing with more realistic data by the time you reach UAT for your latest sprint worth of features, but the QA team can stress test not necessarily the underlying response of the CMS, but the templates and screens that have been built. Will that heading appear in the specified font? If I create twelve news articles, will they appear in the order I expect them to over on the widget that displays “Latest News”?

What about code tests? First, you may need to accept that if you consider test coverage a useful metric, that you will see a dramatic drop in percentage here. As mentioned previously, most of the files your project has will not need to be tested, or was tested by the developers of the CMS themselves. However, your custom code can still be tested, in much the same way that you might test a completely custom development project.

Takefor example. Your project is in .NET and most of your custom dev will be some form of C# and JavaScript. You might consider separating out your code heavy portions that are not directly linked to a particular page into a side project. That project can be more easily supported with a test project. With the “Kentico.Libraries.Tests” NuGet package, you can write NUnit tests and make sure your custom functionality is working as expected.

Unlike the back-end challenges one might face, front end tools should behave as usual. Your typical testing frameworks like Selenium should still behave as expected. If you’re testing JavaScript with a tool like Jasmine, there shouldn’t be any issues there, either. Your strategies might need to be built around the potential for pages to contain highly customised content, however. In this case, understanding what kinds of inputs a content editor is capable of is important, particularly when dealing with WYSIWYG.

If a content editor can contribute to the HTML structure of a page (or even introduce custom CSS and JS if the situation calls for it), front end tests will need to consider that. If the majority of content is being inserted into the existing HTML and not modifying it, however, a more standard approach might be feasible.

While testing a CMS might seem like a daunting task, there are strategies available for development teams to use. It might not be as simple as the testing available to an ASP.NET application built from scratch, but we can still leverage some control over the work we do on top of our CMS of choice.

If you’d like to discuss a new or ongoing project, we’re here to help. Fill out our simple Contact Us form today and let’s start the conversation.