Software Environments
- James Seabrook
The software environment setup is critical for success, particularly on a large scale enterprise with competing priorities.
Best Practice
The main software environment should be along these lines:
Function | Environment | Explanation of Function | Exists at Indigina |
|---|---|---|---|
Development, eg new feature | Dev | Developers are free to do development as required - experimentation, resolving the requirements | Yes |
Code review | Dev | Code is reviewed by another developer who understands the requirements | Yes |
Regression Testing | Reg | Regression testing is where automated tests are run to check for problems. A report is produced detailing any tests where the data has been changed in a manner inconsistent with pre-development work | Yes |
Quality Assurance Testing | QAT | QAT is for finding bugs and ensuring the testing is correct. There is limited requirement for full business knowledge and work should be driven by specification along with acceptance criteria | No - QA is done in UAT environment |
User Acceptance Testing | UAT | UAT is for determining that what is due to be delivered is exactly what is required. This is completely separate and requires the mindset of a user to ensure that the specification and subsequent development fulfill user requirements | Yes |
Demo System | Demo | Environment for real users to test data in an environment which is a mirror of production | Yes |
Production System | Live | Environment for real users and data | Yes |
Current Indigina Environment
The current Indigina environment contains almost everything which is required. The only thing missing is the QA/UAT separation. This hasn’t been required in the past as the development has been driven by Indigina and having two separate environments would have added relatively little value. However now with competing priorities QA and UAT should be separated in order to allow projects to be tested for quality even if the priority of them is subsequently reduced in favour of other work. In this way they can be kept as separated features within the testing process rather than being consolidated too early. This means subsequent changes can be made without affecting a release.
Important Notes
Increasingly with a bigger customer base there is more demand on the entire company resources. Along with a larger customer base is the possibility that customers change their mind about what they require after the development has started. The development life cycle can be adversely affected by those change requests depending on where the development is in the software life cycle at the time. It is critical that any software developed which has to be altered as a result of customer requirements doesn’t get into the main production code without final sign-off. Separation of QA and UAT will help with that.
Current Process
Every evening all the code which has been developed and code reviewed (in code branches) is put into a QA / UAT release. All code is put in en bloc and reversal of any of the code owing to changes in specification or serious bugs becomes very difficult.
Improvement to Current Process
In order to circumvent this the development branch should be kept separate for as long a time as possible, and only when UAT has been signed off should the branch be closed (merged to the main trunk).
Â