Hello Testiny team!
We are facing a challenge with the current test run creation interface.
Our repository contains ~ 10,000 test cases, and we’ve noticed that the interface limits the display to a maximum of 500 cases per page.
This limitation makes it inconvenient to browse through the repository, as we are unable to see all sub-sections at once. Scrolling through multiple pages to locate the desired test cases is both time-consuming and inefficient.
We would greatly appreciate the ability to:
- Display the entire repository in the test run creation window without page limits.
- Or alternatively, increase the maximum number of test cases shown per page significantly (e.g., to 2,000 or more).
This enhancement would improve usability and efficiency for teams working with large repositories.
2 Likes
Hi and welcome to the Testiny forum!
The current limitations on the page size are there for a reason, i.e. to limit the data transferred and the workload both at the Testiny backend and frontend. Bigger page sizes may cause longer request times and performance issues in the frontend (your browser).
So we are a bit hesitant when it comes to increase that limit or remove it altogether 
That said, we would like to better understand your use case, meaning why it’s necessary to see >2000 test cases and why searching or filtering test cases is not a viable option.
So, it would be great if you could give us some more context and if there’s something that you are missing in Testiny’s filtering capabilities that would also improve the situation.
Thank you!
Best regards,
Alex
Hi Alex,
We’ve recently moved from TestRail, where we were long-time users. In TestRail, the entire repository was visible during the test run creation process. This feature was convenient, as it allowed us to see all sub-sections at once and navigate more efficiently. It provided a clear overview and made it much easier to add all necessary test cases.
While Testiny’s filtering and search features are useful, they don’t fully address our needs:
- Search Limitations: Search requires specific keywords, which can be tricky when we don’t remember exact test case names. In many cases, we need to explore the repository visually to identify relevant test cases.
- Filter Limitations: Filtering by type, priority, or other fields doesn’t work well for us because our test cases were created without consistent use of these attributes. We haven’t fully refactored our repository to include these fields across all cases, so filtering doesn’t provide the precision we need.
Additionally, our repository contains not only a large number of test cases but also a large number of sub-sections. Having all sections visible at once makes it much easier to navigate directly to the desired section, rather than scrolling through multiple pages to locate it. This immediate visibility greatly improves our efficiency during test run creation.
We understand your concerns about performance. However, one potential solution could be to load all sections in a single request initially and then load the test cases within each section dynamically only when the section is expanded. This approach might strike a balance between usability and performance optimization.
