Managing and running tests is the core of your testing process. It is important that your tests are properly organized and defined, in order to perform your job in the most effective and efficient way.
Although you can use PractiTest as a stand-alone bug tracking tool, or as a requirement repository, the extra added value of PractiTest’s Application Life Management (ALM) comes from putting all pieces together. For example, PractiTest can automatically show you which requirements are not covered by tests, or what customer features are more or less stable than others; it can allow your developers to see the exact tests where the bugs were detected, and be able to manage all your Development Life Cycle in one place.
Test Case Creation and Management
The Test Library module is where your tests are created and stored. There are Three types of test cases that can be created in the Test Library:
- Scripted - Test cases where users predefine steps.
When choosing a scripted test, you can add the description in the general tab and a “Steps” tab will appear where you can define the steps
- Exploratory - Tests that don’t include predefined steps where users add annotations "on the fly".
When choosing an Exploratory test, you will find fields for Test Charters and Guide points instead of description. (read more)
- Automated - Test that run automatically and update PractiTest using one of the following tools:
- API tests - reporting automation results using the REST API
- FireCracker Tests - FiraCracker automatically converts xml results files (Received from CI/CD tools) to PractiTest tests and runs.
- Eggplant - when working with thePractiTest - Eggplant integration.
- xBot - an internal automation framework (coming soon!).
*To read more about automated tests options please go here
After saving, a Test can still be converted to another type of test using the actions button at the top right side of each test.
These tests can later be run as part of your Test Sets.
Each Test has its own meta-data, as defined by its system fields and custom fields; you can customize your tests by adding as many fields as your product and process require.
Scripted test - Test Steps
A test usually comprised of several steps. The steps describe in detail which validation checks you need to perform on your application or system.
To enter steps to your tests, go to the Steps tab and add your steps one by one. Each Test Step has the following fields:
Name, Description and Expected results. In addition, you can attach a file or link to each step, Test or Step Run.
Step Attachments, Test Attachments, and Step Run Attachments
Attachments can be added to specific steps, but also to the test in general, to be viewed later in the test’s ‘Attachments’ tab. In the test’s general attachment tab you may put attachments that are relevant for the whole test and not just a specific step (for example, system configuration document for the test).
A step of a Test Run (ie. step-run), shows the Test Library’s Step fields and attachments, and it may have its own attachments. The difference between the attachments of a Test Library Step and a Step Run, is that Library step attachments, may have screen shot of how things SHOULD appear, while the Step run attachments, can show a log of the run, or a screen shot of how things look while running the test.
After saving a test, you can always go back and add, delete or re-order steps, or call steps from a different test. PractiTest even allows you to modify your steps as you run your tests.
The Traceability tab
Under the Traceability tab, you can see the test's instances in TestSets it was added to, the issues that were found using this test, which requirements this test is covering and the tests that are calling this test.
The Test Library Grid
The Test grid is initially displayed with the default view, showing all your tests and some default fields in the columns. You can choose to display only tests that fall under certain criteria based on your filters. Filters can be created from the grid itself or from the project system panel. When defining filters, you base the criteria on the tests fields value. You can also configure which fields will the grid show under each filter.
Read more about filters display here.
Other than viewing and editing single tests, you can also perform actions from the test grid itself, such as editing, cloning and deletion of multiple tests at one time.
How do I run my tests?
Before you can run a test, you need to add it as part of a Test Set. Test sets use copies of the tests you have in the library – called test instances. This way, you can make changes to a single test-instance without altering the original test (If, for example, you delete a step in a test instance, your original test in the Test Library will stay intact). Each test can be added to as many test-cases as needed.
When viewing a test in the Test Library you can open the instances tab in order to see exactly where it’s being used.
For information on creating Test Sets and running tests, go to Test Sets & Runs section.
Creating Test Sets directly from the Test Library
Test Sets can be created from the Test Library directly. You can create a new Test Set from the Test Library, by selecting the Tests you want to group together in a Test Set, then click on ‘Create a TestSet’.
Adding Tests to existing Test Sets
If you want to add Tests to existing Test Sets, you can do so from the Test Library, as well as from the Test Sets & Runs module.
In order to add Tests to existing Test Sets from the Test Library, select the Tests you want to add, then click ‘Add Test to TestSet’.
When clicking ‘Add Test to TestSet’, a new screen will appear, containing the different filters from the Test Sets & Runs module. Select the Test Sets you want to add the Tests to, then click ‘Add Tests to Test Sets’.