QA Automation Tool
This was an automated validation tool built for the QA team to test the AI & AR Web Platform. Through configurable test flows, the platform validated the embeddable Web SDK's API behavior, UI states, and final AR rendering output.
I was responsible for requirements communication, test flow design, architecture planning, feature implementation, code refactoring, documentation, and later version iterations.
Technical Challenges
1. End-to-End Testing
The main goal of this project was to validate the final AR result produced after a user completed the full operation flow, not just a single API or UI component.
I used Puppeteer to automatically open the browser and execute the full sequence: SDK initialization, test data input, feature operations, and result output. The test flow also checked whether the system displayed the correct error states when an image did not meet the required specifications.
After the operations were completed, the program saved the final AR rendering result for later automated comparison or manual review. Tests could run in headless mode, which allowed them to be integrated into Jenkins and executed automatically in CI environments without a graphical interface.
2. Configurable Test Mechanism
To let the QA team create different test scenarios without modifying code, I organized test inputs into configuration files and fixed-structure input and output folders.
The configuration file included test data, Web SDK version, initialization parameters, and other options required by the test flow. QA could adjust the configuration to switch between versions or parameter combinations, then repeatedly execute the same validation process.
This design also allowed later systems or CI flows to start tests with a consistent data format, reducing tight coupling between test scripts and specific cases.
3. Specific Frame Validation
Some AR features required video input and validation of the rendering result at a specific point in time. However, browser video playback can be affected by decoding speed, event timing, and runtime performance. Relying only on JavaScript to control playback position could not guarantee that every run captured the exact same frame.
To solve this, the project introduced FFmpeg on the Node.js server side to preprocess input videos and convert the specified frames required by the test into stable input data.
The Web SDK also added corresponding handling for automated testing needs, so each test could render from the same visual content and avoid inconsistent results caused by video playback timing differences.
My Contribution
I was the main developer for this project from requirements discussion and architecture design through production implementation. I also continued handling code refactoring, test flow adjustments, and operation documentation maintenance.
This platform transformed AR rendering flows that were previously difficult to reproduce reliably into automated test cases. It allowed the QA team to validate different Web SDK versions with consistent input conditions and compare rendering differences before and after version updates.
Through Puppeteer, Jenkins, and a configurable testing mechanism, the team could repeatedly execute the same cases, reduce differences caused by manual operation, and identify API, UI flow, or AR rendering issues earlier during version iteration.