DEV Community: Weiwen Weng

Stop Using Raw WebDriver in Robot Framework

Weiwen Weng — Thu, 09 Jul 2026 18:14:55 +0000

A lot of Robot Framework projects still look like plain Selenium scripts with .robot file extensions.

Someone imports webdriver, creates driver = webdriver.Chrome(), then calls find_element and send_keys in Python helpers. Robot Framework runs the suite, but readable keywords, shared libraries, and consistent waits never show up in the tests.

If you already use Robot Framework with SeleniumLibrary, you do not need the raw WebDriver API. SeleniumLibrary gives you high-level keywords. The Page Object Model gives you structure. Together they keep tests short and UI changes localized.

We published a small MIT template that shows the layout: rf-seleniumlibrary-pageobject-template. It targets Sauce Demo — clone it, run four tests, fork the folder structure.

What breaks when you mix in raw WebDriver

driver = webdriver.Chrome()
driver.find_element(By.ID, "user-name").send_keys("standard_user")
driver.find_element(By.ID, "password").send_keys("secret_sauce")
driver.find_element(By.ID, "login-button").click()

Fine for a script. Painful in a growing suite.

Locators spread across helpers and test files. Waits become time.sleep(2) in one place and missing in another. You end up maintaining SeleniumLibrary and a parallel WebDriver stack. CI fails on a Tuesday night and you are not sure which path opened the browser.

Before and after

Before	After
`driver.find_element(...).send_keys(...)`	`Login With Valid Credentials ${VALID_USER} ${VALID_PASSWORD}`
Locators in every file	`LoginLocators.USERNAME` in one module
Ad-hoc sleeps	`wait_until_element_is_visible` in `BasePage.click()`
Two browser stacks	One `SeleniumLibrary` instance per suite

Four layers

Layer	Job	Example
Locators	Selectors per screen	`login_locators.py`
BasePage	Shared waits and actions	`click()`, `enter_text()`
Page library	Screen keywords	`LoginPage.login()`
Robot test	Scenario only	`Inventory Should Be Visible`

Folder layout in the repo:

resources/locators/   → selectors
pages/                → Python page libraries
tests/                → thin .robot files

Locators stay in one place

class LoginLocators:
    USERNAME = "id:user-name"
    PASSWORD = "id:password"
    SUBMIT = "id:login-button"

Prefer stable attributes like data-test when the app exposes them.

BasePage owns the waits

def click(self, locator):
    self.seleniumlib.wait_until_element_is_visible(locator)
    self.seleniumlib.click_element(locator)

@property
def seleniumlib(self):
    return BuiltIn().get_library_instance("SeleniumLibrary")

Import SeleniumLibrary once in common.resource. Page objects look up that same instance — no driver argument passed between keywords. If you create driver = webdriver.Chrome() outside SeleniumLibrary, your page keywords will not see that browser.

A thin test

*** Test Cases ***
Valid Login
    Login With Valid Credentials    ${VALID_USER}    ${VALID_PASSWORD}
    Inventory Should Be Visible

No locators. No driver setup. Browser open/close in Test Setup / Test Teardown.

Quick start

git clone https://github.com/gitoza-io/rf-seleniumlibrary-pageobject-template.git
cd rf-seleniumlibrary-pageobject-template
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
robot --pythonpath . --outputdir results tests/

Use --pythonpath . from the repo root so pages.* imports resolve. Four passing tests = layout is wired.

Migrating without a rewrite

Move locators to resources/locators/
Add BasePage with click / enter_text
Wrap login as the first page library
Import SeleniumLibrary once in common.resource
Rewrite one .robot file, delete webdriver imports from its helpers

Repeat screen by screen. Leave the rest alone until you touch that feature.

Playwright and Cypress are valid for greenfield work. Plenty of teams still run RF and SeleniumLibrary in production — for them, dropping find_element for Page Objects is a low-risk upgrade that pays off on the next UI refactor.

Full guide: gitoza.com/blog/robot-framework-seleniumlibrary-page-object-model

