Merge pull request #658 from grafana/update_roadmap

Update project roadmap

Author: andrewslotin

ROADMAP.md

@@ -30,35 +30,26 @@ Status updates
 Short-term goals
 ----------------
 
-These are goals achievable within 3-6 months, tentatively done by Q3 2022.
+These are goals tentatively achievable by Q2 2023.
 
-- **Stabilize the existing functionality and fix any major, high-impact, and blocking bugs.**<br>
-  Tool stability is something we take very seriously and users shouldn't run into any major showstopping issues.
+- **Make xk6-browser a part of standard distribution of k6.**<br>
 
   *How will we achieve this?*<br>
-  By manually testing the application in different scenarios, adding more automated tests, and addressing reports from internal and external users.
-  Any issues found that have a considerable user impact will be given highest priority and fixed ASAP.
+  xk6-browser will become an [experimental module](https://k6.io/docs/javascript-api/k6-experimental/) of k6, and thus available to use in load tests that utilize standard k6 release builds.
 
   *Definition of Done*<br>
-  This is difficult to gauge, but at some point we should stop running into any major issues on a frequent basis and should consider this goal as reached.
+  A load test script that imports `k6/experimental/browser` can be executed using the latest release build of k6. The browser-level APIs provided by xk6-browser are available for use within this script.
 
-
-- **Limited Alpha deployment and testing of the extension in k6 Cloud.**<br>
+- **Public beta in k6 Cloud.**
 
   *How will we achieve this?*<br>
-  Soon we will create a small-scale deployment for internal use and specific customers, meant to test the basic integration of the extension in k6 Cloud.
+  Cloud builds will start using k6 releases that include xk6-browser as an experimental module.
 
   *Definition of Done*<br>
-  When the extension is usable in k6 Cloud; i.e. scripts can run and test results are shown. Frontend changes are not required at this stage.
-
-
-Mid-term goals
---------------
-
-These are goals achievable within 6-12 months, tentatively done by mid 2023.
+  Load tests executed in Cloud can use xk6-browser API by importing `k6/experimental/browser`.
 
 - **Transition our API to be async/`Promise` based.**<br>
-  Currently (April 2022), most of our API is synchronous. This is due to the historical fact that k6 didn't support async behavior because of a missing per-VU event loop.
+  At the moment, most of our API is synchronous. This is due to the historical fact that k6 didn't support async behavior because of a missing per-VU event loop.
 [This event loop is now available](https://github.com/grafana/k6/pull/2228).
   Async APIs are important for a browser-testing tool, since most browser behavior and [CDP](https://chromedevtools.github.io/devtools-protocol/) (the protocol we use to communicate with the browser) is event-based. We need to expose an async API to implement this missing functionality and reach feature parity with tools like Playwright or Puppeteer.
 
@@ -69,25 +60,18 @@ These are goals achievable within 6-12 months, tentatively done by mid 2023.
   When most of the API can be used asynchronously.
 
 
-- **Beta availability of the extension in k6 Cloud for all users.**<br>
-
-  *How will we achieve this?*<br>
-  The deployment should be optimized and the extension thoroughly tested before making it available to all users. Frontend changes should be done at this point, and usage costs (CPU, RAM, storage) and pricing details should be determined, followed by public announcements of the availability. Features such as screen capture, video recording, downloading, and file uploading should be available.
-
-  *Definition of Done*<br>
-  When all users are eligible to upgrade to a plan that includes browser testing.
+Mid-term goals
+--------------
 
+These are goals tentatively achievable by Q1 2024.
 
-- **Merge the extension into the main k6 repository.**<br>
-  k6 and Grafana consider browser testing to be another strategy under the testing umbrella, along with performance, contract, and other types of testing that modern web applications benefit from. As such, the scope of the k6 tool will expand to include functional/E2E testing using browser automation, with the ultimate goal of merging the xk6-browser extension into the main k6 repository as a core JS module.
+- **Global availability of the extension in k6 Cloud for all users.**<br>
 
   *How will we achieve this?*<br>
-  Once the extension and API are relatively stable, and it's well-tested in k6 Cloud, we will create a PR to the main k6 repository with the extension code. Then we will deprecate the standalone xk6-browser repository, and point users to use the main k6 binary instead.
-
-  This will be a minor breaking change, as scripts will have to import `k6/browser` instead of `k6/x/browser`, and CI jobs will need to change, but the functionality should remain the same.
+  The deployment should be optimized and the extension thoroughly tested before making it available to all users. Frontend changes should be done at this point, and usage costs (CPU, RAM, storage) and pricing details should be determined, followed by public announcements of the availability.
 
   *Definition of Done*<br>
-  Once the extension has been merged into the k6 repository.
+  The import path for xk6-browser is updated to `k6/browser` and the API is considered to be stable.
 
 
 - **Increase test code coverage; refactor problematic areas of the codebase; fix "flaky" tests, linter issues, etc.**<br>
@@ -116,10 +100,10 @@ These are goals achievable after a year, and don't have a clear date of delivery
 
 
 - **Feature parity with Playwright and Puppeteer.**<br>
-  Currently, our functionality is limited compared to more mature projects like Playwright and Puppeteer. We plan to expand this gradually and reach or exceed the features offered by other browser automation tools.
+  Currently, our functionality is limited compared to more mature projects like Playwright and Puppeteer. We plan to expand this gradually and reach or exceed the features offered by other browser automation tools, such as screen capture, video recording, downloading, and file uploading.
 
   *How will we achieve this?*<br>
-  By prioritizing new features to add based on API importance and user feedback. After the short-term stability improvements are made, our main focus will be to add more missing features and close the current feature gap.
+  By prioritizing new features to add based on API importance and user feedback. Once our standalone and Cloud users are able to execute feasible complex scenarios, our main focus will be to add more missing features and close the current feature gap.
 
   *Definition of Done*<br>
   When we implement all of the functionality found in other tools that makes sense for xk6-browser. This is intentionally vague at the moment, and we'll refine it as we make progress.