Forum Discussion
What's your pre-publish sanity check?
I'll admit to a ritual that probably looks obsessive from the outside.
When a Storyline course is 'done,' before I publish, I open the trigger panel on every slide that has conditional logic and read the triggers top-to-bottom, out loud, like a script. 'When the user clicks Next... if MenuVisited is True...' It takes 20 minutes on a big course. It's tedious. And it catches things preview never does — a condition checking a variable that isn't set until two slides later, two triggers in an order that only breaks on revisit, a 'jump to slide' firing before the 'set variable' above it.
Preview always walks the happy path. The read-through doesn't.
I'm curious how other people handle this. Do you have a pre-publish ritual — a trigger review, a console check for your JS, a specific click-path you always test? Or do you trust preview and let QA catch the rest?
4 Replies
A few years ago, I wrote this post about Quality Assurance Testing. It provides an overview of what to include in a QA check.
As PhilMayor said, it's important to run through the course forwards and backwards. Lots of errors can pop up if one doesn't plan for what will happen when a user revisits a slide.
Publish, run through forwards and backwards, release when I can get through without an issue, check the console for any errors in my code.
I publish a separate instance as a "self-check" to Review, with the player settings and everything as I would have them in a final version. Then I leave comments for myself. Since those comments show up in Storyline (in the same area as the Trigger panel) I can go slide by slide and fix whatever comment I left for myself.
I like to publish for the web. That lets me go through, aka test, the course on my desktop. With Storyline open at the same time, I can immediately investigate and (hopefully) correct the mistakes. Depending on the issue, I might only re-test the slides in Preview. Or I might republish for the web for additional testing.