Template repo: github.com/gitoza-io/rf-seleniumlibrary-pageobject-template

When Excel Stops Working for Test Case Management

Weiwen Weng — Sun, 05 Jul 2026 13:45:31 +0000

Most teams start with an Excel sheet. One tab per feature, columns for steps and expected results, maybe a status column someone colors green by hand. It is cheap, familiar, and fine for ten cases.

Then the product grows. The sheet does not.

Where the sheet starts to hurt

Excel stores text, not test runs. It does not know what "Pass" means in your release process, who executed a case yesterday, or which build you tested. Run history ends up in another tab, another file, or someone's memory.

File names tell the rest of the story. test-cases-v3-FINAL.xlsx becomes v3-FINAL-John-edits.xlsx on a shared drive. Two people update the same row. Someone sorts a column and IDs no longer match the bug tracker. There is no diff, no reviewer, no clear answer to "who changed step 4 before we shipped."

Meanwhile your app, automated tests, and CI live in Git. Manual cases sit in a file that never rides along with your repo history. When a feature changes, the sheet is usually one sync meeting behind.

Spreadsheets are fine for a one-off checklist. They are a poor system of record once QA is ongoing.

Cases as files in the repo you already have

The usual upgrade path is a cloud TMS. That solves collaboration, but your catalog moves into someone else's database — another login, another export, another place sensitive scenarios live.

A lighter step for many teams is test cases as files in a repository you already control. Each case is a small YAML file: metadata up top, steps and expected results in Markdown below. Git gives you history and review without a separate process. A thin editor on top lets you browse suites, edit cases, and record runs — pass/fail and notes saved as structured files, not colored cells.

That is roughly how Gitoza works. You connect a repo (GitHub, GitLab, or any remote you already use), keep cases on a dedicated branch, and edit from VS Code or Cursor. Testers who do not live in the IDE can use the Desktop app for runs and dashboards. The VS Code extension is free for solo use and open-source projects.

What actually changes

Runs stop living in side tabs. You assign cases, record results, and the history stays next to the cases themselves — on the same branch, versioned with every sync.

When a feature ships, you can see case changes in git commits — who changed what, and when — instead of chasing the latest spreadsheet on a shared drive. Tags, priorities, and links to automation specs are easier to keep consistent when each case is a file, not row 427 in a sheet that someone sorted last Tuesday.

You do not need to rip out Excel tomorrow. If the sheet is fighting you on every release, moving cases into Git is often less painful than another "please use the latest file" email.

More on the file format: Why test cases belong in YAML.

Try it (free VS Code extension): Gitoza on Marketplace

Team / manual testers: Gitoza Desktop

Full post: gitoza.com/blog/excel-test-case-management-alternative

Test Management Compliance: Cloud SaaS vs Local-First

Weiwen Weng — Fri, 03 Jul 2026 16:03:51 +0000

Security sends a forty-question vendor questionnaire. Legal asks whether your test cases contain customer PII or staging screenshots. Procurement forwards next year's per-seat renewal.

The decision is not which UI looks best in a demo. It is whether you can keep sensitive test knowledge off a vendor's cloud — without staffing a server farm.

Test cases are not harmless notes. They hold user stories, credentials in steps, production-like screenshots, and run history. For finance, healthcare, or EU-facing teams, that is operational data — not "just QA."

Cloud SaaS vs local-first at a glance

Question	Cloud SaaS	Local-first (e.g. Gitoza)
Where is the canonical copy?	Vendor cloud DB	Your repo / your storage
Does test data cross vendor boundary?	Yes, by design	No vendor DB; sync via your Git remote or BYO S3
Audit trail	Vendor activity log	Git commit history (author, timestamp, diff)
Typical small-team cost model	Per-seat subscription (hosted data)	Lower per-seat subscription; no hosted TMS DB
Manual tester UX	Web UI	Desktop UI
Exit strategy	Export / API	Files already yours

Planning aid, not legal advice — your security team signs off.

