Loop / while inside tests

With this feature, you will be able to add loops inside your tests

Dark mode

Dark theme of the BugBug web application.

Configure browser geolocation

Please add the functionality to configure browser geolocation to a specific coordinate/region for a test/suite. This feature would be crucial to test many apps since their behaviour might be adjusted in accordance to the geolocation, and in many cases this is a regulatory requirement of certain countries/industries.

Multi-browser support

Option to add more window sizes for tests in project settings

Today, BugBug offers the only option to configure Desktop and Mobile window sizes. It would be nice to give the ability to add more screen resolutions.

Video of a test run

This will only be available for cloud runs, but could provide some additional information for debugging purposes.

Private cloud / on-premise

Option to install BugBug on customer infrastructure or in popular cloud providers such as AWS/GCP/DigitalOcean under customer maintenance.

Manual step in tests

A new type of step that must be confirmed whether passes or fails manually by the user. We are gathering interest in this idea here. The step can be used to create a fully manual test scenario, where all steps are to be verified by the QA professional or can be used inside a regular automated test where at the certain stage the manual verification by the QA professional is necessary (e.g. is the content of the generated PDF valid). EXAMPLE OF MIXED-CASE SCENARIO Phase 1 — test recording Marie starts test recording, logs into the application and navigates to analytics dashboard. She selects the first position on the list of available metics. She records a series of assertion ensuring proper graph headers are present on the page. Next, she pauses the test recording and validates if all the graphs on the page contain no data gaps. She pans and zoom inside the interactive canvas-based visualization. After confirming no data gaps are present in the graphs, she resumes the test recording. She selects another position on the list of available metics, records a series of assertion ensuring proper graph headers are present on the page. Next, she pauses the test recording once again and validates if all the graphs on the page contain no data gaps. Once again, she pans and zoom inside the interactive canvas-based visualization. After confirming no data gaps are present in the graphs, she finishes the test. Phase 2 — test editing Now, Marie goes back to the BugBug web application to split the test into several groups and to create placeholder groups for the manual verification process for both metrics. She adds a new manual step in the manual verification group and fills out the name: "Check no data gaps in YOY revenue graph" and provides a quick description in the step details. She repeats the process for the other metric. Phase 3 – test run Marie runs the test. BugBug extension goes through the previously steps and stops at the manual step "Check no data gaps in YOY revenue graph". She validates that no gaps are present and sets the step toggle into "Passed" position. The extension immediatly resumes replaying previously recorded step until it faces the manunal step again. Marie repeats the procedure and after confirming the step passed, the whole test finishes with "Passed" status. Technical requirements step name is provided by the user additional description can be provided in the step details step timeout can be set by the user step is set to passed in the cloud environment if run via BugBug extension the popup lets user confirm if the step passed or failed

Lock components for non-admin users

Some components should only be editable by an admin user, the normal users should only be able to use the components but should not modify them

Run tests on the local machine (local agent)

This can be useful for running local headless tests or connecting your application behind a VPN if you can't allow BugBug's Cloud IPs into your infrastructure. The local agent will also help you connect to the local database and manipulate it when necessary.

Easy API testing

In some test cases, to cover scenarios, retrieving data from API is required. Today, this is something that users can achieve using a custom JS step and fetch() function, but this requires code. To simplify this process, it would be nice to add an extra step like Request API where you will be able to define a method, URL, and parameters for making requests. Using variables within this step should also be possible. Storing the response as a variable could also give a lot of flexibility to users. This could be a first step to implementing more advanced API testing for BugBug.

PDF assertions

An easy way to validate what's in the generated PDF

Allow undoing a test step deletion

I've had this happen a few times when I wanted to delete a test step but didn't want to finally. It would be great if we can undo (at least) the last delete action. Using Ctrl+Z or a cancel deletion button somewhere.

Storing information between tests / persistent variables (data storage)

Example: user has a list of company IDs that he wants to use in tests each test execution should take the next ID from the list BugBug could help here if there is an option to somehow store information about the last used ID. This could also be used in other cases, or for exchanging data between tests in the test suite.

Teams integration for alerts

Add a native integration with Teams, similar to Slack.

Store tests as scripts in the git repository

The idea is to store tests in the git repository and allow users to manually modify them using any IDE. After modification, users can commit changes, which will appear in the UI.

Adding Upload CSV file to the BugBug tool (datasets for tests)

In my previous suggestion titled “Suggestion about interacting with similar pages”, Mr. Pawel mentioned that “We started working on if-else statements this month”. I think that’s a great start! Building on that, I suggest adding a new feature to BugBug tool that would be useful for everyone who uses if-else statements. The feature is “Adding Upload CSV file to the BugBug tool”. The properties of this feature are: It could be a use case as same as “components” that can be used in all tests in a project. Then the user can use it as an action as same as mouse, inputs, etc. The action has several steps, such as reading the file, reading a specific data (value) in the file, and assigning it to a variable. So the user can loop in the data to use different values in the loop steps. I think this feature is essential in automation testing and is very famous in Selenium and codeless tools. It would be a great addition to BugBug tool and would make it easier to automate repetitive tasks.

Step to end test

with the new if (end-if) condition(great work btw) i was thinking that it would be great to add a step that ends the test itself

Assertion for page loading time

An extra assertion to validate how long the page was loading.

Assert the element has an attribute with specific value

Now we can use the assert the element has the expected “value” attribute. But we can´t assert another attribute value. In my case I´m trying to find an element and assert if it has the attribute “data-state” set to "checked/unchecked"

