A release represents an internal or external distribution of software once a development loop within a product’s lifecycle has been completed. In qTest, a start and end date of a release has to be defined.
The build information includes information on the relevant testing plan, tests conducted, test results, and defect records.
Users can divide applications into modules, hierarchical groupings based on the product’s structure and functionality. Requirements and test cases can be assigned to specific module levels. Often, it is helpful to organize requirements and test cases into logical groupings, according to module functionality.
Modules are commonly shared between the Requirement tree and the Test Case tree. Creating or editing modules in the Requirement tree will affect the Design tree, and vice versa.
Requirements describe in detail what needs to be achieved in order for the software developed to meet its objectives.
Test case describes in detail what needs to be tested to meet quality objectives. Test case details steps, including actions and scenarios, and expected results.
The testing of a release can be broken into a number of shorter cycles. Each of these cycles results in a build.
Test suites are comprised of a set of the same type of test cases, such as functional tests, non-functional tests, sanity tests, or regression tests. Test suites are focused on addressing specific test objectives. For example, tests in a test suite may be selected specifically to validate specific new features, or to test given levels of integration.
Test run refers to an uninterrupted period of time spent in executing a test case. For each test run, the tester is provided with the instructions and resources required to perform the test. In addition, the test run may specify a choice of possible results and provide testers with the ability to attach supporting documents and comments.
A flaw that causes a component or system to fail to behave or function as expected. If encountered during execution, a defect may cause a failure of the component or system.
This page is displayed when a user clicks the top most object of any system tree. The name of the root object will correspond to the project. The user can collapse the system tree or expand it to view the entire structure.
System User Roles
Site Admin: The first user who registers a site on the QASymphony Web page will be granted full privileges on site settings page.
Project Admin: A user who is normally assigned to a project created by the Site Admin and who has all permissions enabled on their assigned project.
Project User: Any other users who are invited to the registered site by the Site Admin and added to a specific project by the Project Admin. The Project Admin can specify a Project User’s permissions and access rights for each specific project.
qTest’s major menus provide different capabilities that correspond to each step in the product testing life cycle. qTest includes the following System tabs: Project, Requirement, Test Design, Test Execution, Defect, and Report.
A hierarchical display of objects, for example, with the root page at the top and underlying objects at the bottom.
System trees are available in the following locations and their names:
Test Plan tab: Release tree toolbar
Requirement tab: Requirement tree toolbar
Test Design tab: Test Case tree toolbar
Test Execution: Test Run tree toolbar
Any objects that are created while using qTest, including: release, build, module, requirement, test case, test cycle, test suite, test run and defect. They can be edited, deleted, copied or cut on the system tree to manage your test project in a flexible manner.
System Tree Toolbars
A toolbar includes buttons that provide access to the most commonly used functions on each System tree across qTest’s main system tabs.
These toolbars are available in the following locations:
Test Plan tab: Release tree
Requirement tab: Requirement tree
Test Design tab: Test Case tree
Test Execution: Test Run tree
Test Data Source
A test database that is used for a specific test suite. All test runs for a given test suite must be based on the data extracted from the associated test data source.