Filters enable you to organize your data in a dynamic rather than a static way. Using filters, you can organize your issues, tests, testSets, and requirements, based on their fields, and have the information, displayed in multiple ways.
For example, you can create 2 filters in the Test library module - one that displays the tests that are related to the DB server and the other filter displaying tests whose priority is 'Show Stopper'. A test that
has its component field set on ‘DB server’ and its Priority set on 'Show stopper' will appear in both trees accordingly.
Similarly to working with paper folders, folders allow you to file a paper only once. In case your paper belongs to more than one folder - you will need to choose where to put it. If you will want to re-organize
your papers according to different parameters you will have to take all the papers out, delete the folders you have, create new folders and organize the papers accordingly. When you want to find a paper you need to
remember in which folder you filed it.
Filters enable you to organize your data in a dynamic rather than a static way.
Each “paper” is tagged using different fields. You can then create a filter for each value and field and the same test will appear in all relevant filters.
It means you can slice & dice your information in many ways and stop wasting time on data mining.
Many times, an entity belongs to a subcategory inside a larger category. This is why we call our filters “Hierarchical filter trees”: Each filter can become a parent filter of more filters. This way you can easily find the exact data you are looking for.
For example - I can have two separate filters: One will show tests that their component is 'DB server', and the other will show tests that are set to priority Show stopper. A test that is both DB server and a show stopper will appear in both filters.
But - If I want to see all tests that are DB server AND show stoppers?
I can create a sub-filter under 'DB server' filter and add the show stopper rule. Under this child filter, only tests that qualify to both criteria will appear.
In order to save you time and based on the fact that many times filters are based on ‘list’ type fields, PractiTest can create automatic filters trees using ‘auto filters’. With auto filters, the process of organizing your entities is cut down significantly allowing you to concentrate on your actual work.
When creating a filter based on a ‘list’ field type, you can choose to make the filter automatic. This will mean the software will automatically create sub-filters for each one of the list values. So, if I have a list field for Tests named “Product Component” with different options to choose from, and I create an auto filter based on this field, I get a component parent filter with child filters of all the component options I have in the field. I can also see how many tests reside in each sub-filter.
After making data organization in each module much more agile, flexible, and customizable - why stop there?
What if I want to see all the issues in my issues module, that are related to a specific sprint?
Or what if I want to view all tests that were not added to a specific sprint?
These relationships are something that you can’t even dream of using folders.
In PractiTest - it’s as easy as pressing a button.
Want to know how to do it?
Read more here