Many testers build small tools to simplify repetitive work. Have you created anything like that? What was the problem, what did your tool do, and how much time did it save you?
2 Likes
I’d be interested to hear if anyone has spun up quick internal tools, or prototypes with the help of AI. 
1 Like
I built a Chrome extension called Q-ARK, which is an all-in-one toolkit for QA engineers. It helps generate stable locators for automation frameworks like Selenium, Playwright, and Cypress, including support for complex structures such as Shadow DOM and iFrames. It also includes JSON Studio ( this will be available next week) for JSON validation, smart JSON comparison, generating JSON paths compatible with Rest Assured, and simple API contract testing. In addition, it provides a built-in accessibility scanner so quick accessibility checks can be performed directly from the browser.
I created Q-ARK because I was constantly switching between multiple tools during testing — one for locators, another for JSON validation , another for API comparison, and separate tools for accessibility checks. Bringing these capabilities into one extension helped streamline my workflow and reduced the time spent jumping between different utilities while testing.
I’ve built two that solve real problems I kept running into — and that anyone in test automation can benefit from:
1. Bill Payment API - Documentation — A full end-to-end business workflow API designed for API automation practice. What makes it different is that it comes with a UI as well — you can perform an operation from the front end and then verify the outcome via the API (or vice versa). This makes it ideal for:
- Building and validating API automation frameworks from scratch
- Practicing real-world scenarios like creating users, processing payments, and checking balances
- Cross-channel testing — combining UI actions with API-level assertions
2. Test Automation Practice Hub — A sample site built specifically for UI automation. It covers a wide variety of element types in one place, so instead of hunting across different websites for a specific dropdown, date picker, or dynamic table, everything is right here. It’s useful for:
- Exploring and handling different UI element types (dropdowns, modals, drag-and-drop, iframes, etc.)
- Scaffolding and smoke-testing a new UI automation framework against a stable, predictable target
- Onboarding new team members who need a safe playground to practice Selenium, Playwright, or Cypress
I created a file dumping tool `fd` a long time ago. It dumps file content in two colums, one showing the hex values, the other one the textual representation.
It was quite simple to build ‘back then’ (way before I started working on/with Unix machines and a log time before I learned anout Unicode).
The problem: Some text files may contain a ‘byte order mark’ (BOM) (details → Byte order mark - Wikipedia ) at the beginning of the file, others don’t and it’s not visible when oepning the file in most applications. Dumping the file as hex code, clearly shows the BOM.
The problem when I started to rewrite it to deal with Unicode (UTF-8 to be specific): There may be more bytes in a string, than characters. In other words, the one-to-one-correlation between number of bytes and number of characters per line was gone, and with it the easy way to display the file content.