If you are a Managed Hosting customer, this topic doesn't apply to you.

Blackboard strives to deliver the highest-quality software available. Blackboard product releases go through extensive testing during each phase of development before being made available to the public. To that end, Blackboard has established a set of standards and best practices that stem from industry best practices and our own domain expertise.

However, Blackboard understands that each institution uses our products in unique ways to meet the needs of their teaching and learning environment. Institutions have numerous customizations and integrations, and users prioritize the use of different tools in their courses for many different purposes. Therefore, with each new release, it is essential that you test Blackboard Learn against your institution's unique requirements.

To help with this, Blackboard has created a checklist of recommended items to test when installing or upgrading Blackboard Learn. Whenever possible, you should test these items in a local environment before the release is rolled out into production.

Managed Hosting clients do not need to test certain items mentioned in this topic because Blackboard manages the items for these clients:

Firewall settings
Network topography (some third-party tools might require testing)
Tuning parameters
Patch sets
Load-balanced configuration
Data storage

Testing checklist

Blackboard has provided the following checklist to help you test your institution's environment. This file allows you to track the recommended items to be tested and the results of that testing, as well as add additional items to the list.

The following sections explain in detail exactly what Blackboard recommends that you test after an install or upgrade.

Platform configuration and environment

Blackboard uses a stable, generic lab for development and testing and understands that institutions develop environments specific to their needs. After each upgrade, Blackboard encourages you to test the items that are specific to your institution's environment.

Operating system and database setup specific to the institution

Firewall settings

Managed Hosting clients do not need to test these items.

Firewall settings should be thoroughly checked after an upgrade from both sides of the firewall. Before performing the verification, you need to know which ports to validate. Common ports include:

  • 80/tcp HTTP
  • 443/tcp HTTPS
  • 8080/tcp Tomcat HTTP (internal only)
  • 8443/tcp Tomcat HTTPS (internal only)
  • 8010/tcp Collab Server
  • 8012/tcp Collab Server
  • 1521/tcp Oracle TNS Listener (on database server)
  • 1433/tcp MS SQL Server Listener (on database server)
  • 3389/tcp MS RDP
  • 22/tcp Linux SSH

The following are some access points to validate:

  • Test access to the application from the most common user origination points:
    • External (internet) access
    • Internal (intranet) access
    • DMZ access
    • WiFi access
    • 3G access
    • VPN access
  • Test access to a course for course roles after course backup and restore processes are complete.
  • Test access for critical administrative processes.

Network topography

Although most Managed Hosting clients do not need to test these items, you should test any third-party tools that have access dependencies outside of Managed Hosting. For example, Turnitin.

Checking the network topography ensures that access to applications and system integrations are all functioning properly after an upgrade.

You should test access to major functions of the application for different roles (such as student, instructor, administrator, and command line) from the network locations that are most likely to host application users. Ideally, test one network of each type of access, including:

  • Internal networks
  • External networks
  • WiFi networks
  • 3G/mobile networks
  • VPN networks

Test all third party integrations affected by network topography changes, such as Shibboleth or SIS integration. To learn more, see Shibboleth and Student Information System (SIS).

Tuning parameters

Managed Hosting clients do not need to test these items.

Checking and tuning performance is a key step after an upgrade. To learn more, see the following topics:

The Release Notes for each Blackboard Learn release also include specific performance tuning information.

Patch sets

Managed Hosting clients do not need to test these items.

It is important that your institution keep track of patches that have been applied to your system and that you take the following into account during an upgrade:

  • Keep track of any Blackboard Learn patches that have been installed. To track the issues resolved by these patches and determine which future release permanently resolves the issues that they have patched, search the Known Issues for your release. After upgrading, the patches that were targeted for the release you installed will no longer be necessary, but the issues to be addressed in later releases will need to be patched.
  • When you are ready to upgrade, open a Support ticket to let Blackboard know about your upgrade strategy. Support can give you access to a new patch for the upgraded system or initiate a new patch request for any issues that may not have a patch yet.
  • Certain releases have certified patch sets that clients should apply to their systems after upgrading. These patch sets are critical issues that have been identified by Blackboard and aggregated into one package. These patch sets are made available to you when you upgrade your system.

Load-balanced configurations

Managed Hosting clients do not need to test these items.

Some institutions manage the software and hardware for Blackboard Learn in a load-balanced environment. After an upgrade, test these configurations by doing the following:

  • Be sure that all nodes are up and running.
  • Verify that the same data can be accessed across different application servers or nodes of the load balancer.
  • Verify that users can access all components managed on different application servers.

To learn more about load balancing, see Optional - Set Up Load Balancing for Multiple Application Servers.

Data storage

Managed Hosting clients do not need to test these items.

