1. Background
Where does testing fit in the overall software development process?
Github ‘issues’ detail the desired improvements we want to make to the software. These are created in two situations a) the global community has decided that there’s a new feature that will be added (e.g. a new report) and b) there’s a bug which has been prioritised to be fixed.
A developer will create a Pull Request (commonly referred to as ‘PR’). This is the code that makes the changes that solves the issue- either by building a new feature, or by fixing the bug.
This Pull Request code needs to be ‘staged’ and tested. This is the process of putting the code into one of the testing websites (called ‘staging websites) and checking that the code works as intended, before the code gets added to the ‘master’ code.
If the Pull Request is having the desired effect and solving the issue then we can ‘merge’ this Pull Request. If not, it will need to go back to step 2, where the developer improves their pull request before it gets tested again.
All of the merged pull requests are collected together into a ‘release’. This contains many pull requests. Before we launch a release we also test the release itself- to check that all of the PRs are interacting together ok.
The release is eventually adopted by all of the OFN instances.
It's also useful to understand the GitHub flow: https://guides.github.com/introduction/flow/
Last updated