Product Quality Assurance Policies at Digizuite

The following outlines the processes at Digizuite addressing quality assurance during the product development and release.

1. All new software is based on a task or issue ticket logged in the backlog. No code is checking with-out link to a ticket.

2. All code changes are reviewed by a peer before check-in. The so-called “pull requests” are mandatory.

3. Developers write unit tests and automated UI tests before code is checked-in. Availability, coverage, applicability are all part of the peer review.

4. QA Phase One - Internal Testing: all tasks go through a quality test performed by R&D’s internal QA team. Issues are logged as defects.

5. QA Phase Two - Regression Testing: to ensure that that there are no side-effects of a change then a regression test is performed by a combination of running all automated tests and performing a suit of manual tests. Issues are logged as defects.

6. QA Phase Four - Factory Acceptance Testing (FAT): before a release the product is handed over to the service department where an acceptance tests is performed by the consultants on behalf of the customers. Issues are logged as defects.

7. QA Phase Five - Load and Performance Testing: before the final release the performance of the new version is tested against a standard set of typical use cases where it is ensured that

   1. the performance of the system is on par or better than the previous released version, and

   2. the new release does not break under a load which is higher than what it can handle.

8. UAT: All new versions are first installed on the customers test environment where the customer performs a final user acceptance test (UAT) with their own configuration.

Besides the above the security of all new releases is validated. See security policy.