Table of Contents
Things We Should Keep Doing
- SPH: Broad regression tests
- SPH: Process: Ticket -> Specs -> Dev -> Test
- SPH: Group/Feature area leads
Things We Should Change
- SPH: When submitting a bug, include scripts or detailed list of procedures, and error messages.
- SPH: Improve test system reliability. Test systems should fail less than once a month.
- Get two machines set up to run the tests
- Schedule maintenance work in advance, if possible
- Start system early enough to be monitored
- Machine should be located on-center, so VPN is not needed
- JJKP: Something keeps causing the script test system to crash when loading results. If this continues, we may need to investigate changing how the reporting code works. (This might be a good idea anyway, it takes a LONG time).
- JJKP: Some Visual Freeze things don't actually need to be in visual freeze.
- Updating destination addresses in GMAT.ini
- Updating TestComplete link tests in GMAT.ini
- Note that if new buttons/links need to be added, these do become Viz Freeze items.
- DJC: When reporting issues:
- If you have a script that shows the issue, always include it even if it seems trivial.
- Avoid "whack a mole" issues, where the developer will fix the presented issue only to see it reopened with a description of "this one is just like the original issue." Reopening once is okay, but if the issue shows signs of being systemic, then change the description to clue the developer in that it is likely systemic, or open a new issue.
- DJC: When partially closing issues:
- Be sure to include text explaining the current status of the issue so that when a developer returns to it, it is clear where things were left. (See for example GMT-2686. I should have noted where things were left, but didn't.)
- SPH: Leverage code from heritage systems
- SPH: Consider using more third party libraries like SPICE or Asset Importer to avoid duplication of solved problems
- SPH: Spreading ourselves too thin. Don't do more projects and improvements than we can do well.