Leonardho R Sitanggang

LMS B2B Dibimbing

Manual & Automation Testing

​

Education

Leonardho R Sitanggang

S1 Rekayasa Perangkat Lunak, Telkom University (2019- 2023)

LinkedIn: https://www.linkedin.com/in/leonardho-rante-sitanggang/

Overview Project

Working

IT Developer (Full-Time) Jan 2024 - Now

PT. Astragraphia Information Technology, South Jakarta

Freelance Web Development Tutor (Part-Time) Apr 2026 - Now

Jakarta Metropolitan Area

Table Of Content

Problem Statement

05

Requirement & Test Plan

06

Manual Testing

14

Automation Testing (E2E Test)

17

Automation Testing (IntegrationTest)

20

Regression & Compatibility Testing

23

Reporting & Analysis

27

Conclusion & Recommendation

33

LMS B2B Dibimbing is a web-based Learning Management System that helps Dibimbing admins and employees manage bootcamp and course programs. Built with React and Next.js on the frontend and GraphQL as the API layer, testing covers three core modules : Company Dashboard, Class Management, and Announcement Management across both frontend and backend, on desktop across Chrome and Firefox.

Introduction

As a platform handling centralized class and employee data, LMS B2B Dibimbing carries real risk if left inadequately tested: login failures could lock out all users, mismanagement could disrupt class schedules, and weak input validation could corrupt records. Manual testing across multiple browsers is also time-intensive, risking reduced coverage within a limited sprint window.

​

Requirement & Test Plan

Testing scope was defined based on risk analysis per module, prioritized from P1 (Authentication, Class Management) to P4 (Dashboard). The plan combines API Integration Testing, UI E2E Testing, Manual System Testing, Compatibility Testing, and Regression Testing. Entry criteria require a stable staging environment and reviewed test cases; exit criteria require a minimum 90% pass rate with no open Critical/High defects before release. Each test case should also be completed in under 20 seconds.

Scenario & Coverage Area

All testing activities are backed by structured, traceable documentation across dedicated Google Spreadsheets. Test cases and their results are logged with full detail, from Test Case ID and pre-conditions to expected results, execution status, and related defect IDs, giving the team real-time visibility into progress. Security vulnerabilities are tracked separately with severity, risk impact, and verification status, while defects follow a clear lifecycle from New through Assigned, In-Progress, Resolved, and Retesting, closing only once a fix is verified or reopening if it fails.

​

Beyond individual test cases, QA Metrics roll execution data up into a single quality snapshot pass/fail/blocked counts, defect distribution by severity and priority, feeding directly into the Test Closure Report that determines release readiness through a Go/No-Go recommendation. Execution itself runs on a day-by-day schedule tracked in Jira, keeping manual and automation progress, module coverage, and daily case counts visible and up to date throughout the sprint.

Test Strategy

Test Plan: Test Plan - LMS B2B Dibimbing - LeonardhoRS

Manual System Testing forms the foundation of the QA process, validating that every requirement is met and data flows correctly across all integrated components. Executed end-to-end on real devices within the staging environment, it follows documented user behavior — test steps, test data, and expected results — across the Auth, Dashboard, Class, and Announcement modules. Rather than running in isolation, manual testing feeds directly into automation: once a test case is executed, have passed status, and its expected result confirmed, it becomes the verified basis for scripting, ensuring automation is built on triaged behavior rather than assumptions. This testing layers target a minimum 90% pass rate.

Test Approach

System / Manual Testing

API Testing & E2E Testing

Automated coverage is split across two layers that mirror the application's architecture. API Integration Testing, built with Java REST Assured, validates that GraphQL endpoints return correct payloads aligned with both the database and UI-entered data, with each test file mapped to a single query or mutation. UI End-to-End Testing, built with Java Selenium, validates complete user journeys from the browser through to the backend, converting confirmed manual test cases into automated scripts covering both positive and negative flows. Each test case execution have maximum execution time of 20 seconds per test case.

