As mentioned on previous calls and emails, we’re working to stabilize OpenLMIS for a 2.0 release. The team at VillageReach is currently going through a round of testing and bug fixing.
New bugs are being filed every day. Any and all help is appreciated to resolving these. Even if you are unable to contribute coding effort, you may have background or knowledge on a particular issue that can help resolve it. Scan the bugs now and again and add comments.
In the absence of written test scripts, we are following a pattern of testing all create/update operations, as well as executing processes like requisitions and distributions. We’re logging coverage on a simple spreadsheet found on this [
shared dropbox link](https://www.dropbox.com/sh/uadl8m9jbfittow/AADkZ8rgRbL5fCzVrwCybNjGa?dl=0). The folder also contains a testing strategy doc.
WRT to logging bugs: I originally promoted using the JIRA field “Fix Version/s” to indicate the product version where the bug was found. Per JIRA doc , “Fix Version/s” is meant to indicate the version where the fix will be made. The “Affected Version/s” field is the appropriate one to use, indicating the version(s) where the bug is occurring. I will update all open bugs to set Affected Versions == 2.0. Sound okay?
Thanks to those who pointed out this discrepancy.
As we add more versions, knowing where the bug was found is important. Should we make Affected Version required?
Thanks – Rich
Rich Magnuson | email@example.com
Software Development Manager
Village****Reach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
DIRECT: 1.206.639.2253 CELL: 1.425.445.2408 FAX: 1.206.860.6972