At the EPiServer meetup in Oslo a few weeks ago, I presented how we work with Quality Assurance in EPiServer CMS 6 projects at Epinova. We always strive for solid craftsmanship through the entire project scope. To achieve this, we have developed and refined a set of frameworks, tools and checklists which define our desired level of technical quality.

With the release of EPiServer 7 we're currently revising the entire system, and we feel it's time to share some of our QA systems with the community, including our complete development checklist for EPiServer 6 projects.

Custom EPiServer project template

All our EPiServer projects start out using the Epinova Visual Studio project template - a custom made, ever-evolving, barebones project containing only what we consider best practise configurations.
Key features include:

Using this template, every project starts off right, quick, and ensures a basic uniformity between projects. It also ensures that the foundations of the project will pass the QA audit.

Epinova Visual Studio project template for EPiServer

Automated Visual Studio tools and CI tests

Some of the audits we perform on our projects are extremely time consuming and inaccurate when done by a human. As part of constantly improving our quality, more and more checkpoints are audited automatically. To achieve this, we are using Continuous Integration systems and custom-built, automated tools integrated with Visual Studio. Developers use these tools during all stages of the project.

Automated Visual Studio tools

Development checklists

Checklists are a big part of the QA system, and they undergo continuous improvement. At Epinova we consider back-end and front-end to be separate specialist disciplines, and we have dedicated checklists for each of them. I've seen a couple of other checklists out there, but we decided to create more detailed lists for internal use. The checklist covered in this blog post is for back-end development only, although we might share the front-end checklist at a later time.

During the development phase, these checklists act as important guidelines. They are NOT quick-fixes to apply in the final stages of a project. We make sure developers know them well and continually use them during coding. Towards the end of every project, we produce two QA reports - one each for back-end and front-end. The reports are based on the checklists, and evaluate the overall technical quality before a site goes live.

Screenshot from a development QA report (in Norwegian)In the report, the auditor marks each checkpoint as Passed, Failed, Not Applicable, or Subject For Discussion. If a checkpoint fails, the auditor adds a comment explaining why. Developers are given a short amount of time to correct errors or debate that particular decision, after which the report is finalized and a QA score is calculated. This stimulates a healthy internal competition to achieve the best scores - finding scape goats is never the focus.

Auditing is not always black and white though. For instance, while I initially expect to find zero TODOs in a completed project, finding a few will not always fail the checkpoint if there is a good explanation. Other issues detected by the auditor may not fit under any of the checkpoints, and are summarized to be debated at the end of the report. We also use the checklists when taking over a project from a third party to uncover potential flaws.

Our strong belief in QA systems comes from experience. Over the years I've seen several EPiServer solutions with high code quality on both back-end and front-end. However, the end product often smells of being created by engineers, for engineers - resulting in a bad user experience and dissatisfied customers. In my opinion, this is one of the most important (and neglected) areas of quality assurance.

An improved user experience for editors is one of the big new features in EPiServer 7, with more focus on details like On Page Editing and highlighting required properties. As details like these have always been covered by our EPiServer 6 checklists, these solutions are already well prepared to take advantage of the new features and prove that focusing on quality and doing things right the first time makes your solutions more viable over time.

The Epinova QA checklist for back-end development

Source code

Configuration files and other configuration

User experience for editors

User experience for administrators

Technical quality





Development environment

Test environment

Production environment


With this brief introduction, we hope to inspire and spark off some constructive debates around QA in EPiServer projects. Perhaps one day, we can join forces and create a collaborative QA system to benefit the entire community?

If you found this useful, have any questions or disagree with some of our views, we'd love to hear your feedback in the comments section.