Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Note: QMetry Insight module will only be visible if the user has the View and Modify rights for QMetry Insight.

...

Using the fields, you can easily create custom queries and generate custom reports.

Note:

  • Queries returning data from using a SELECT *  clause is not allowed. Column names need to be specified in the select statement.
  • UPDATE and DELETE queries are not allowed.
  • Group by GROUP BY on text column is restricted. QMetry reporting tables store custom/udf fields of type lookup & multi-lookup as text fields. Hence GROUP BY on these fields are not possible.
  • The gadgets other than table are generated on the 500 records.
  • While creating queries, during execution the query will return just the first 500 records. However all data is available in the reports export.


The test asset key will

...

become clickable on the report if the column name

...

contains the keyword (i.e. Entity Key), in any of the formats like -  "entity key" or "entityKey" or "entity-key" or "entity_key" in it.


Once you edit the query using required fields, click Run to generate the report.

...

Individual Gadget data can be exported into CSV with the same limit.



Best Practices

  1. Rights to write custom queries must be provided only to those users who have knowledge of writing SQL queries and can access any QMetry data, as there is direct access to all QMetry data in Report Schema DB.
  2. The custom SQL queries must always include a project filter specified as : @FILTER.PROJECT. This will prevent the recipients of the shared report gadgets from inadvertently viewing data from other projects that they do not have access to.
  3. The custom SQL report queries after creation must be run and saved against a Sample Project, so that the report does not load with the data of an un-intended project.
  4. The Report DB has tables like testcase, testexecutions, etc. which now only have user IDs instead of the actual information of the users. This information should be queried by writing an SQL Join with user IDs from `users` table now available in the Report DB schema.