Adapt Data-driven testing and avoid duplicating Scenarios
A Scenario in accelQ represents a unique flow or use case in test application. Never write two Scenarios that are comprised of same sequence of Actions. All the data permutations within the same flow should be addressed by way parameterization and data driven testing. Do not duplicate or clone Scenario, unless you are creating a different flow/sequence of steps.
accelQ takes data driven testing to the next level, by allowing you to define parameters based on Data Types or Data Lists. When you find a particular Action parameter can only take a limited set of values, define appropriate Data Type or Data List for that parameter. You can automatically create permutations of test cases based on permitted values.
Design Test Suites with your execution requirements in mind
Plan your release or sprint level test executions through Test Suites, and not as individual Scenarios. With the Filter based and Requirements based suite design, you have an ability to design dynamic test collections. Few parameters that could make good filter criterion include Application Module, Sprint number, Build verification attributes such as Sanity, Regression etc.
You can also utilize Test Case filters to gain additional control on the level of granularity in suite design. For example, you could setup a suite with Scenario filter on Application Module, and then further division between Sanity, Smoke and Regression through Test Case filters. Remember, you can setup Test Case filters even for a Static Test Suite.
Here is a sample Custom Field design to accomplish above requirement.
Plan and organize your test executions just like test development
When you are in a release cycle, it is a common occurrence that automation executions are not particularly well planned or organized. Most of the time, tests are run in an ad hoc, incremental fashion and an automation team member takes the responsibility to collate and communicate the overall result.
In accelQ, test executions can be planned and organized equally well as the test development. In the release planning stage, determine which suites will be executed and on what schedule. Each cycle of execution should be well identified with a properly indicated "Purpose of Run".
In case there are reasons to re-execute part of the test suite in a given cycle (either due to build issues or other reasons), utilize the Re-run facility in the test report. When you re-run a test, all the instances (or attempts) of executions in a given cycle are collated together. You get a unified view to test report, which can be shared with the project team.
You will find "Re-run" button in the top right corner of a test report.