Where cloud TMS friction starts

TestRail, Testmo, Qase, and similar tools store cases in a vendor-operated database. Rollout is fast. Manual testers get web forms without a terminal.

The compliance pitch is usually SOC 2, ISO 27001, and a DPA. That certifies the vendor's operation — not whether your test catalog belongs in their multi-tenant cloud.

Question 12 on a typical security questionnaire: Where is customer data processed? Your cases may include staging screenshots with real-looking records. Meanwhile your cases sit in a US region while your customers are in Frankfurt.

On audit trails: activity logs help, but the system of record is still editable rows. Proving "we tested exactly this before release 4.2" often means trusting vendor retention — not a history your org already controls.

Then there is seat math. Twenty testers at roughly $30–45 per seat per month adds up before renewals. Desktop tools like Gitoza also charge per seat — but you are not paying to host your test catalog in a vendor database.

What about on-prem?

Self-hosted TestRail Server or Jira + Xray behind the firewall can be right at enterprise scale. For a twenty-person QA org without a platform team, six figures all-in is not rare. Many regulated teams end up on cloud SaaS and hope the DPA holds.

Local-first in one paragraph

Local-first keeps the canonical copy in files you control — typically a Git repo — while a desktop app gives manual testers the UI they expect from SaaS.

No vendor database as system of record. You pay a per-seat license for the app — not a recurring fee to store your test catalog in a vendor cloud.

With Gitoza, cases live on a dedicated gitoza branch in a shadow clone; testers do not touch main. Git history is the audit log — every change is a commit with author, timestamp, and diff.

Checklist before you shortlist

Inventory — What sensitive data is in cases and runs today?
Residency — Where must it live? Can US-hosted SaaS meet your contracts?
Canonical copy — If you stop paying, what do you still own without an export project?
History integrity — Can an admin alter past results without a durable trail?
Seat math — Three-year cost at current headcount and +50% growth?
Manual tester path — Can non-engineers run tests without CLI or VPN?
Vendor count — How many new subprocessors does this tool add to annual review?
Migration — Realistic effort to move in and out in one release cycle?

If 2, 3, and 7 are red, cloud SaaS needs a harder look.

Before you pick the dashboard

A vendor's SOC 2 report describes how they run their platform. Your auditor will still ask where your case library lived when release 4.2 shipped — and whether anyone could rewrite that history without leaving a trace.

Those are different questions. Certified cloud TMS vendors serve plenty of regulated customers well. Local-first does not replace legal review or a signed DPA. It just moves custody: the canonical copy sits in your repo, not a vendor row you export at renewal time.

If custody matters in your industry — and for many QA teams it does — answer that on paper before the UI demo wins the room.

Try Gitoza: Desktop download · VS Code extension

Why Manual Test Cases Should Live in YAML

Weiwen Weng — Tue, 30 Jun 2026 18:34:39 +0000

Most teams still treat manual test cases as rows in a SaaS database. That worked when cases were written slowly, reviewed rarely, and automation lived in a separate silo.

It works less well now.

AI can draft cases from screenshots and user stories in minutes. Automation lives next to application code. QA and dev share the same PRs. Auditors ask where test data lives and who changed what.

In that world, test cases are data — and the format you choose matters as much as the tool UI.

The durable direction is tests as code: plain YAML files in version control, with a thin local layer for humans to browse, run, and review. Not because databases are evil, but because git + YAML matches how we already work with code, AI, and compliance.

1. AI is good at YAML — and YAML keeps your data yours

LLMs are unusually good at structured text: YAML front matter plus a Markdown body is a sweet spot. Give the model a schema (title, tags, priority, steps, expected result) and a screenshot or user story, and you get a draft case in one pass.

That matters for more than speed:

Boundary cases — ask the model what you might have missed; it can reason about the scenario, not just paraphrase the story.
Consistency — the same format every time makes batch generation and review predictable.

