Task/document test plan

.github/pull_request_template.md

@@ -0,0 +1,24 @@
+## Proposed Change
+
+Summarise your proposed changes here, including any notes for reviewers.
+
+## Type of change
+
+What types of changes does your code introduce? Tick all that apply.
+
+-   [ ] Bugfix (non-breaking change which fixes an issue)
+-   [ ] New Feature (non-breaking change which adds functionality)
+-   [ ] Breaking Change (fix or feature that would cause existing functionality to not work as expected)
+-   [ ] Documentation-Only Update
+-   [ ] Other  (if none of the other choices apply)
+
+## Checklist
+
+By opening this PR, I confirm that I have:
+
+-   [ ] Ensured that the PR branch is in sync with the target branch (i.e. it is automatically merge-able)
+-   [ ] Created or updated any tests if relevant
+-   [ ] Have validated this change against the [Test Plan](https://github.com/HicServices/RDMP/blob/task/document-test-plan/Documentation/CodeTutorials/TestPlan.md)
+-   [ ] Requested a review by one of the repository maintainers
+-   [ ] Have written new documentation or updated existing documentation to detail any new or updated functionality and how to use it
+-   [ ] Have added an entry into the changelog

Documentation/CodeTutorials/TestPlan.md

@@ -0,0 +1,51 @@
+# RDMP Test Plan
+The RDMP test plan outlines the questions that should be asked of new changes to help ensure the correct changes are being made at the correct time.
+These questions are designed to help highlight any steps in the testing process that may have been missed.
+
+If you are looking to release a new version with this change, please look at the [Release Testing](#release_testing) section below.
+
+## Questions To Ask
+### Does this change add a database migration?
+If the change adds a database migration, ask yourself the following questions:
+* Is the change backwards compatable?
+* Have I tested the change with a fresh install of RDMP?
+* Have I tested the change through the upgrade path with populated data that my change affects?
+* Should this change be included in a patch release? or be part of the next minor release? Or even a major release?
+    * Patch releases contain small improvements and should be usable interchangably with other versions within the same minor version e.g v8.1.4 and v8.1.5
+    * Minor released contain new functionality and should be backwards compatable with other versions in the same major version e.g. v8.1.0 and v8.2.0
+    * Major releases contain changes that are not backwards compatable
+
+### Does this change add new functionality?
+If the change adds new functionality, ask yourself the following questions:
+* Is the functionality usable via the GUI? If no ,why not?
+* Is the functionality usable via the CLI? If no, why not?
+* Has the functionalty been covered via unit tests?
+* Has the functionalty been manually tested?
+    * Has the happy path been tested?
+        * This is the expected path, where users are paying attention and are on their best behaviour
+    * Has the sad path been tested?
+        * This is where the user tries to be as obtuse as possible
+* Does this change do any data processing? If so, check the performance questions below
+
+### Does this change have any impact on performance?
+If the change adds or amends functionality that processes data
+* Is the functionality performant?
+    * Can the space/time complexity of the functions be reduced? 
+* Does the functionality handle large datasets (>1GB) efficiently?
+
+
+### What assumptions have been made?
+* Have any assumptions about how this functionality will be used been made?
+* Have any assumptions about the input data been made? Can these assumptions be extracted out into configuration?
+
+## <a name="release_testing"></a>Release Testing
+The release testing process should be completed once the release is feature complete and no more code changes are due to take place.
+This testing is to ensure that all code changes made during this release play nicely together and have no unintended side effcts.
+It may be useful at this point to revisit each piece of functionality and ensure they work as expected and perform some user acceptance testing on them, in light with the questions above.
+### What's changed?
+* Does the changelog accuratly reflect the pull request changes made?
+* If there are database migrations, are they all correctly sequenced and not overlapping?
+* Does the release work as epxected with a fresh install and via the upgrade path?
+* Is all functionality documented?
+* Are all version numbers bumped correctly?
+* Do all of the managed plugins work with the new release without issues or warnings?