Since RayQC is a checklist based application for quality assurance related test executions, it may actually not be overly surprising to find an object called "RayQC checklist". However, recognizing the differences between checklists and templates, or checklists and projects may be a bit tricky without further explanation. Therefore, here is a brief outline of the objects and their related file name extensions in RayQC.
RayQC Checklist and RayQC Template (*.rqct)
The file types checklist and template exist due to historical reasons. In fact, both names refer to the very same object type RQCT, which is the abbreviation for RayQC Template. The idea is that when a new checklist is created, RayQC uses a default template to generate the basic checklist structure. As long as the checklist has not been executed within RayQC, it is nothing more than a manipulated version based on the original template file. Therefore, when the labels checklist and template are used within the RayQC user interface or documentation, both actually intend to refer to the very same type of file.
The RQCT files used in RayQC 8.0 are ZIP containers that contain the XML checklist file (checklist.xml) as well as all other resources required to run the checklist in RayQC: plug-ins, help files, images, etc. are stored within dedicated directories wrapped in the zip container.
Checklist Group
A group is a logical bundle of elements within a checklist. The elements of a specific group are handled as a unit, and thus will be displayed in a shared container area when a checklist (template or project) is opened within RayQC. Each group has its own header (including index number, title, and description) and content section (including the groups checklist elements).
Checklist Element
An element is a single item within a checklist group. There are four basic types of elements that may be used within checklists: Information, Data Field, Checkpoint, and Multi-Option. The type of element determines the input and result options users face when they actually run a checklist instance (which in fact is called a project, see below). Further details about the specifications of the element types are provided within the Element types chapter later on.
|
Be aware: Former releases use different names for the checklist element types. In order to avoid misunderstandings and provide clear names, a change according to this mapping has been done: •Comment > Information •User Comment > Data Field •Checkpoint Entry > Checkpoint •Multi-Option Entry > Multi-Option |
RayQC Project (*.rqcp)
A RayQC project file (abbreviated by RQCP) is a ZIP container, just like RQCTs. In addition to the checklist resources it is extended with the current execution status for this specific checklist instance. Therefore, when a checklist file is opened in RayQC, it is automatically converted into a temporary project file that resides within the session memory. Saving changes made to a checklist automatically preselects the project data type RQCP as its file extension. Only when users manually change the default selection to RayQC Template (*.rqct), the original checklist file is physically overwritten.
In order to decide which target format is desired, users have to be sure about what exactly they want to save: The status-free checklist itself, which may later be used as the source for several new projects, or the current state of a specific checklist run, which has to be a project file.
|
Be aware: To distinguish evaluation status and element structure information out of a project file, users have to open the project file with a tool like WinZip or 7ZIP. Once opened this way, the checklist status and structure are both directly available as XML files. However, it is not recommended to manipulate the files somewhere outside of the RayQC application scope, since the result will very likely not be in compliance with its schema and value domain restrictions anymore. |
Plug-ins
Checklists may include different plug-ins, whilst each checklist element (see paragraph above) may be equipped with a maximum of one plug-in. plug-ins enable automated checklist execution, since they provide scripted logic that may be called by the RayQC plug-in interface.
Internal Plug-ins
Internal plug-ins have been defined within the RayQC application and are ready for usage within any kind of checklist. Users simply add the plug-in to an element, select the required control options and parameter values, and the scripted logic is executed at checklist project run. Within the current version of RayQC, there are nine Internal plug-ins available for out of the box usage:
External Plug-ins (PowerShell Script and Manifest XML)
Whilst Internal plug-ins have been predefined for general usage within RayQC checklists by the Raynet development team, External plug-ins may be created and integrated by RayQC users themselves. They usually provide specific logic for a test criterion required by a single checklist, or a whole checklist group. Depending on the test and assurance needs of each individual customer, these External plug-ins are limited only by the experience the creator has in writing PowerShell scripts, and the given restrictions of the work environment (e. g. access restrictions, best practices, and the like).
Each External plug-in must consist of at least one PowerShell script file, containing the plug-in logic, and an XML manifest file (Manifest.xml), declaring the plug-in interface for direct interaction and communication with RayQC. These files have to be stored within the same parent directory that is named according to the plug-in name. The type of supported PowerShell scripts is not determined by RayQC itself, but the PowerShell interpreter on the machine the plug-ins are executed on.
RayQC automatically checks the application installation directory (e. g., C:\Program Files (x86)\RayQC\) for the existence of a \plug-ins\ directory. If it exists, the content is analyzed in order to find plug-ins. These global external plug-ins may be used from within any checklist created and executed from the machine that hosts the current RayQC instance.
Another type of external plug-in is the local external plug-in. These ones are basically of the same structure (PowerShell script and manifest within the same folder which is named after the plug-in name), but have to reside within the plug-ins directory that is part of the RQCT / RQCP ZIP container. Therefore, local external plug-ins move with their parent checklists and projects, as they are essential parts of them. They are more portable than global external plug-ins, which reside on one specific QC device.
Please refer to the Plug-ins section of this document for details on how to actually use plug-ins within checklists.
|
Note: Please note that the possibility of using external PowerShell plug-ins within a checklist is only available with RayQC Enterprise Edition. |
Condition
Conditional statements are an important aspect of dynamic checklist evaluation. In RayQC, users are able to define conditions, as combination of several conditional statements, which may decide about the actual evaluation path of a checklist. For example: If the result of Checkpoint A is true and the result of Multi-Option B is false, checklist group X has to be evaluated. If not, checklist group X is invisible and does not affect the result of the checklist.
The logical idea of conditions in RayQC 8.0 is based upon the so called "disjunctive normal form" (DNF), which allow building any kind of condition as a combination of ORs between ANDs. To be more precise: A DNF is a disjunction of conjunctive clauses. Within our checklist editor, clauses are called buckets. Within each bucket, there may be several conditional statements, but all have to evaluate to true in order to let the bucket evaluation result become true. If the condition for an element contains more than one of those buckets, it is sufficient to have one bucket evaluate as true to let the whole condition evaluate as true. So you see, the buckets are made up of ANDs, and are chained by ORs.
Please refer to the Conditions section of this document for details on how to actually use conditions within checklists.
Next Steps
Now that the most important objects within the RayQC universe are a bit more familiar, it is time to see how they are used in productive work scenarios. Go ahead and get details about typical workflows in RayQC.