Quality Assurance and Testing Process for PeopleFluent Learning

Overview

At PeopleFluent, we take the quality of our software seriously. PeopleFluent Learning (PFL) is a mature, comprehensive Learning Management System with a deeply capable feature set built over many years. As with any enterprise-scale software platform, no release is entirely free of defects — but our engineering and quality assurance teams follow a rigorous, multi-layered process designed to identify and resolve issues as early as possible, and to ensure that every release meets a high standard of quality before it reaches our customers.

This article describes that process in detail.

Layer 1: Quality at the Ticket Level

Every change to the PeopleFluent Learning codebase — whether a defect fix, a new feature, or technical maintenance — begins with a ticket in our issue tracking system. Quality checks are built into the development workflow from the very first step.

Test Plan

When a feature is scheduled for work by developers, the Q/A team immediately drafts a Test Plan for the new feature.  This is especially true for complex features.  The developers will then reference this plan during their technical design process to ensure all of the requirements are fully covered and edge cases are not missed.

Developer Testing and Automated Test Creation

Before committing any code, the engineer responsible for the ticket is expected to:

  • Test their changes thoroughly in their local development environment using the team's integrated development environment (IDE) and build tooling.
  • Write integration test cases and direct unit test cases to cover the changes made.
  • Run all relevant tests locally to confirm they pass before proceeding.

Static Code Analysis

Engineers use a static code analysis tool directly within their development environment to analyze their code. This tool evaluates changes for security vulnerabilities, code quality, and coding standards. Because the PFL codebase includes mature, long-standing code, findings are reviewed in context: engineers are expected to address issues introduced by their current changes, while pre-existing findings in unmodified portions of a file are tracked separately and addressed as part of ongoing technical maintenance work.

Integration Testing on Feature Branches

When changes are substantial, engineers have the option to run a full integration test suite via our continuous integration (CI) system against their specific development branch before submitting their code for review. This provides an additional layer of validation prior to peer review.

Pull Request Review

All code changes are submitted as a pull request in our source code repository before they can be merged. This review process includes:

  • An initial automated review pass by an AI-assisted code review tool, which surfaces potential issues for engineering consideration.
  • A mandatory review by two human engineers, who must approve the changes before the pull request can be merged.

Engineers use AI-assisted analysis tools to help evaluate any findings raised during this stage. Feedback -- whether from automated tools or human reviewers -- is addressed before the code proceeds. If any step reveals issues, the code is corrected and re-tested before moving forward.

Layer 2: QA Team Review

Once code is merged, it is reviewed by PeopleFluent's dedicated Quality Assurance team, which consists of QA engineers led by a dedicated QA manager.

Each issue ticket includes acceptance criteria — typically authored by the product management team — that define what "done" looks like for a given change. The QA team uses these criteria as a foundation for their testing, and they are experienced at going beyond the stated criteria to probe edge cases, validate user workflows, and ask clarifying questions when necessary.

Any issues identified during this phase are reported, and the code is corrected and re-tested before the ticket is considered complete.

Following verification of the specific fixes or features, the QA team conducts an evaluation to designate critical functions as regression test scenarios, which are subsequently prioritized for QA automation if eligible.

Layer 3: Release-Level Testing

PeopleFluent Learning follows a structured release schedule with two types of releases:

  • Versions — Major and minor releases issued three times per year (e.g., 26.02, 26.06, 26.10).
  • Patches — Targeted fixes released as needed between versions (e.g., 26.02.1, 26.02.2).

Both versions and patches go through a comprehensive release-level testing process before they are made available to customers.

Build Validation

The engineering team runs a CI build process to confirm that the release compiles and builds successfully before any functional testing begins.

Automated UI Testing

Every release — both versions and patches — is subject to a full suite of automated UI tests. This suite provides broad test coverage across PeopleFluent Learning's features. Automated testing always runs in its entirety, regardless of the scope of a given release.

Risk-Based Manual Testing

In addition to automated testing, the QA team maintains a suite of manual test cases covering features of PeopleFluent Learning that require direct interaction with the user interface. The total number of test cases across the application numbers in the hundreds.

Manual tests are applied using a risk-based approach: tests are scoped to features touched by the version or patch, as well as critical functions even if there are no changes to those features. For example, if a release does not include any changes affecting an integration functionality such as Drillster or Zoom, the manual tests for that feature are not executed — allowing the team to focus testing effort where risk is highest.  However, those manual tests for learning, talent, and core system functionality are conducted every version release.

Issue Resolution and Prioritization

Issues identified during release testing are reviewed by engineering and product management and prioritized based on criticality. Issues judged to be significant are resolved before the release proceeds. Lower-priority items are documented and added to the product backlog for future attention.

Security Scanning at Version Releases

For each major and minor version release, the engineering team performs comprehensive security reviews, including:

  • A full static code analysis scan of the entire codebase.
  • A third-party security scan to identify additional vulnerabilities.

In addition, automated dependency vulnerability scanning runs on a continuous basis, providing ongoing security awareness between releases.

Our Commitment to Quality

PeopleFluent Learning is a powerful and feature-rich platform, and our QA process reflects the depth of investment we make in maintaining its quality. From the moment an engineer begins work on a ticket to the final validation of a release, multiple layers of automated testing, peer review, and dedicated QA oversight work together to protect the integrity of the product.

We understand that encountering a defect — particularly in a feature that is important to your organization — can affect your confidence in the platform. Our team is committed to continuous improvement, and the process described here reflects our ongoing efforts to deliver a reliable, high-quality product to every customer.

 

For questions about a specific issue or defect, please contact PeopleFluent Support.


 

Was this article helpful?

0 out of 0 found this helpful