OpenET 2 - Eye-Tracking Data Quality & Test Automation
A client capstone combining requirements ownership, Python and browser QA, Docker delivery, and Power BI reporting for traceable eye-tracking data.
Verified 6 September 2026
Test scope & results
Local verification of supplied v1.7 source and the synthetic-data workflow.
- Offline suite
32 passed / 1 skipped
Includes 3 documentation checks. One case requires original client data.
- Browser acceptance
105 passed
35 parameterized cases per engine: Chromium, Firefox, WebKit.
- Synthetic CLI
3 sessions completed
All 28 source files unchanged; HTML, CSV, JSON, and provenance outputs generated.
Verification boundaries
- Original client recordings, physical GP3/Tobii hardware, and Docker execution were outside this recorded test run. Docker deployment is separately supported by my project experience.
- CI workflows are configured; this snapshot does not claim a remote v1.7 CI run or measured code coverage.
- Power BI work is described from project experience; this test snapshot does not include an independent PBIX run.
Summary
Project context
Completed UNSW client capstone extending an existing OpenET prototype into reproducible data-import, quality-control, benchmarking, and reporting workflows.
Problem / goal
Different recording formats, inconsistent timestamps, and conflicting metadata could produce misleading reports. Researchers needed repeatable checks and a clear link from source observations to reported metrics.
My role
Project Owner & Developer, responsible for client coordination, primary implementation, and QA on a UNSW client capstone.
My contributions
- Chaired client and team meetings, clarified ambiguous deliverables in writing, and linked 10 requirements to implementation and verification evidence.
- Used a test-first approach for Python import and data-quality workflows, covering malformed inputs, timestamps, metadata conflicts, sampling gaps, and repeatability.
- Led Codex-assisted Playwright scenario design, log investigation, and responsive CSS fixes; checked browser behavior through screenshots, traces, and regression results.
- Logged a damaged-recording issue in Jira and verified that quality warnings were retained while other sessions continued processing.
- Built Power BI reports from Python CSV outputs, cleaned fields in Power Query, related data by session_id, and checked sampled units, aggregates, and filters against source records.
- Deployed the project with Docker, configured GitHub Actions regression workflows, and delivered demonstrations and setup/import/troubleshooting guides.
Technical approach
- Normalize input formats and time units, check metadata and sampling quality, calculate metrics, and generate HTML, CSV, and JSON reports.
- Use controlled fixtures to distinguish software behavior from physical eye-tracking hardware accuracy.
- The v1.7 report suite checks navigation, keyboard interaction, images, CSV downloads, responsive layouts, and no-JavaScript fallback across three browser engines.
Key features
- Requirement-to-test traceability
- Negative and boundary tests for research data
- Participant-specific repeatability checks
- SHA-256 manifests and auditable diagnostic outputs
- Source-reconciled Power BI reports and client handoff guides
Impact / results
- On 6 September 2026, the offline suite returned 32 passed and 1 skipped; the skipped check requires original client recordings that were not supplied.
- 35 parameterized acceptance cases per browser produced 105 passing executions across Chromium, Firefox, and WebKit.
- A separate synthetic-data CLI run processed 3 sessions with zero pipeline failures and preserved all 28 input-file hashes.
What I learned
- Successful processing and acceptable data quality are different outcomes; reports should make both visible.
- Reproducible fixtures and provenance help explain failures without exposing original research recordings.