Change Control and Testing

QlikView development is fast, which in an ever changing business world is of great benefit. Whilst this speed of delivery can be very positive there’s a word of warning. People make mistakes. If you have no testing strategy or version control you mind find yourself with applications that are supplying the wrong information.   Below, I outline a very simple method of version control and testing which has served me well over the years


Basic Principles

Following a requirement to change which can be made either externally via stakeholders or internally within the QlikView development team four basic points are to be followed which intended ensure a history of changes are collated and maintain data integrity:

  1. Logging the change within a central shared document including:
    • When the change was implemented
    • What changed
    • What prompted the change
    • Who made the change (QlikView Developer)
  2.  The dashboard is saved with a version number prior to any new developments *
  3.  The Dashboard is tested following the change
  4.  Changes are communicated to the stakeholders via email or within the dashboard itself.

* – The published dashboard should have no version number in its filename, this ensures saved bookmarks continue to work and there’s less effort required to change scheduled tasks on QMC.



Testing for each change is split into four parts and is intended to ensure data accuracy and functionality:










Operational testing covers data integrity and would include checking row counts and calculations in QlikView match those in the source data

Functional ensures actions performed within the dashboard have the desired effect. For example a button to show options behaves accordingly

Standard testing applies to all changes and is a consistent set of tests regardless of the change being made.

Change testing applies directly to the development being implemented ensuring this behaves as expected.


Example Standard Tests

Completed before each new change release regardless of what has been changed


Operational Functional
The number of rows in the QV Fact tables aggregated by date is identical to those in the source database  The dashboard filters are all populated correctly
The sum of Sales, Value, etc. aggregated by date is identical to those in the source database  The dates reported within the dashboard is as expected
 Navigation / Form Buttons behave as expected


Example Change Tests

For example: New fields have been added to the database. These fields are to be included within the QlikView data and the users need to be able to and values are to be shown within the charts   The example tests below are completed solely for this release and are adapted accordingly; these are used in conjunction with the standard tests.


Operational Functional
New field values sum or count of distinct values is identical to those in the source database Fields are visible within the filter dialog form and behave as expected
Data displayed in the RAG and All Reords are populated, without null values and are identical to the source database Fields are visible within the select columns dialog form and behave as expected. Including in the operation of the Default button for example


For both operational and functional tests completed a simple document containing results, screen shots, notes, etc. to be saved which can be reviewed again if fault occurs which was previously known as tested.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s