The TopClass Blog

Have you ever wondered why your LMS software works as well as it does? How it traveled from a bunch of developers’ brains to your computer screen? No? Never? Oh dear, some LMS developers I know in Dublin just died a little bit inside. But I’m sure now that you’re thinking about it, you are curious about what goes on behind the scenes with your LMS software.

Your TopClass LMS software doesn’t just come “out of the box.” You may have thought, “The code is already written and the software is already developed, isn’t it?” Well, yes and no.

Our developers work on coding during your LMS project so TopClass meets all of your association’s requirements and expectations. For example, our developers, business analyst and/or project manager work with your association to clarify requirements, approve design layouts, and address integration or customization workflows.

Another group working their magic behind the scenes is the Quality Assurance (QA) testing team. They’re the second set of eyes that ensures your LMS software is truly TopClass. Let’s look at some of the responsibilities of LMS developers and QA testers during an implementation project.

Setting up LMS integrations

During the setting up of standard or customized integrations, our team finds out which software—the LMS, AMS, or other system—will be the system of record for eCommerce, certification, and other processes. We identify the user, role, group, and partition (sub-portal) data that must be transferred between systems. And, we address many other questions that help us refine the software code, for example:

• Do you enroll learners individually, require bulk enrollments, or both?
• What systems—AMS, CRM, website, etc.—require single-sign-on access?

When integrating our LMS with other systems, like an AMS, it’s helpful to work with someone on the association side who has technical expertise about the AMS. Implementation is sped along when we can work with someone on staff or an AMS consultant who can identify and provide us with the technical integration points within the AMS.

Customizing and configuring LMS software

When we write code for our standard TopClass product, we try to ensure it will work for as many associations as possible. But sometimes an association with a unique process wants to customize a workflow instead of changing their workflow to match the standard functionality. In that case, our development team customizes the core code for the association.

Sometimes these customizations end up becoming part of our standard product, because they improve the overall functionality and would be useful for other organizations too.

We also configure the software for every association client—these changes don’t affect the core code but do change how the software looks and works for your association. Some of the changes our developers make include:

• Branding that aligns with your website and style guide, for example, color schemes, custom fonts, and logos
• Terminology that matches what your association regularly uses
• Screen layouts
• Permissions
• User profile data
• User (learner) workflow
• Notifications

Developing an LMS for accessibility

If someone with a disability wants to participate in one of your online learning programs, your LMS shouldn’t stand in the way. We write our code in compliance with WAI-ARIA, which stands for Web Accessibility Initiative – Accessible Rich Internet Applications. This technical specification published by the World Wide Web Consortium (W3C) specifies how to increase the accessibility of web pages. Our use of WAI-ARIA also puts our software in compliance with Section 508, an amendment to the U.S. Workforce Rehabilitation Act, a federal law mandating electronic and information technology developed, procured, maintained, or used by the federal government be accessible to people with disabilities.

The hand off to QA testing

After the development team completes their work, they deploy a release of your LMS software to a QA server where everything, including customizations, is tested. Before we dive into QA testing, let’s take a break with our developers.

Staying sharp

Our developers are always intensely focused on what they’re doing since they deal with many different challenges throughout the day. Another thing I’ve noticed about them: they drink a lot of coffee. They added two coffee machines to our kitchen: a Nespresso and another machine that grinds the beans and even froths the milk. A couple of them subscribe to a monthly coffee service that sends artisanal blends to the office.

Developers are serious about their coffee—and cake. We have a few great bakers in the office so there’s often nice cakes to go along with that fancy coffee.

WBT Systems developers keep their brains fresh and sharp by getting outside or going to the gym at lunch. We’re lucky we’re near St. Stephen’s Green, Iveagh Gardens, Grafton Street, and the Grand Canal. I’ve seen them out walking in one of the parks or by the canal near our Dublin office.

Okay, back to work.

The importance of QA testing

We put every LMS system through QA testing to ensure our technology is as reliable as ever and our client’s objectives and requirements are met. If we didn’t do QA testing, we couldn’t put our stamp of quality on our software.

QA testing also brings a fresh pair of eyes to the project. Our developers test the software as they are developing it, but the QA team goes in and tests the software from start to finish making sure the LMS works per the client’s expectations.

During QA testing, we constantly ask ourselves, “Is this what the client wants and have we met or exceeded their expectations?”

Who’s involved in QA testing

Our QA team works closely with the WBT Systems business analyst, project manager, and developers. The developers help testers understand workflows and functionalities from a technical point of view. The business analyst and project manager work closely with the client so they can help developers and testers understand how the client anticipates using the functionality. This collaboration ensures all scenarios are covered during testing.

Our CTO oversees technical work on all projects to ensure our high quality standards are maintained, but for larger, more complex projects, she also acts as the WBT Systems project manager and participates in QA testing.

How QA testing works

Testing is hardwired into the entire software development cycle. Developers run tests on the code while developing, and again when it’s amalgamated into the product to make sure their work is TopClass - sorry, had to sneak that pun in somewhere. Later, the QA team tests the entire workflow to ensure the new code hasn’t introduced any bugs elsewhere in the platform.

The QA team designs and takes advantage of extensive automated testing commensurate with the very best practices in the field. However, we never forget that people use our software so hands-on testing, verification, and feedback are indispensable to our sign-off process.

The team reads through the association’s requirements document to ensure they fully understand the workflow. Then they create test cases (step-by-step scenarios for each requirement). They work through the different scenarios that could happen, good and bad, to make sure the software works as expected and no errors or issues arise. If they find an issue, it’s tracked in the test case document and sent to a developer to fix. QA goes through many rounds of testing to ensure the association is getting the best system possible.

Besides testing the software against the association’s requirements, the QA team tests many other factors, including:

• Responsive layouts on actual physical devices (mobile, tablet, laptop, wide desktop, etc.) as well as emulators
• Cross-browser compatibility

When the QA team finishes testing the software, we release it to the association for user acceptance testing. We encourage our clients to test the system using real-world scenarios to make sure it works as needed.

We don’t expect development and QA testing to be your cup of tea, but at least now you understand some of what goes on behind the scenes in Dublin—coffee, cake, and coding.