I am on a team that does not use the Articulate products, but we are now tasked with supporting/managing the releases for our content designers. Can anyone share their strategies & best practices around testing releases prior to pushing out the latest version? What is your release cadence? How do you determine what needs to be tested? Do you do any regression testing on basic functionality?
Julie, I will recommend keeping an eye on the version history- https://access.articulate.com/support/article/Rise-Version-History and also the roadmap. However I've noticed bugs get reported directly in this forum by end users very quickly after a release, and staff will respond with updates if it is a confirmed bug causing a regression issue that affects everybody.
Also Rise functions a little different than most saas software. Once you export a course, it becomes a self-contained application. It is no longer connected to the Rise codebase in the cloud that is being updated. So if you have an old course from say 2 years ago, there is no reason to do any further testing on it, as long as it has been exported and deployed to your LMS. But if you had a little text edit today and export that new package, you might consider doing a full QA on the course because its using a different codebase now that 2 years of updates are now part of your updated course.
Another consideration is consistency. If you have 50 courses from 2 years ago, and you made an update today on just one of them, and redeployed to your LMS, this might introduce an improvement that now creates an inconsistency among your other 49 courses. It might be an improved typography treatment (size, line height) or use of the theme color on a particular block. So you might consider a process for redeploying old courses. The one thing to look out for that I've seen on this forum, a very old course from 5-6 years ago might have some content/settings that doesn't play nicely with today's codebase.
2 Replies
Julie, I will recommend keeping an eye on the version history- https://access.articulate.com/support/article/Rise-Version-History and also the roadmap. However I've noticed bugs get reported directly in this forum by end users very quickly after a release, and staff will respond with updates if it is a confirmed bug causing a regression issue that affects everybody.
Also Rise functions a little different than most saas software. Once you export a course, it becomes a self-contained application. It is no longer connected to the Rise codebase in the cloud that is being updated. So if you have an old course from say 2 years ago, there is no reason to do any further testing on it, as long as it has been exported and deployed to your LMS. But if you had a little text edit today and export that new package, you might consider doing a full QA on the course because its using a different codebase now that 2 years of updates are now part of your updated course.
Another consideration is consistency. If you have 50 courses from 2 years ago, and you made an update today on just one of them, and redeployed to your LMS, this might introduce an improvement that now creates an inconsistency among your other 49 courses. It might be an improved typography treatment (size, line height) or use of the theme color on a particular block. So you might consider a process for redeploying old courses. The one thing to look out for that I've seen on this forum, a very old course from 5-6 years ago might have some content/settings that doesn't play nicely with today's codebase.