We now have the ability to Create test sets from test library, but it'd be nice to have the ability to also *add* tests to *existing* test sets from the test library. Thanks!

There are no pages in PT that actually remember the width of columns or sorts. This makes using PT pretty annoying for people who manage or run test sets, issues, or requirements.

When reviewing tests cases, it would be useful to have a field to comment a step when a tester is reviewing someone else tests cases. This way, he can add comments without modifying the test case. In case of misunderstanding if the specification, from the reviewer, author of the test case can update the reviewer and doesn't need to rewrite the test case.

We want to be able to create filters from the API
this will allow us to group text sets created via a pipeline and better organize what tests where ran where

it would be very useful if we can duplicate the filters (instead of re creating them every time ) in case we need them in several places.

can you add the test number to the top banner of the page? or make the test name and number line "sticky" so it will stay visible when you scroll down?
(When I have few tests open, in order to work in parallel - I have to scroll up all the time to make sure on which test I'm on.
very annoying... and leaves too much room for errors (=unwanted editing)

Please add two-way integration with Github. Not everyone's on Atlassian products such as Jira, Bitbucket, et al.

Add ability to convert a search to a filter (which can be later customized).

Now, the only thing we can do to view Test Steps from Test Sets is by:
1. Clicking the instance
2. Click "Test in Test Library"

which means we can only see steps for a particular test at a time.

I'd suggest that you add the ability to view Test Steps directly from Test Sets, maybe by implementing display popover? Or maybe add another page that allows us to view all steps in all the tests in a certain test set. Thanks!

Currently, if a test is marked as an automated test ("Automated" checkbox is checked on the test case) the status of the test run cannot be changed manually. At times a test will fail due to an issue with the automation script itself, so we get a false fail. At that point we will run the test manually, but then we are not able to fix the status in Practitest.

As mentioned with the Ability to add a test case item, we tried filters; it’s cumbersome to have to shift gears and create a new filter every time that we want to look up / search for something new. It clutters things up as then there is the maintenance and scrolling to contend with as well.

In order to provide better coverage of the specifications I do propose to implement:

- Tree-like import that means importing parent and subtickets;
- Provide straight dependence between subticket and linked test, i.e. if Practitest user link test to subticket the test should also be linked to parent ticket automatically, as subticket is a must part of parent;
- Add system field "Traceability" for requirements that will reflect clickable test IDs;

If the solution will be implemented it will simplify test covering process and test covering tracking process;

When preparing a "Test set", sometimes we need to give extra informations about the "Set" we prepare with other builders and testers.
It would provide us the ability to share informations such as the purpose of the "set" or any extra data needed to execute the test.

And more, having a "comment" section in each "Set" would be helpful to share informations between testers and those who build the "Set".

There is currently no API to generate report by test set ID. Generate report by test set ID would greatly enhance our automation process

Right now, typing a word into "Tags" field will bring up tag suggestions, which is nice and useful, but it is case-sensitive at the moment.

For example, if the tag is "Billing" and I type "bill" without uppercase on the first character, the suggestion will not come up. I have to type it with capital B for the suggestion to come up.

When an issue is created from a test, the associated requirements could be linked (if Jira requirements, then the Jira requirement link) to the issue document (perhaps appended to description, or to a field defined in Practitest by the user) before being sent to Jira.
Why? So in Jira a developer can click straight on the requirement to see what should happen, rather than dig through a number of screens to access the requirement

When executing a test case one of the key things you'll want to reference are the requirements, so logically they should be accessible.

Very often when we are executing a test we would like to attach a screenshot. In many test tools it’s possible just to copy and paste from a sniping tool, but in practitest it seems to be necessary to save the screenshot as a file and then upload this file. This is pretty cumbersome. I suggest that you implement such a feature.

The ability to filter entities (e.g. Issues) based on traceability to other issues (e.g. requirements or tests)