After an upgrade, check that data storage is accessible and data is being managed properly:

  • Verify that the data storage mount works properly after upgrade (for example, local storage, network storage, and NFS).
  • Test access to data storage from the application and database servers.
  • Validate read, write, snapshot, cloning, archive and restore operations.

Security configuration

After an upgrade, confirm your institution's security settings and verify that any custom configurations have not changed. To learn more, see Security.

  • Verify that the web server uses only high-strength ciphers (TLSv1+).
  • Verify that the SSO provider uses strong policy enforcement such as strong passwords, password reset cycles, and throttling/locking. Ensure this functionality is operational after upgrade.
  • Verify that session timeout values in bb-tasks.xml are set to reasonable levels. The default is up to four hours and should be reduced based on your institution's policy.
  • If your school licenses content management, be sure that persistent cookies are disabled. To learn more, see Persistent Cookies.
  • Verify that session fingerprinting is enabled and enforced. Customers using Blackboard Learn Mobile should only enable, but not enforce, session fingerprinting it because it will cause issues for customers accessing Learn from Mobile. To learn more, see Session Fingerprinting.
  • Verify Guest Access settings at the gateway level, course tools level, default course settings level, and default organization settings level. To do this, access Learn as a guest user or observer user from each of these places and ensure that it is enforced. To learn more, see Guest and Observer Access.
  • Verify Global Cross-site Scripting Security Control is enabled and set to the strictest setting.
  • Verify that roles have the least number of privileges necessary to complete their tasks and responsibilities. For example, not all users need the "Add/edit trusted content with scripts" privilege. If only certain users need the privilege, consider creating a new role, assign only those users to the role, and grant that role the privilege. To learn more, see Course and Organization Roles and System Roles.
  • Verify that load-balanced instances are forwarding the client IP addresses and each application instance is capturing the X-Forwarded-For header. If this does not happen, logs will all show activity as the load balancer IP address significantly reducing your ability to investigate security incidents.
  • Verify that grade history is enabled, cannot be flushed, and cannot be disabled. To learn more, see Default Settings for Courses.
  • Verify that the system is up to date in patching and configuration recommendations by checking Behind the Blackboard for relevant security advisories.
  • If using Release 9.1 SP 8, upgrade to the latest version of Apache™ HTTD Server and thus OpenSSL.

TLS settings

As of Blackboard Learn release 9.1.2001404 TLS is required system wide. Upon upgrade, verify that TLS is enabled. To learn more, see Optional - TLS Configuration.

  • If your institution has different TLS settings, this should be verified upon upgrade.
  • Verify that TLS certificates are installed and use a minimum 2048-bit key. Users should not see a pop-up asking them to accept a certificate that is improper.
  • If your institution uses different certificates for validation, also check these upon upgrade. Verify that the certificate is current and accurate and that content that relies on a certificate, as well as third party applications, is available.

System customizations

Many institutions customize Blackboard Learn, including adding third party tools and customizing Blackboard Learn features. These should all be reviewed upon upgrade.

This section of tests is of particular importance given the HTTP changes introduced in Learn 9.1 April 2014.

Third-party tools

Your institution should test all third party tools that are integrated with your Blackboard Learn system. Examples include collaboration tools and white board tools provided by a third-party vendor. Note that the only third-party tool that Blackboard tests is the basic integration of the Respondus lock-down browser.

  • Verify the availability of the tool within Blackboard Learn. To learn more, see Manage Tools.
  • Verify the availability of the tool to different roles, such as instructors and students.
  • Verify important workflows using these tools.

Building blocks

After an upgrade, it is important to check all Building Blocks used by your institution that are not bundled with Blackboard Learn. (Blackboard tests all Building Blocks that are bundled in the application). Whether these are built on campus or by a third-party vendor, it is critical to test them within your institution's installation.

  • Verify the compatibility with the Blackboard Learn release. This should be verified with the vendor if it is a third-party tool.
  • Verify the availability of the tool within Blackboard Learn.
  • Verify the availability of the tool to different roles, such as instructors and students.
  • Verify important workflows using these tools.

Custom portal pages and modules (Community license only)

If your school licenses community engagement and customizes your modules and portal pages, verify that these appear as intended to your users. To learn more, see Modules and Customizing the Gateway Page.

  • Verify that customizations made to the portal pages and custom modules appear properly to different user roles.
  • Some institutions restrict module tabs to specific roles on campus. Verify that these restrictions are in place and that the correct roles can access them.
  • Some tabs may be set to appear in more than one tab group. In these instances, verify that they appear in all expected places.
  • Verify the behavior and critical workflows of custom modules for the campus or modules deployed from Building Blocks.
  • If your institution has delegated administration of individual modules or groups of modules (using the Domains or Institutional Hierarchy features), verify that the delegated users have proper access to the correct modules.

