General Overview
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 comes from putting all pieces together. For example, PractiTest can automatically show you which requirements are not covered by tests, and 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. Four types of test cases 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 a description. (read more) - BDD - A test that is written as a scenario or as a scenario outline. Use the common Gherkin syntax, and each Gherkin row will become a step when you run it. If you use Scenario Outline, each example will be added to the test set as a separate instance. Read more about BDD tests here.
- Automated - Test that runs automatically and updates PractiTest using one of the following tools:
- API tests - reporting automation results using the REST API.
- FireCracker Tests - FireCracker automatically converts xml results files (Received from CI/CD tools) to PractiTest tests and runs.
- xBot - an internal automation framework.
*To read more about automated tests options please click 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 (besides BDD tests).
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 required.
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. You can either create a step or call steps from a different test using the test ID. Each Test Step has the following fields: Name, Description and Expected results. You can attach a file or link and add a comment to each step or to the entire Test. During the run you will be able to add files and links to the Step Run as well.
Step Attachments, Test Attachments, and Step Run Attachments
In the test’s general attachment section you can add attachments that are relevant to the whole test and not just a specific step (for example, system configuration document for the test).
TTest Step attachments are relevant to a specific step, for example, a screenshot of how things should appear. When running, each step of a Test Run (i.e., step-run) will show the Test Library’s Step fields and attachments. During the run, you can add attachments to the Step run, for example, to show a log of the run or a screenshot 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 deleting 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 Tests to and then click ‘Add Tests to Test Sets’.
