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:
- 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)
- The dashboard is saved with a version number prior to any new developments *
- The Dashboard is tested following the change
- 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
Testing for each change is split into four parts and is intended to ensure data accuracy and functionality:
|
Operational |
Functional |
|
| Standard |
Yes |
Yes |
| Change |
Yes |
Yes |
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.
qlikcentral 