Robot Framework
Keyword-driven open-source automation framework. Readable tests for collaboration between developers, testers, and business stakeholders.
Overview
Robot Framework is a generic open-source automation framework developed at Nokia Networks in 2005 and now maintained by the Robot Framework Foundation. It uses a keyword-driven testing approach where tests are written in a tabular format (text files, TSV, or reStructuredText) that reads like natural language. This makes tests accessible to non-technical stakeholders while remaining executable by machines.
Robot Framework is particularly popular in telecommunications, embedded systems, and organisations where business analysts need to review or contribute to test cases. It is not a tool itself but a framework that integrates with Selenium, Appium, REST libraries, and many other tools via its extensive plugin ecosystem.
What it's used for
Robot Framework is the right choice when:
- Business readability is critical: Tests written in plain English that stakeholders can review and approve.
- Embedded or hardware testing: Strong support for testing physical devices, serial ports, and protocols.
- Multi-tool integration needed: One framework that orchestrates Selenium, API tests, database checks, and file operations.
- Telecommunications or industrial systems: Native support for protocols like SSH, Telnet, SNMP, and Modbus.
Pros & Cons
Pros
- Highly readable keyword-driven syntax
- Extensive library ecosystem (Selenium, Appium, REST, SSH, database)
- Free and open source with active community
- Runs on Python/Jython/IronPython — easy to extend
- Great for acceptance test-driven development (ATDD)
Cons
- Not as fast or modern as Playwright/Cypress for web testing
- Tabular syntax can become unwieldy for large suites
- Debugging is harder than in IDE-integrated tools
- Smaller talent pool than Selenium/Playwright
- Web testing relies on SeleniumLibrary — inherits Selenium limitations
Platforms & Integrations
Robot Framework runs on Windows, macOS, and Linux. It requires Python (3.7+). Tests can target web, mobile, API, desktop, and embedded systems depending on installed libraries.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Framework, all standard libraries, community support |
| Robot Framework Foundation | Free membership | Governance, roadmap influence, conference access |
NZ Context
Robot Framework has a niche but loyal following in NZ telecommunications and industrial automation. Spark and Chorus have used Robot Framework for network equipment testing. For web-focused NZ teams, Robot Framework is less common than Playwright or Selenium, but it remains an excellent choice for teams practicing ATDD or testing beyond the browser.
Alternatives
- Cucumber — BDD-focused with Gherkin syntax. Better for behaviour-driven development.
- Gauge — Specification-driven testing with markdown-like syntax.
- Playwright — Modern web automation. Better DX and performance for browser testing.
When to choose Robot Framework
A quick decision guide for NZ teams evaluating keyword-driven test automation options.
| Choose Robot Framework when… | Choose something else when… | Combine with… |
|---|---|---|
| Your test suite must be readable by business analysts or product owners who don't write code | Your team is web-only and ships fast — use Playwright; it's faster, has better debugging, and has a far larger NZ talent pool | Playwright (via Browser Library) for modern Chromium-based web tests where Robot provides the keyword layer |
| You're testing embedded systems, network equipment, or protocols (SSH, SNMP, Modbus, Telnet) alongside web or API layers | Your organisation already has a strong BDD culture — Cucumber with Gherkin gives cleaner Given/When/Then collaboration and better living documentation | RequestsLibrary for REST API tests; DatabaseLibrary for SQL assertions; SSHLibrary for infrastructure checks — all in one suite |
| You need a single orchestration layer that calls web, API, database, and file-system tests in one run and produces a unified HTML report | Your team writes mostly unit and integration tests in Python — pytest is lighter, has better IDE support, and is the natural choice | Allure Report or ReportPortal for richer dashboards; Jenkins or GitHub Actions for CI orchestration |
| You're practising ATDD and want acceptance criteria to live directly inside the test file, visible and editable by the whole team | You need parallel browser execution at scale — Cypress Cloud or Playwright's native parallelism are significantly more mature for that workload | AppiumLibrary for mobile; SeleniumLibrary as a fallback for legacy IE or Safari coverage where Playwright's support is thinner |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I was joining Chorus NZ's network assurance team, where a single regression run must validate both the web provisioning portal and the underlying network equipment via SSH and SNMP
I would…
Standardise on Robot Framework with Browser Library (Playwright-backed) for the portal and SSHLibrary/custom Python keywords for the equipment layer. One suite, one HTML report, and keyword names written in plain English so infrastructure engineers can read test outcomes without decoding code. I would not split this across two tools — the cross-layer assertions (provision a service, then verify the device config changed) are exactly what Robot's orchestration layer handles well.
If…
I was on a QA chapter at Benefits NZ (Benefits NZ), where business analysts define acceptance criteria for benefit eligibility rules and need to sign off on test coverage before each release
I would…
Use Robot Framework's keyword-driven format as a contract between the business and engineering. Test case names become acceptance criteria; the .robot files live in the same Git repo as the code. BAs review pull requests at the test-case level, not the code level. I would set up an internal keyword library — things like "Verify benefit rate for single parent" — so non-programmers can assemble new scenarios without touching Python. The alternative here would be Cucumber, but Robot's built-in HTML reports are richer and easier to share with compliance auditors.
If…
I was leading automation at TechServNZ's managed services division, where test suites span customer web portals, internal REST APIs, and Windows desktop tooling — all maintained by a team of mixed skill levels
I would…
Start with Robot Framework as the orchestration layer and invest heavily in a shared keyword library that junior testers write tests against and senior engineers extend. The critical discipline is keeping keywords at the right altitude — "Login as admin user" not "Click element id=submit". When I hired someone new I would have them write their first test on day two using only existing keywords; if they couldn't, the library needed improvement. I would switch the web layer to Playwright's Browser Library the moment I found SeleniumLibrary's flakiness eating up sprint capacity — that migration is straightforward and worth doing early.
The bottom line: Robot Framework wins when your tests are a communication tool, not just a safety net — if the only people reading your test reports are engineers, you probably don't need it.
Interview questions
Questions you are likely to get if you list Robot Framework on your CV — with what interviewers are really testing for.
Why would you choose Robot Framework over writing tests directly in pytest or unittest?
What they’re really testing: Whether you understand the keyword-driven philosophy and can articulate it to a non-technical audience, or whether you just followed a job spec.
Strong answer covers: The distinction between test-as-code (pytest) and test-as-specification (Robot); how .robot files become a communication layer that business analysts and compliance teams can read; the trade-off — you gain readability and stakeholder buy-in, but lose IDE integration and debugging ease. Mention ATDD or a context where that bridge between business and engineering mattered.
What is the difference between Robot Framework’s SeleniumLibrary and Browser Library, and when would you use each?
What they’re really testing: Whether you have hands-on experience with the web testing ecosystem and are aware that SeleniumLibrary is the legacy path.
Strong answer covers: SeleniumLibrary wraps Selenium WebDriver (slower, requires WebDriver binaries, no auto-wait); Browser Library wraps Playwright (auto-waits, faster, Chromium/Firefox/WebKit support, no WebDriver). For new projects, Browser Library is the modern choice. SeleniumLibrary remains relevant for teams already invested in Selenium infrastructure or needing Internet Explorer coverage. Note that many NZ enterprise environments still have legacy Selenium setups.
You’re joining TeleNZ’s network assurance team. Their existing Robot Framework suite tests both a web provisioning portal and physical network equipment over SSH. How would you approach onboarding and extending that suite?
What they’re really testing: Whether you can navigate a real mixed-layer Robot suite — web plus infrastructure — and understand the keyword abstraction discipline needed to keep it maintainable.
Strong answer covers: Start by reading the existing keyword library before writing a single test; understand which keywords are atomic (low-level SSH commands) versus composite (business-level workflows). Check that keyword names read at a consistent altitude — “Provision broadband service” not “Click button id=submit”. For the SSH layer, confirm SSHLibrary is used and look for any custom Python keyword files. When adding new tests, write at the composite level first and only add new low-level keywords when the library has a genuine gap.
Your Robot Framework tests pass locally but fail intermittently in CI. The failures show “Element not found” errors on the same keywords each time. How do you debug this?
What they’re really testing: Practical debugging skill and whether you know how to extract diagnostic information from Robot’s reporting tools.
Strong answer covers: First, check the Robot HTML report and log.html — Robot produces detailed keyword-level traces that show exactly which step failed and the full element locator used. Compare browser window size in CI (headless, often smaller) vs. local. Look for missing “Wait Until Element Is Visible” calls — the most common cause of this pattern. If using SeleniumLibrary, consider switching the affected keywords to Browser Library which has implicit auto-wait. Add screenshots on failure using the “Capture Page Screenshot” keyword in a Suite Teardown.
How would you structure a Robot Framework suite for a large NZ government agency where different teams own different application areas, and tests need to scale across multiple Jenkins pipelines?
What they’re really testing: Whether you can design a maintainable, team-scalable Robot Framework architecture rather than just writing individual tests.
Strong answer covers: Organise by domain — one top-level resource file per application area (e.g. payments.resource, eligibility.resource) with shared keywords, and separate test suites per team that import only what they need. Use Robot’s “--include” and “--exclude” tag flags so each Jenkins pipeline runs only its own tags. Store the shared keyword library in a common repo and have teams pull it as a dependency. For reporting, aggregate with pabot (parallel Robot executor) and feed results into a ReportPortal or Allure dashboard so leadership gets a cross-suite view without reading individual HTML logs.