Customized roles and privileges

Customized roles and privileges enable your institution to have more granular control over the tools and workflows available to users. If your institution uses these, it is important to verify the following after upgrade:

  • While Blackboard tests the roles and privileges feature, your institution can create endless combinations of custom roles and privileges. Test all custom roles and privileges.
  • When verifying the system, perform acceptance testing while logged in as a custom role and verify that the user has the proper privileges.
  • If you are using custom course roles, verify that the enrollment process works properly and that users are enrolled with the right role.

To learn more about managing roles, see:

Customized system appearance

Some institutions customize the brand and theme used to style the Blackboard Learn user interface. Upon upgrade, it is important to verify these customizations to ensure that the application appears properly to users. To learn more, see Brands and Themes.

  • If your institution has developed a custom theme for a previous version of Blackboard Learn, new features introduced in the new service pack will remain un-styled. This may result in rendering problems and, at times, layout issues. This could compromise functionality (for example, if controls are covered). Although minor markup changes to existing styles may occur, these will be strictly cosmetic in nature and should not cause any trouble. If your institution has a custom theme, it important to review the themes, including the color palettes or other CSS modifications, especially for new features.
  • Your institution has the option of creating a custom brand. Verifying these brands follows the same process as custom themes. If the brand uses a custom theme, you should review the theme upon upgrade.
  • Upgrades will include changes and additions to the text in the application. If your institution is using a custom language pack, this could result in missing language keys that are unparsed and result in unreadable long strings. Aside from being unreadable, they are likely to cause layout problems because of to their length. Update and review any custom language packs if your institution uses specific terminology or has installed a language pack provided by a re-seller or partner.

System integrations

System integrations are a critical part of the Blackboard Learn environment, and it is important that they are verified with an upgrade. Part of this verification should include a review with vendors to ensure that the configuration is supported.

  • Student Information System (SIS)
    • Test SIS integration after an upgrade. You should also validate the version and compatibility with the vendor.
  • Snapshot Command Line Tool
    • Test customized snapshot feeds and their file formats.
  • Custom Authentication Types
    • Blackboard tests the API framework, but you should test single sign on authentication and any other custom authentication you may have set up.
    • If you are using a remote authentication provider, ensure that it is functioning properly.
    • If the school has a Guest access policy that does not require a login, make sure this is functioning properly.

Critical features and workflows

Each institution relies on a critical set of features and workflows prioritized against their specific needs. It is important to understand these key processes and policies so they may be validated before an upgrade is rolled out to users. This is essential for course reuse processes that are vital for preparing for a new term.

Course reuse processes

Every institution has a specific set of processes used for managing course packages and reusing them term over term. During an upgrade, it is important to check that these are functioning as expected.

Course and content complexity

Blackboard enables a large number of feature and content customizations to enhance the teaching and learning environment. You should review your institution's customizations and complex content after an upgrade to ensure that it appears and works as expected.

  • Review the configuration of tools at the course level. To learn more, see Tool Availability. For example, check that tools are available in the right contexts to the correct roles.
  • Instructors may set up Adaptive Release rules for content availability. Review these for courses on an upgraded system or when the course package is reused. To learn more, see Controlling the Release of Content.
  • Check rich and complex content built for your institution. This may include embedded web sites and different types of media files.
  • Review content with a life cycle or content that changes over time, such as at the start of semester and at the end of a semester.
  • Check the availability as well as the start and end dates for reused courses. To learn more, see Setting Course Properties.
  • Review course templates and shells that are used to build out courses. These templates may require updates depending on new or enhanced functionality in Blackboard Learn.

Critical features for each role

Each major role at an institution uses a set of tools and workflows that are critical to their tasks. These may be modified and enhanced in a Service Pack, and it is important to review them after an upgrade. It is most beneficial if users in these roles have an opportunity to do acceptance testing themselves to validate their processes and workflows. Roles may include Instructors, Instructional Designers, Students, and Help Desk Support. Examples include:

  • Start of semester and end of semester course activities that administrators perform.
  • Grading activities and workflows for instructors.
  • Password reset or other common helpdesk activities.
  • Content creation and updates by instructional designers.
  • Access to observer tools for parents or others using this role.

Large courses

Some institutions have a set of very large courses with hundreds (or more) of content items or users. Blackboard does performance and scaling testing with every release, but we recommend checking your largest courses by size of course materials as well as your largest courses by number of enrolled users for any issues with viewing content or managing students.

  • In largest course size by content, check course files and multimedia content used within the course.
  • In largest course size by student, check that the course roster and Grade Center appear and function properly.