Uy Tran
posted this on June 28, 2012 02:23 am
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.
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:
System Objects
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.
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:
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.