Planning for Bugs
The jury is still out on the trend towards subscription-based development software. We love the new features and the ability of the software to quickly respond to changes in how browsers handle different types of content.
We hate the bugs.
Given the pace of device, system, and browser upgrades these days, we can't expect any authoring tool to be bug-less. Despite what sales will tell you, no authoring tool is exempt from software bugs, although some do have better online communities and case responders to help you deal with them.
If you are building simple, linear courses, you probably won’t see many bugs. These are usually caught by developers before release. If you are pushing at the limits of what your authoring tool can do or even just using most of the features, bugs can cause budget issues and delays.
We suggest a realistic and proactive approach.
Here are steps we suggest to mitigate issues:
Be sure to include additional testing time when scoping projects.
Don’t wait until the end of the project to do functionality testing.
Have a backup plan when using newer features or complex builds.
Report bugs ASAP.
Let’s talk more about that testing. Play your hosted course on multiple browsers and devices during the development cycle. Don’t wait until your course is complete. Never rely on the in-program preview or review sites alone.
The type of testing you’ll want to do depends on the program you are using and the complexity of your course. For simple courses, just reviewing occasionally in different browsers and devices during development should do. If you are developing for mobile, you probably want to have the mobile version up on a mobile device during development to check as you go. For more complex courses, you’ll want to do a bit of stress testing on your interactions throughout development. You’ll want to test the entire course after each new release.
Finally, it can be frustrating to report an obvious issue only to get the standard, “We can replicate the behavior. It has been logged as a possible bug. We will discuss with our team. . .” response. But in the end, it’s worth the frustration because the faster bugs are reported, the faster they can be fixed.