QA automation alongside development – how a Lanna editor stays reliable

Moradok Lanna is built by one engineer who is also a QA automation engineer, and that shapes how the work is done. Tests are not a phase at the end: they are written in the same change as the feature, they run against the real site, and every bug that reaches a person becomes a test, so it cannot come back unnoticed. This page explains what is tested, how, and where automation stops.

The principles

• Test the real thing. The suites run against the live site in real browsers, not against mocks. Lanna typing depends on how each browser handles keys, input methods and editable text, and only the real browser tells the truth.
• Never touch real data. Tests carry a secret test key. Anything they create is marked as test data, hidden from visitors, left out of every count and statistic, and kept out of the feedback inbox. Test accounts exist, and are flagged the same way.
• Prove the test catches the bug. A new test for a bug is run against the old version first, and must fail there in exactly the way the person saw it. Only then is the fix released.
• Every bug becomes a test. The suite is the project's memory of what has gone wrong.
• Releases are gated. A release does not ship while any case fails.

What is tested

Two more checks guard things that are not features at all:

• Search visibility. Before and after any change that could affect the dictionary pages, a script reads ten key pages the way a search engine does and compares the title, description, headings, word content, structured data, links and speed with a saved baseline. Any difference fails the change. The dictionary is where most visitors come from, and it must never change by accident.
• Public-safe writing. These developer notes are scanned before every publish for anything that should never be public: server paths, file and table names, network addresses, keys, internal links, internal work codes, product names and versions. Anything found blocks the publish.

Testing an editor that people type into

The Lanna editor is the hardest part to test, because the bugs live between the keyboard and the page.

• Real key events. The suite sends key presses through the browser's debugging protocol, the same path a physical keyboard takes, instead of setting the text directly. A direct-Lanna key, a Space, an Enter and Ctrl+Z all go through the code a person would trigger.
• Input methods. Thai and other languages often arrive through an input method that composes text before committing it. The suite simulates composition (the in-between text, then the commit) to catch text that disappears during it.
• Phones without a phone. Phone screen sizes and touch are emulated to test the on-screen Lanna keyboard, the bottom sheet, and switching between the Lanna keyboard and the phone's own.
• Pixels, not just DOM. For visual work (font size, layout, pictures made from boards) the tests take screenshots and measure computed sizes, because a bug can be correct in the markup and wrong on screen.

Bugs that became tests

Each of these reached a person first. Each is now a permanent case.

Space deleted part of a Lanna word. On a Mac, typing a Lanna word and pressing Space sometimes removed letters. The cause was the operating system's inline prediction replacing text the editor had just written. The fix was for the editor to own the keystroke instead of letting the browser insert it. The test types the same word three times with spaces between, and checks every word survives.

Lanna text grew bigger on every line. Pressing Enter after Lanna text made the browser carry the text's formatting into the new line, so the next line was nested inside it, and each level scaled the font again: 24.8, 38, 60, then 92 pixels. The test repeats the person's steps four times and checks there is no nesting and only one size. It was run on the old version first and failed with the same four sizes.

Undo after picking a word did nothing. Picking a dictionary word is recorded in two steps: inserting it, then locking it as one unit. The lock counted as a separate undo step, so the first undo seemed to do nothing. The fix treats the lock as part of the pick, and a test presses undo once after a pick and expects the word to be gone.

A safety copy that was never written. The new feature that keeps unsaved board edits on the device did not save anything during live editing, because live editing marks text as unsaved a moment after each keystroke. Simulating a lost connection in the test found it before any person did.

Safari, and the limits of automation

Running the core cases in real Safari found something useful about the automation itself. When the test pressed Cmd+Z, Safari handed the shortcut to its own Edit menu, and the page only received the Cmd key; a simulated mouse click could also land on a one-time hint above the toolbar instead of the undo button. The editor was fine — checked by hand step by step — but the test had to press the button directly. Knowing where automation lies is part of the job.

Some things automation on a computer cannot reach at all:

• Phone keyboards. iPhone and Android Thai keyboards, their prediction and their quirks only exist on the phones.
• Operating-system prediction on a real Mac, as in the Space bug above.

For those there are two tools. A typing log can be switched on in the editor: it records which keys arrived and what the editor did, and a person can copy it into a report. And a short guided self-check for phones is on the roadmap, so anyone can test their own device in two minutes and send the result.

What it buys

• Releases without fear. The editor went through more than fifteen releases in three days, each one checked by the full suite in Chrome and Safari before going live.
• Bugs that stay fixed. None of the bugs above has come back.
• A record others can trust. Every release is listed in the changelog, and the number of tests on the home page is the real number.

No software is ever bug-free. If you find something wrong in the site or in these notes, the report button at the end of this page goes straight to the team, and every report is read.