This page outlines how we implement quality control in relation to changes to the Lawmaker application during the development process and as part of the release process.
Testing during the development process
All new features and bug fixes are implemented by a multi-functional development team operating in an agile manner.
To ensure the quality of those changes, we implement the following steps:
The initial developer working on a feature or bug fix will, at the same time as writing the necessary code, write automated tests (“unit tests”) or modify existing ones, that can be run in future to ensure the feature/fix is still working as intended.
A second developer peer reviews the codes changes made by the first developer and the tests, before they are merged into the development environment.
When a change is merged into the development environment, all existing unit tests are run against the updated version to ensure that they still pass. If they don’t then the change will not be merged.
The new feature or fix is then tested by a QA engineer or another developer in the development environment to ensure it works as expected. A member of the Lawmaker service team tests feature/fix to ensure it meets the original specifications/expectations (this is effectively “user acceptance” of the change within the agile cycle).
If an issue is found at any of these stages, either it is passed back to an earlier stage in the process to be resolved or a separate task is created to resolve the issue.
Testing as part of the release process
Before any significant or minor release, a series of additional testing is carried out to ensure the quality of the release. The aim of this testing is to ensure that all new features and fixes work as expected when integrated together and also that no regressions in existing functionality have been introduced.
It is impossible to completely rule out any possibility of a regression being introduced somewhere but the testing aims to ensure that all business critical paths through the application work as expected and any defect introduced has only a minor impact on users.
So far as possible all issues found during release testing will be rectified before the release but work is prioritised as follows:
if an issue affects a business critical paths then it will be fixed and retested before release,
if it otherwise has a non-minor impact on users or could significantly erode user confidence in the robustness of the Lawmaker service then they will be fixed and retested before release,
if it has a minor impact on users or is a pre-existing issue that is not being introduced by the release then it may be recorded in our issue-tracking system and addressed in a later release.