Every month, we release improvements in our product and new functionality to our partners. We separate new (beta) functionality by use of feature flagging. Changes in our software that require or do not require testing:
Updates to features, small improvements and bug fixes. No testing needed.
New features released (flagged). The raise of a flag is communicated in the notes of the preceding release. Testing recommended.
Large updates or (expected) maintenance (back end). Communicated at least 2 weeks up front. Testing recommend as a validating check.
New plugin or integration method released. Implementation and testing needed.
Updates to features, small improvements and bug fixes don't need testing from your end. We have our Quality Assurance team testing these extensively.
Our advice is to test flagged features when we communicate the raise of this flag (in the preceding release). This will give you approximately a month to test the functionality. In case it is not desired to deploy this feature for all users at you institution, please contact us, we can see to leave the specific feature disabled. For each institution we can assign a so called super-user. For the super-user, all beta functionality that is available under feature flag, will be enabled at all times. This way the super-user can test and try out new functionality whenever this is desired. It is also possible to set up assignments for teachers who want to pilot with beta functionality.
When doing large updates or (expected) maintenance, we will communicate this at least 2 weeks up front. In these cases, testing can be done by the technical department as a validating check, preferably in the days after the update/maintenance. Again, these changes are tested extensively by our Quality Assurance team to make sure nothing unaccounted for happens. (Large updates like these don't occur often, approx. once a year.)
When we've build a new plugin and release this plugin to production, two things on your end need to happen. A new LTI connection needs to be established and the plugin needs to be tested. It could also be that instead of releasing a new plugin, we have improved our integration with the LMS. In this case the same steps need to be undertaken: the integration needs to be made and testing needs to be done.
To establish this, please get in touch with our FeedbackFruits contact person and/or follow the steps of LTI / API integration manual to configure the tool or the new integration.
This concludes the Is testing required before a release? article.
If you have any questions or experience a technical issue, please contact our friendly support team by clicking on the blue chat button (Note: support is available 24h every weekday & unavailable on the weekend).