Add a versioning system to allow running an old version of the test

Hey there, To integrate Bugbug into my CI/CD and have my tests pass on multiple environments, I currently have to duplicate the tests and modify the changed parts, which is inefficient... It would be great if we could have test versioning so that I could point the production-oriented test to the production environment (let's name it v1.0) and the development-oriented test (v1.1) to my development environment. With that, when I deploy dev to prod, I'll be able to point the test I've already created for dev (v1.1) directly to production. Without that, I'll have to spend time modifying the tests right after deploying dev to production, otherwise the tests would fail.

Two-factor authentication (2FA) for BugBug web application

Auto-healing broken tests

Some heuristics to implement an auto-healing mechanism for broken tests.

Reusable login session

Today it is not possible to reuse the login session if we use the same login component for most of the tests. This feature could reduce the execution time of tests.

Reserved parallel runs for manual testing

Problem Teams with several parallel cloud runs often use all of them for automated suites (scheduled runs, CI/CD, API triggers). When someone needs to run a test manually, for example to verify a hotfix or debug a failure, they have to wait until an automated run finishes, because every slot is already taken. What we’re planning A concurrency limit for automated executions, set at the organization level. You will be able to decide how many of your parallel runs automated suites may use at the same time, and keep the rest free for tests started manually from the BugBug app. Example: an organization with 10 parallel runs sets the automation limit to 9. Scheduled, CI/CD and API-triggered suites never use more than 9 runs at once, so 1 run is always free for manual testing. How it will work A new setting in organization settings: “Max parallel runs for automated executions” Automated runs above the limit are queued, not rejected Manual runs can use any free slot, including the reserved ones Works within your current plan, with no change to your subscription or number of parallel runs

Simple conditional statements

'If-else' rules apply to tests for single steps and whole groups.

Screenshot comparison (Visual regression) - assertion step

We plan to add a separate step for screenshot comparison. The first execution will save a screenshot as a baseline, and then every next execution will be compared to this baseline screenshot. If the new screenshot is different from the baseline, the test will fail. Possibly, this step should also have an option to exclude some random elements from the DOM before taking a screenshot option to decide how this comparison should be done (pixel perfect or percentage) option to verify screenshot only for specific element on the page (given selector) Any other ideas around this feature are more than welcome.

Add a way to create a folder in tests page

As you create more tests it would be harder to filter and organize the scripts, would be nice if we can create a folder inside to organize it. Author: Lain H A nice feature would be the ability to group tests in the same way test steps can be grouped and the group named, expanded and collapsed. So, allow tests to be grouped, the ground named, and the individual tests expanded or collapsed in a similar fashion. A step further would be to allow a test to appear in more than one group, but I guess that’s then crossing over into Suites. Or maybe tests could be tagged and have more than one tag, and then viewed by tab with tabs expanded and collapsed? That would do 2-in-1 - grouping and allowing one test to be seen under more than one topic/slice (tag)

Ability to add the same component to the test multiple times

More detailed PDF reports for test runs and suite runs

For evidentiary purposes as defined by some legal regulations (in the USA), we plan to add an option to save the results of test runs and full suite runs as a PDF with detailed information such as Step type Screenshot of the page Additional comment Step status Date of the execution The first implementation should allow users to download these reports from the UI manually. Based on the feedback, the next phase could bring some automation on how to store them without manual interactions. Any extra feature requests are welcome.

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.

Record (and run) at a specific location in a test

For me, the most time-consuming part after (and during) recording a test is the need to run the entire test from the beginning to the end (or until a certain point) if I need to change or update something. More exactly, for our longer E2E tests from start to finish they can take up to 5+ minutes, and if I need to record something at the last few groups, I need to wait minutes in a row just to reach that part in order to click or update some new elements. In the roadmap, something that would help with the above are the following two considered features: I wish that, during recording, I could "select" specific locations inside the test where the step would appear for the action I do in the recorded window. This way I could skip/ignore certain groups/components of the tests which I know are passing. Maybe something like a "Record at location" or "Change record location" button in the recording options modal, which, when pressed, would allow me to select where my action will be recorded in the test in the form of a step. If I was able to do something similar to that, I would be at least 50% faster if not more, while expanding our testsuite or even keeping it updated when needed. As mentioned, a big chunk of my time consists in waiting for a test to reach a certain point, so I can continue adding more steps. I think the best parallel I can do here is the "Record at cursor" option from Playwright: While this option is activated (and clearly marked it's on) then any action done on the webpage will be recorded I can cancel/stop/pause the option, without closing the recording window, so that I can freely navigate the webpage elements without actually recording steps. While the option is activated, I can also click any line number in the code editor where I want the step to be recorded The steps are recorded in the same manner as BugBug, from top to bottom, wherever the "cursor" is at the code line at that moment A video that captures the above behavior to get a better idea: https://streamable.com/w18bz1 In my opinion, this would be the most important feature for me while using BugBug, probably above any other improvements I can think of. 😁

Before & After steps for tests

We plan to add an option to perform some actions before test execution and (always) after test execution. This could be treated in a similar way to the setUp and tearDown functions in unit tests.

Sorting and filtering on test suite report

It could be very useful to be able to sort every column in a test report as well as having filters to show at least the passed/failed/all tests. You can also, decouple the test code from the test name in order for that to be individually sorted as well.

Folder system for components

Folder system for components for better organization. We may use some components for a particular section of our product and some others for another section. It could be useful to have a way of distinguishing them.