# What's New? ### OS Filter for Test Steps OS-level filtering for individual test steps - enabling precise platform-specific execution control within a single test case. In cross-platform test cases configured to run on both Android and iOS, all steps would previously execute on both platforms regardless of relevance. This made it difficult to handle platform-specific flows without duplicating entire test cases. With this capability, users can assign an OS type to individual steps directly within the test case editor. During execution, steps with a specific OS assigned are only triggered for the matching platform and skipped for the other. Steps left at the default "Both" setting continue to execute across all platforms as before. OS settings applied to a functional block affect only its usage in that context - the block itself remains unmodified and fully reusable across other test cases.It is now possible to manage platform-specific logic within a single test case, eliminating the need for duplicate flows and reducing maintenance overhead. *** ### Clone Test Data Across Plans Clone test data sets from one test plan to another — eliminating manual re-entry and ensuring consistency across plans that share the same data structure. Previously, reusing a test data set across multiple test plans required manually recreating each entry, which was time-consuming and error-prone, particularly for large data sets with a mix of static, random, and dynamic values. With this capability, users can clone an existing test data set with a single action. A popup prompts for a new title, after which all items are duplicated under the new set - preserving their original state, type, and order. Static and random items are copied exactly as configured. Dynamic items are inserted as-is, without altering their generation rules.It is now possible to scale test data across plans rapidly while maintaining full fidelity to the original configuration. *** ### Exception Block for Failure Handling Introducing a global exception block at a test case level, to enable automated failure handling without manual intervention. In complex test flows, a failing step would previously halt execution or require individual error handling to be configured for each step. This made it difficult to ensure consistent cleanup or recovery actions. With this capability, a dedicated Exception Block can be configured at the footer section within the test case. If any step fails during execution, exception block is automatically invoked, executing the defined actions in the block. It is now possible to define centralised failure recovery logic once and have it apply automatically across every step in the test case. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.qapilot.io/whats-new.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.