Skip to main content

Import/Export feature for tests

BugBug does not currently have an import/export feature for tests. Exporting and importing tests can be very beneficial for users.

By exporting tests, users can save their work and reuse it in other frameworks. This allows users to benefit from further advanced testing without losing their work. Users can also export multiple tests into a single file, which is compatible with many other frameworks (Selenium, Python). The export feature is especially useful to outgrow the capabilities of BugBug.

In addition, users can import tests from other frameworks into BugBug (Selenium, Python). This allows users to reuse their existing test cases and test suites in BugBug. Users can also import multiple tests into BugBug at once, which saves time and effort.

Status: Completed24 comments

Log in to comment and vote

Comments24

  • Paweł Bylina changed status to Completed
    Team•

    Aug 14

    Pinned

    Feature arrived! :)

    You can now export (and import too!) a single test or the whole project to YAML format!

    This is part of something bigger we are heading to- no vendor lock-in and an open YAML format for e2e testing that will allow non-tech people to modify tests using the UI and more technical people to operate on YAML with an IDE or LLMs (MCP is coooming!).

    Project:

  • Paweł Bylina

    Team•

    Nov 23, 2023

    @Haian Abou-Karam Indeed, BugBug doesn't support export/import yet. But this is a very complex task. BugBug has its own technology under the hood, so we can't just convert tests to open-source format because our runner has a lot of internal techniques to prevent flakiness and similar problems.

    We can add an exporter to e.g. Playwright or Selenium (Java or Python), but after exporting the tests they will not work out of the box for the reasons mentioned above.

    Currently, it will not be possible to run these tests smoothly outside the BugBug infrastructure.

    Importing is an even worse scenario. It's not possible to import tests based only on source code from dynamic languages like Python, JavaScript, TypeScript.

    What's your real case scenario for this feature? I believe this is important to prevent vendor lock problem, but only this?

    • Gizelle

      •

      Sep 19, 2024

      Hi @Paweł Bylina , please do the export/import feature even if for Bugbug only as backup. I have a case where some of the steps of my tests where suddenly gone or accidentally deleted by other user. But if we can create test backups and just reupload it if something happens, that will be beneficial to us. Hope you can consider this. Thank you

      • Paweł Bylina

        Team•

        Sep 19, 2024

        We plan to ship this next year. As a backup today you can copy the whole project.

    • Mike Wright

      •

      Feb 4, 2025

      @Paweł Bylina Would be great to add an exporter in the meantime (while you build out the import/export functionality this year). Playwright would be a good start so we can elevate test automation candidates that manual QA's have created with BugBug. Let me know your thoughts?

      • Mike Wright

        •

        Feb 4, 2025

        Even if the Playwright code needs tweaks to run. It’s still beneficial to have that functionality, a) so its easier to bring into our test automation suite, and b) a nice way for manual QAs to learn the code output of their own tests

        • Paweł Bylina

          Team•

          Feb 4, 2025

          What is the actual workflow? You can find Playwright recorders on the market

          https://playwright.dev/docs/codegen

          If you export tests from BugBug to Playwright, you lose all the platform's benefits, so why do it (unless you want to leave and take your tests with you - which is understandable)? Could you elaborate a bit more on this?

          • Mike Wright

            •

            Feb 4, 2025

            1. We have manual testers that want a platform that help them record/replay/edit regression tests. Especially edit using a UI workflow rather than code. Your platform seems to do this well.

            2. Then with above satisfied, we track test cases (in Jira linked to tests in your platform) and potentially identify + elevate some cases to be included in our test automation suite.

            3. Upon successful elevation/selection, we would need to export the test case from your platform and bring it into our own test automation suite. Which is maintained by SDETs.

              ^ below is also an attempt to try to bring Manual QA & SDETs together to work on a testing through process. Which is a very common problem to be honest.

            • Paweł Bylina

              Team•

              Feb 4, 2025

              OK, I'll explore this topic a bit more ;)

              1. Why do you treat manual QA and SDETs separately?

              2. Why can't SDETs use BugBug too?

              3. What should BugBug be changed to bring SDETs into the platform?

              4. Do you think that having tests in YAML files and being able to modify them in both ways (manual QAs could use UI to change tests, SDETs could change test scripts in their IDE and push changes to Git) would be a good solution?

              • Mike Wright

                •

                Feb 5, 2025

                @Paweł Bylina In reply to your questions:

                1. Cos we have manual QAs with very little technical knowledge (but lots of product / user journey domain knowledge) and we have SDETs who maintain a test automation suite that runs heartbeats/smoke/full regression automation in various environments inc. production. The test automation suite (build with TestCafe/BDD) won’t be going anywhere, so its more about using a platform like BugBug to compliment and enhance the testing that manual testers do (record tests easily, replay etc) with the additional bonus of elevating selected candidates into our automation suite. Its also about trying to create a process to bring the manual testers and SDETs closer together (as a wider, eventual shift left initiative).

                2. No reason why they can’t use it but we’d not want to replace our suite with your platform. And I doubt there would be many SDETS would think this is a good idea from a vendor lock, maintainability, flexibility perspective.

                3. First and most important would be Export tests to Javascript or Typescript (most likely Playwright would be most popular). But would be great to create features to help bridge the gap such as tracking test cases (integration with Jira), identify/elevate test automation candidates, BDD inc. using AI to convert AC to Gherkin and maybe even AI selectors (think ZeroStep).

                4. Hard to say. It depends if the YAML can be used in other platforms so that you’re not vendor locked. I believe this is similar to what Selenium offers in their recorder app but its only really useful for Selenium to Selenium (to save a local backup of the tests or share with a team etc). Tbh, we wouldn’t care about that as a feature unless it could export out to a JS or something we could turn into viable code. Gherkin could also work but that would probably be more difficult than exporting code.

                • Paweł Bylina

                  Team•

                  Feb 5, 2025

                  @Mike Wright Man, thank you for taking the time to answer! I got it, it’s really valuable feedback <3

  • Naveen Basar

    •

    Jan 9, 2024

    @Paweł Bylina As previously requested, it is essential for us to uphold internal backups for all test scripts and cases in accordance with our backup policies. Consequently, having an export feature for all test cases, including screenshots depicting expected results, would greatly facilitate this process. In the event that such an option is unavailable, could you kindly propose an alternative method for exporting these test cases and storing them within our internal backup directories?

    Please note that this requirement is crucial for our business continuity plan. In the event of a system outage or unavailability, having readily accessible test scripts is imperative for conducting tests on our local machines.

  • Haian Abou-Karam

    •

    Jan 10, 2024

    @Paweł Bylina While BugBug does not currently have an import/export feature for tests, I have an idea that could potentially solve the problem. In Google tools, there is a recorder that has a feature to export/import use cases as JSON. The user can play with JSON files from previous tests, and rejoin and modify them. This feature could be a viable alternative to the import/export feature that you requested.

  • Prolorus

    •

    Dec 3, 2024

    @Paweł Bylina for me I would like an export feature that allows me to export a test and all it’s steps to a JSON file. I can then manipulate the file and reimport back into BugBug.
    I have been using this feature with Ghost Inspector to quickly replicate steps in a test that only have slight difference… Think accessing 20 pages and creating an assertion each time as part of a smaoke test.

    • Paweł Bylina

      Team•

      Dec 3, 2024

      Today you can only duplicate a test. We plan to ship this feature in the next year.

  • Ken Lyle

    •

    Apr 10

    I have Claude Code writing and running automated tests using Playwright. I would love to be able to import those.

    The LLMs are really good at writing structured outputs. I have Claude generate Uilicious syntax tests regularly- It’s super-simple: I.goTo, I.click, I.enter, I.see etc. - For me, that would be an nice import, and fairly easy as the operations are so fundamental.

    • Paweł Bylina

      Team•

      Apr 16

      This is our current goal. We have implemented the YAML format for the tests and are now finishing the importing functionality. We will publish the format and the option to export/import soon. This will enable users to transform tests from BugBug into other formats, and to import tests from other formats into BugBug.

  • Ken Lyle

    •

    May 21, 2025

    Import from Uilicious would be helpful to us.
    They have a pseudo-AI, TAMI, which produces pretty good tests from a prompt.

    The tests have a really simple syntax like

    I.goTo

    I.click

    I.hover

    I.see

    so should be able to map pretty easily, as it’s a simple platform.

    • Paweł Bylina

      Team•

      May 22, 2025

      @Ken Lyle It's probably possible with LLMs. It would potentially be easy when we have our own DSL. Why do you want to switch from Uilicious?

      • Ken Lyle

        •

        May 22, 2025

        I consider Uilicious to be a very 1.0 platform, kind of like Netscape as a browser.
        It certainly doesn’t have the Inbox Tester. I recall that I have only one user account. There is no recorder. I am not aware of any CI/CD integration. I have not found their team to be very responsive, and they use Discord, which I find very dysfunctional- I know that with threading turned on, it should be better, but I found the “support” function to be both chaotic and non-responsive.

        • Paweł Bylina

          Team•

          May 22, 2025

          Thanks for the details! I thought this was a relatively mature business, but it sounds like an amateur project.

          • Ken Lyle

            •

            May 22, 2025

            That’s just my impression. You know how relationships can die slowly by 1000 cuts and tiny annoyances? That.

            • Paweł Bylina

              Team•

              May 22, 2025

              I absolutely agree!