Testing Fundamentals

TAL (Test Analyses Language)

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.

ELOQUENTAL

Main Entities:

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.

CONDITION { 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.

CYCLE { REPEAT, UNTIL | DO, WHILE }

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

  • REPEAT -> UNTIL: declare activities to REPEAT till condition(s) UNTIL are not fulfilled.
  • DO -> WHILE: declare activities to DO till condition(s) WHILE are VALID.

Example 1

Description

  • PURPOSE OF THIS Test case Create, Read, Update, Delete Task in the edit form
  • CHECK if created Tasks/bugs are displayed correctly on the Issues main page
  • GO to the Projects/ select Project / open Module Issues/ open Task edit form
  • CHECK visual UI fits with definition in small/big view
  • DO Edit Task name with max.255 characters
  • IF Edit Task with more than 255 characters - negative
  • DO Refresh & Share
  • DO Created clone -> DO Delete clone -> DO Restore clone
  • DO Delete Task -> DO Restore Task
  • DO Modify Labels/ Description/ Status/ Priority
  • DO Link Main Entity -> DO Unlink Main Entity
  • DO Link Roadmap -> DO Unlink Roadmap
  • DO Modify estimated time & Add spent time & Due Date
  • DO Modify Author/ Assignee/ Collaborators
  • DO Write a comment -> DO Edit comment
  • DO Delete comment -> DO Restore comment
  • DO Link new/created Issues -> DO Edit, clone child entities
  • DO Switch between pages in the +Select or Add Issues (Task or Tags) tab
  • DO Link new/created Test -> DO Edit, clone child entities
  • DO Switch between pages in the +Select or Add Test Case tab
  • DO Change Rows per page
  • DO Unlink Issue / Unlink Test

Test data

  • ENVIRONMENT: Training
  • LIKE: Super Admin | user with permissions | user without permissions
  • Browser: Mozilla | Chrome | Safari

Expected result

This test case verifies that

  • Super Admin: Can DO CRUD Task edit form
  • User with permissions: Can DO CRUD Task edit form
  • User without permissions: Can NOT DO CRUD Task edit form

Test steps

  • OPEN modul Issues -> Check created Tasks/Bugs
  • OPEN Task edit form
  • EDIT Task name under/over 255 characters
  • DO Refresh page
  • DO Delete -> Restore Task
  • DO Share page
  • DO Create Clone -> Do Modify Clone
  • DO Delete -> Restore Clone
  • DO Modify Labels/ Description/ Status/ Priority
  • DO Link Main Entity & Roadmap -> Unlink them
  • DO Modify estimated time & Add spent time & Due Date
  • DO Modify Author/ Assignee/ Collaborators
  • DO Write a comment -> Do Edit -> Do Delete -> Do Restore
  • DO Switch between pages in the +Select or Add Issues (Task or Tags) tab
  • DO Link new/created Issue -> Do Unlink Issue (Task & Task )
  • DO Modify Status Priority/ Labels /Owner by child entities (Issues)
  • DO Change Task to Task/ Bug to Bug
  • DO Link new/created Test -> Do Unlink Test
  • DO Modify Status Priority/ Labels /Owner by child entities (Test)
  • DO Switch between pages in the +Select or Add Test Case tab
  • DO change Rows per page

Example 2

Description

  • PURPOSE OF THIS Test case -> Create, Read, Update, Delete Story and
  • DO Bulk Edit on the Design main page
  • GO to the Projects / select Project / open Module Design
  • CHECK visual UI fits with definition
  • CHECK created Story & Epic are displayed
  • DO create new Story
  • DO edit Story->Epic->Story
  • DO click for MODIFY Status/ Priority/ Label
  • DO delete Story->DO restore Story
  • DO change Rows per page
  • IF logged as SuperAdmin THEN can Full Bulk Edit

Test data

  • ENVIRONMENT: Training
  • LIKE: Super Admin | user with permissions | user without permissions
  • Browser: Mozilla | Chrome | Safari

Expected result

This test case verifies that

  • Super Admin: Can DO CRUD Story and Bulk Edit
  • User with permissions: Can DO CRUD Story | Can NOT DO Bulk Edit
  • User without permissions: Can NOT DO CRUD Story neither Bulk Edit

Test steps

  • OPEN modul Design
  • CREATE New Story via +Design
  • CHANGE to Epic-> back to Story
  • EDIT Status/ Priority/ Label
  • DELETE at least 5 Stories
  • CLICK Show With Deleted
  • RESTORE all Stories
  • CHANGE Rows per page
  • IF you are logged in as SuperAdmin, THEN execute full Bulk Edit