Compatibility Testing keeps functional execution efficient by running every checks on Google Chrome and Mozilla Firefox. All achieved by executing the same Selenium suite in parallel through a CI workflows, eliminating the need to repeat manual testing per browser. Regression Testing closes the loop: triggered automatically through GitHub Actions CI/CD on every code change in the main branch, it ensures new updates don't break existing functionality, catching regressions early and reducing reliance on repeated manual re-testing.

Test Approach

Compatibility & Regression Testing

Executed Rate = (Number of test cases executed/Number of test cases created) x 100

Passed Rate = (Number of test cases passed / Number of test cases executed) x 100

Failed Rate = (Number of test cases failed / Number of test cases executed) x 100

Blocked Rate = (Number of Test cases blocked / Number of test cases executed) x 100

​

Test Metrics

Testing Tools

Other Tools

Manual System Testing validates that all requirements are met and data flows correctly across integrated components. Executed end-to-end on real devices in staging, it covers the Auth, Dashboard, Class, and Announcement modules following documented test steps and data, with results logged in Google Spreadsheet and serving as the baseline before automation.

​

Test Case Example

Test Case: Test Case - LMS B2B Dibimbing - LeonardhoRS

Bug Report Example

Bug Report: Bug Report - LMS B2B Dibimbing - LeonardhoRS

API automation uses Java REST Assured to validate that backend GraphQL responses align with the database and UI-entered data. Each test file covers one query or mutation with multiple scenarios, assertion scripts, and assertion templates for maintainability.

​

Integration Test Guideline

Pre-Condition

• A test case containing an API must already be executed manually and passed without bugs
• The tester can view the GraphQL documentation for the specific operation
• For redundant operations, ensure the Data Integrity concept is implemented
• All test data is gathered in resources/test-data/data.csv and can be accessed by its key

​

Steps

• Create a new class for each operation/API request. One class should contain only one operation, but it may include multiple test cases (positive and negative)
• Prepare and validate test data in the BeforeMethod setup, along with required headers (e.g., sid auth)
• Define test case metadata: each test case must include priority (execution order), test group, and description (TC-ID and TC-Description)
• Prepare parameters and variables within the test case. For enum variables (e.g., type ordering, pagination, column target), define them as hardcoded values in the test case
• Execute the HTTP request using the prepared template
• Validate response data: check every response key’s data type, nullable status, date format, and contained keywords

Integration Test Example

Github Integration Test Codebase: https://github.com/FlazeFy/LeonardhoRS-FinPro-QA-Batch4-Dibimbing/tree/main/src/test/java/test/integration

TC-CLMG-002 : Java Rest Assured Script

API/Integration Test: Class Management Module Suite

UI automation uses Java Selenium WebDriver to validate complete user journeys from the browser through to the backend. Verified manual test cases are converted into automated scripts, covering both positive and negative flows across all modules.

​

E2E Test Guideline

Pre-Condition

• A test case already be executed manually and passed without bugs
• The tester can view the GraphQL documentation (if containing API) for the specific operation
• For redundant operations, ensure the Data Integrity concept is implemented
• All test data is gathered in resources/test-data/data.csv and can be accessed by its key�

​

Steps

• Create a new class for each feature. One class should contain only one feature, but it may include multiple test cases (positive and negative)
• Prepare and validate test data in the BeforeMethod setup also with its pre-condition
• Define test case metadata: each test case must include priority (execution order), test group, and description (TC-ID and TC-Description)
• Each test step must be presented in the test case script
• Locators and methods (user behaviors) are defined in main/java/page or main/java/section
• Assertions are implemented in the test case to validate the behavior of each step or the expected result
• Assertions can also be placed in utility (helper) methods when validating a group of data.

E2E Test Example

Github E2E Test Codebase: https://github.com/FlazeFy/LeonardhoRS-FinPro-QA-Batch4-Dibimbing/tree/main/src/test/java/test/e2e

TC-CLMG-002 : Java Selenium Script

UI/E2E Test: Class Management Tests Suite

