Bug Fest R1 2026 Trillium - Non-ECS - Eureka

Bug Fest R1 2026 Trillium - Non-ECS - Eureka

Bugfest Test Environment

Bug fest environment update will be triggered daily or on-demand (based on the availability of new releases):

  • 10:00 pm ET

URL: Trillium Bugfest environment (folio|folio): https://folio-etesting-sprint-fs09000000.ci.folio.org/

Please note: - Create/use your users for testing activities

In the New Eureka platform, you will need to work with Capabilities: How to: Finding and using capabilities/sets for permissions for QA

Test Environment Preparation wiki 

Trillium (R1 2026)

What

Who

When

Add test cases for the Trillium release 

QA Team

May 4, Monday

Folio module releases

Dev Teams

Apr 17, Friday

BugFest kick-off meeting

Yogesh Kumar

May 6, Wednesday

Claim test cases

Testing Community

May 4, Monday - May 15,Friday

Complete BugFest system

Kitfox Team

May 8, Friday

Sanity Test on BugFest Env.

QA Team

May 8 , Friday

Bug Fest

Testing Community

Product Owners

May 11, Monday - May 29, 2026 Monday

Bug Fixing including module release deadline

Dev Teams

May 11, Monday - Jun 5, Friday

Trillium (R1 2026) release becomes GA

Release Management Stakeholder group

Jun 8

BugFest Goals

  1. Execute the complete test plan (see the scope table below). A list of test cases can be found in the - https://foliotest.testrail.io/index.php?/plans/view/3440

  2. 100% of test cases with Smoke, Critical or Extended High priority should be completed

  3. Add test case descriptions and steps if they are missing

Kick-off Meeting Links

Bug Fest Instructions for Testing Community

  1. We use the TestRail application to edit test cases, assignments, and status execution. Folio Bug fest Project under https://foliotest.testrail.io

    1. Review Kick-off meeting links when necessary. 

  2. T Release Test Run  contains test cases assigned to this Bug Fest. (Useful link: all test cases are sorted by priority, then set the filter to "Untested" to find unclaimed ones)

    1. Priorities can be seen on the right side. Our approach is to claim/execute tests in the following order. Smoke, Critical Path, and then Extended.

    2. Since many tests are in Extended, we recommend running Extended as a high priority first. 

      1. To get extended high-priority tests - Click on the right side for Extended and Select in the Filter bar, select, Prioritization = Critical and High

      2. For Extended low priority, please filter Priortization = Medium and Low

  3. Please use the folio user login to create a user with the desired permissions you will use for testing. Don't use the "folio" user to run test cases.

  4. Please use the deliverable email address when creating your user account 

  5. FOLIO supports only Chrome as an internet browser. Please test in Chrome unless a test case description gives you specific instructions. 

  6. Please review Known Issue table on this page

  7. Failed test cases:

    1. Testers don't file defects in Jira

    2. When a test case fails, a tester creates a comment in Test Rail for this test case and assigns this test case to a Product Owner. See Scope table below with list of POs assigned to app or module. Include screenshots are very helpful. 

  8. Please use Slack channel #folio-bug-fest for all Bug Fest-related communications

  9. A retrospective meeting will be scheduled after the Bug Fest week.

Bug Fest Instructions for Product Owners 

To include a test case in the Bug Fest test run - set the "Test Group" field to:

  • Smoke

  • Critical Path

  • Extended

To remove the test case from the Bug Fest test run - set the "Test Group" field to:

  • Draft

  • Obsolete

  • Automated

Tests with an EMPTY "Release" field will not be added to the test plan.

View more detailed instructions in the Bugfix section of this page.

  1. Throughout the day, monitor failed test cases in your areas.

  2. For each failed test case, the Product Owner reviews the problem, creates a Jira bug, and links it to TestRail

    1. To link Jira bug to test case: 

      1. Select test case

      2. Click "Add Result" button

      3. Enter Jira ID into Defects field (for example, UIU-999).  Don't use URL format.

      4. Click "Save" button

    2. Use the mandatory label bugfest_R1.2026 for all logged defects.

    3. Use label regression if the functionality was working in the prior release

    4. Set the Release field to  "Trillium R1 2026 Bug Fix" if the bug must be fixed before GA deadline. 

    5. Use the following Jira statuses to track bug progress:  

Status

Indicator

Who

Action

Awaiting bugfix release

Indicates the item needs a bugfix/hotfix release to be created

PO

Confirmed an issue in folio-snapshot

Awaiting bugfix deployment

Indicates release containing bug fix is ready to deploy to BugFest environment

Lead Maintainer

Creates a module patch release from one or more PR

In bugfix review



Indicates the bug fix has been deployed to BugFest and is ready to test

Release Coordinator

or QA Lead  

Requests and verifies deployment of a module patch release to Bug Fest

Closed



PO or tester

Verifies fix in Bug Fest

  1. Also, monitor the Bugfest Dashboard in Jira TBD for any bugs filed in your area (some testers and other POs may file bugs, and we want to ensure we triage them, as well).

  2. Assign a priority to your bugs according to the defect priority scheme - Defect Priority Definition for Functional Issues

  3. Select a development team and notify the PO lead for the team so they can get development started

  4. Follow the bug fix process outlined

  5. Trillium R1 2026 Dashboard

Test Case Priority

Test cases that have Critical and High priority should be claimed first. Test Rail filter can be set to see cases with Critical or High priority.

PO & Team Info

FOLIO Module/JIRA project-Team-PO-Dev Lead responsibility matrix



Directory of Product Owners 

Bugfest testing details - Testers, please review

App / PO

Details

App / PO

Details

Bulk Edit, Data Import, Data Export, Lists app

Since this is the first time we are using the Sprint Testing environment, it is expected to be significantly less performant and more resource-constrained compared to our regular Bugfest environment. Because of this, the QA team will avoid executing heavy operations such as large bulk edits, high-volume data imports, data exports, and other performance-intensive actions in order to prevent instability and ensure reliable test execution.

 

 

 

 

 

 

 

 

Known Issues - Testers please review