ELOQUENTAL¶

{ TEST ANALYSES LANGUAGE or TAL}

TAL is a constructed like a structural language that we use to describe our Tests and Test Cases. This language is inspired with syntax of programing languages. Main challenge is to solve discomfort and confusion related with test analyses and bring more effectivity and easiness into review process.

Would you like to support the development of ELQ?

Tell us about your case: https://denevy.eu/contacts

ELQ elements¶

Main Entity¶

SCENARIO¶

Short name or basic description what we should test.

Keywords and how to use them:
Keywords should be used for clear and simple definition necessary steps, actions and operation for SUT (System Under Test) testing.

PURPOSE
¶

Describing target, objective or goal of this test and why we are writing this.

GO { WHERE | HOW }
¶

Action to follow some link or application.
Basic step in many scenarios. Could be replaced with SNIPPETs for better understanding:

WHERE: should be used like definition for target, objective, goal, aim or destination
HOW: should be used for description of

OPEN { WHAT | HOW }
¶

Action used to open some entity e.g. file, link, application, snippet etc.
It is starting action and can be used multipli during the test scenario.
This action should be finished by CLOSE action.

CLOSE { WHAT | HOW }¶

Action used to open some entity e.g. file, link, application, snippet etc Ending action for OPEN. Should be used like last step of scenario.

DO: { ADD | USE | VALIDATE | TRY | DELETE | MODIFY }¶

Execution command used to describe exact action that should be accomplished by. Can by counted by numbers.

ADD: should be used to connect, attach, append, affix or link new or exist entity.
USE: should be used for function description like employ, utilize, make use of, dispose or exert.
VALIDATE: should be used to confirm, acknowledge, certify, validate, affirm or establish behavior or function.
TRY: should be used like description what should be investigated like inquire, research or question.
DELETE: should be used in NEGATIVE scenarios mostly for declaration of correct system behaviour usually in edge cases.
MODIFY: should be used for adjust, adapt, regulate, alter or fix some entity

DATA: { WITH | LIKE | LIMIT }¶

Data driven testing should be focused on elements and declaration for limitations and variability of described test scenarion with those keywords:

WITH: qualify data entity necessary to execution or scenario like valid login credentials or valid file attachment to upload.
LIKE: qualify data parameters used like role (who) or permission definition mostly.
LIMIT: qualify data parameters used for declaration of limitation, border, boundary, line or restriction.

VERIFY | CHECK: { CAN or CAN'T WHAT | CAN or CAN'T , WHERE | CAN or CAN'T , HOW } ¶

Used usually for declaration last steps in scenario of definition for Test Steps.

WHAT: qualify what should be verified and should be referenced for another definition like DO or DATA for example.
WHERE: declare where should be verification executed for example Testing Environment or another special conditions
HOW: qualify how should be verification executed based on condition like tester seniority, development process maturity etc.

CONDITIONs { IF, THEN, ELSE }¶

This form should be used everywhere in description for GO, DO, DATA and VERIFY.

IF: statement for multi-choice definition with conditional meaning. Most used in combination IF->THEN | ELSE
THEN: declare what should happen when IF statement is VALID.
ELSE: declare what should happen when IF statement is INVALID.

Cycles { REPEAT, UNTIL | DO, WHILE }¶