Regression & Compatibility Testing

Regression Testing runs largely through GitHub Actions CI/CD on every code change in the main branch, catching regressions faster than manual testing alone. Compatibility Testing runs functional checks both in Chrome and Firefox through the same Selenium suite executed in parallel via a CI workflows.

Regression Test Example

Github Regression Test Codebase: https://github.com/FlazeFy/LeonardhoRS-FinPro-QA-Batch4-Dibimbing/tree/main/.github/workflows

Regression Test : Setup Github Actions for Automate Test Case Execution every new commit

Regression Test Example

Github Regression Test Codebase: https://github.com/FlazeFy/LeonardhoRS-FinPro-QA-Batch4-Dibimbing/tree/main/.github/workflows

Compatibility Test : Setup Github Actions for Automate Test Case Execution runs in multiple cross-browser

Regression Test Example

Github Regression Test Codebase: https://github.com/FlazeFy/LeonardhoRS-FinPro-QA-Batch4-Dibimbing/tree/main/.github/workflows

Regression Test : Setup mailer for auto reporting after a suite finished execute

Reporting & Analysis

Results are documented through Test Case Logging and Sprint Report. Security Vulnerability Reports, and Bug/Defect Logging (following a New → Assigned → Resolved → Retesting → Closed/Reopened flow). QA Metrics summarize execution progress, pass/fail/blocked counts, defect distribution by severity and priority, and overall release readiness.

Priority & Severity

Bug Reporting Flows

After a bug is found, the status is set to New. QA then waits until the developer fixes the bug, after which the test case can be executed again and the status updated to Retesting

Bug Defect

Security Vulnerability

Bug Report Document

Automation Reporting

Aventstack Automation Report

Mailer Reporting After CI

Defect Analysis

Overall Passed Percentage

73.00% from 100 Executed Test Case

Test Closure: Test Closure Report - LMS B2B Dibimbing - LeonardhoRS

Testing across the Authentication, Dashboard, Class Management, and Announcement modules identified 26 defects. 20 High and 6 Medium severity, with none yet resolved. Alongside 3 security vulnerabilities, including one Critical finding where the Announcement Detail page exposes raw database and SQL error details.

​

Most defects trace back to a single recurring pattern: missing input validation on dates, durations, file types, and URLs, concentrated heavily in Class Management. Notably, the Announcement Detail page also exhibits an intermittent system crash (internal server error), occurring inconsistently rather than on every access, which makes it harder to reproduce reliably and raises the risk that it could reach production undetected.

​

With a Critical security exposure, an unresolved intermittent crash, and zero defects resolved at the time of this report, the application is not yet ready for release.

​

The Critical vulnerability (VULN-ANCM-001) and defects should be resolved immediately, as it risks exposing backend structure to any user who manipulates a URL parameter. The P2 defects should follow next, then the remaining validation-related bugs, ideally fixed at a shared backend validation layer rather than field-by-field, since the same gap (accepting empty, zero, past-date, or malformed input) repeats across more than a dozen defects. Once fixes land, a full regression pass is needed to confirm nothing broke and to close out the Test Execution Summary with real pass/fail numbers before sign-off.

​

THANK YOU

THANK YOU FOR YOUR ATTENTION

Attachments

• Test Plan : Test Plan - LMS B2B Dibimbing - LeonardhoRS
• Jira Sprint : https://flazenedu-1783068267561.atlassian.net/jira/software/projects/SCRUM/summary
• Test Case Manual : Test Case - LMS B2B Dibimbing - LeonardhoRS
• Bug Report & Security Vulnerability : Bug Report - LMS B2B Dibimbing - LeonardhoRS
• Automation Test Repository (UI & API Test) : https://github.com/FlazeFy/LeonardhoRS-FinPro-QA-Batch4-Dibimbing
• Test Closure : Test Closure Report - LMS B2B Dibimbing - LeonardhoRS
• Test Evidences : Evidence
• All Document : Finpro-QA-Dibimbing