The deeper point is data ownership. Cases in a vendor DB are convenient until they are not: export limits, API friction, another system to secure, another place sensitive scenarios live. Local YAML in your repo is trivial for AI to read (including Cursor, Copilot, or whatever you use next), diff, and update — without shipping your test catalog to a third party. For many teams, that is a real security and efficiency win — not ideology.

2. Manual YAML beside automation makes coverage measurable

When manual cases and automated tests sit in the same repository, a few things become boring in a good way:

Tag a case automated: true and point params at a Playwright or Selenium path — one file, one id.
Automation coverage is a script or an AI pass away: scan specs, match case ids or titles, flip flags, report gaps.
Automation rate stops being a quarterly spreadsheet exercise.

Example — a manual case linked to a Playwright spec:

---
title: Login with valid credentials
tags: [smoke, auth, playwright]
automated: true
params:
  playwright: tests/auth/login.spec.ts
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

The case filename is the case id. Tags and params give automation a handle without a separate traceability spreadsheet.

3. Git diffs are a review surface, not a workaround

When AI generates cases at volume, git diff is the review UI. You see exactly what changed: new case, edited steps, tag added, automated flipped. PR review works the same as for application code.

Test runs can be YAML too — one file per run, case paths and results inline — so run history is also versioned.

Git's time machine means you can see what you tested three years ago, not what a database happened to retain after a migration.

For QA leads, that is the difference between "we changed the suite" and "here is the diff."

4. Local files, audit trails, and data sovereignty

YAML on disk fits a lot of compliance expectations without extra product features:

Offline / on-prem — no requirement to sync cases or runs to a vendor cloud.
Tamper evidence — commit hashes and (if you use them) GPG-signed commits attach authorship to changes; faking "we always had this test" is harder than editing a row with admin access in a hosted DB.
Data sovereignty — the canonical copy lives in your repo, branch, and backup policy.

A database can be compliant. So can files. The difference is whether compliance is bolted on or native to how the artifact is stored.

5. The UX problem — and why a local renderer matters

The honest drawback: YAML is code. It is precise and diff-friendly; it is not fun to click through for a full-day test run.

That gap is real. It is also why file-based test management tends to ship a local UI that reads and writes the same YAML files on disk. The goal is not "no database anywhere" — it is no hosted database as the system of record. A desktop client may keep a derived SQLite index or shadow clone under local app data for fast search and navigation; that cache is rebuildable from the files and never replaces what is committed in git. A VS Code extension can go further and touch only the workspace files — no separate index at all. Browse suites, edit cases, execute runs; YAML in the repo stays the source of truth.

The workflow that tends to work:

Cases and test runs follow branches — QA reviews case changes in the PR like any other change.
Devs stay in the IDE — open a test repository view, skim cases next to the fix they are working on.
After a bugfix, assign a case to a tester in the same branch and ship case + fix in one PR.

YAML holds the source of truth; the renderer is the lens. Tests as code with a usable surface — not a replacement for thinking about structure.

What I am not claiming

YAML in git is not magic — you still need conventions, CODEOWNERS, and review discipline.
AI-generated cases still need human review — diff-friendly format just makes that cheaper.
This is not "dump TestRail tomorrow" for every org — migration cost and habit matter.

I am claiming that if you want AI-assisted authoring, shared repos with automation, PR-based review, and strong auditability, file-based YAML cases age better than another hosted test database.

Try it

If you want to see this workflow in practice:

Gitoza — the full platform: desktop client, git sync, review workflows, automation pipelines, and dashboards for the whole team.
Gitoza Lite on GitHub — open-source VS Code extension; cases under .gitoza-lite/test/cases/ and runs under .gitoza-lite/test/run/.
Install from the VS Code Marketplace — open a repo, run Gitoza: Open Test Repository, create a project, commit the YAML.

Lite works directly on workspace YAML with no local index. Gitoza Desktop adds sync, dashboards, and a derived SQLite cache under ~/.gitoza/ — still rebuilt from the same files on disk. Both treat YAML in git as the source of truth.