AIO Tests Glossary & Terminology
Before getting started with AIO Tests, let's go through over the most commonly used terms in the Test Management world and throughout this AIO Tests documentation. This guide explains some basic terminology and concepts that will be useful for users to understand AIO Tests in a better way.
This is a living document and will have constant updates which are driven by new features and product enhancements.
In this documentation, you’ll understand:
Glossary and Terminology
AIO Tests uses very simple and common terminologies, mostly the same as those used in the testing field so that users can seamlessly and efficiently work on the tool.
Terms | Definitions |
Test Management Tool | A tool developed to manage and keep track of all the activities in the process of software testing from start to end. |
Case | A case is a collection of conditions/ steps which are used to verify compliance against requirements. It also includes an expected result used to determine if the test case passes or fails. |
Steps | Test Steps are instructions or actions that need to be performed to execute a test case. In AIO Tests, test steps can be written in classic or BDD/Gherkin. |
Sets | A reusable set of cases which are frequently executed/ tested. Logical grouping for doing testing. A case may belong to multiple Sets. |
Cycle | Set of cases which need to be executed/ tested end to end for a testing goal. |
Run/ Case Execution | A Run is the execution/ instance of a Case. Cases can have multiple Runs within a cycle. |
Run Steps | Specific steps/ checks of the case followed for execution. If at least one step fails, then the case/ run will fail. Run steps contain execution information like status (pass/ fail), defects and attachments. Depending upon the reason behind the failure, an issue or a bug can be created for the development team to work on. |
Pre-Conditions | It is the initial conditions that must be ensured before executing the steps of the test case. |
Datasets | Rows of data (as key value pairs) that capture a set of data that drives the case. Multiple datasets in a case imply, the same case needs to be run with each dataset. Similar to Scenario Outline Examples in BDD |
Classic Case | Capture steps in the classical way of test authoring, with steps, data and expected results. |
Behavior-Driven Development (BDD) | BDD is a software development methodology that combines business interests and technical aspects. It creates test scenarios in a simple language which can easily be understood even by non-technical-savvy employees. |
Gherkin | Gherkin is a programming language where Cucumber developers can use native language to describe test cases. |
Feature Files | A file which stores feature, scenarios, and feature description to be tested. The feature file is an entry point, to write the cucumber tests and used as a live document at the time of testing. The extension of the feature file is ". feature" |
Clone | Create duplicates of various types of entities within an instance. Users can clone test cases, sets and cycles. |
Custom Field | Custom field is a non-standard field that the user can create to meet specific requirements. |
Test Status | Status to capture the current state of a case, can be Draft, Under Review, Published (Ready for Execution), Deprecated |
Execution Statuses | It is the status that testers assign to test cases by looking at their results while executing. Pass, Fail, In-progress, Blocked, and Not Run are default statuses. Users can also add custom statuses. |
Traceability | Define AIO Tests lets users trace linkages between various testing elements such as requirements, test cases, execution information and issues. It allows users to have a broader view of the effect of a correction or an identified issue. |
Priority | It defines the order in which one would resolve any given defect |
Release | Release defines a new version of the system under test. |
Component | A component is one of the smallest parts of a testing system that connects one part with another. A test case has three components: the purpose of the test case, the input required for the test case, and the expected result/response of the test case. |
Tags | Tags are keywords that let users classify cases in a more flexible and informal manner. It help users in searching the test cases. |
Estimated Effort | It is the expected time to complete the execution of the case. It can be entered in the given format Xh Ym. |
Automation Key | The automation key is used to match AIO Tests cases with an automated case. Normally created automatically when cases are getting created, while importing results. Value depends on the test results frameworks. |
Automation Testing | Automation testing have the test activities that are done by scripts and tools rather than manual work by a human. |
Automation Owner | Automation engineer who automates a case or is assigned to take automation ownership. |
Deprecated | A case can be moved to deprecated status, if the case is no longer relevant or the steps have become obsolete. |
Archive | The archive is a storage place for your test cases, which are currently not in use but may be needed in the future. |
Case Linking/Reuse | Entire cases can be used as steps in other cases, thus promoting reusability and easier scalability |
Import Cases | Simple map and use utility to import cases from other tools or XLS/CSV |
Project Admin | Project admin is a user who is normally assigned to a project created by the Site Admin and who has all permissions enabled on their assigned project. |
AIO Admin | AIO Administrators are Jira users who have been granted access to administer the AIO Settings for a particular project |
Ad-hoc Cycle | It is the default cycle. If no any cycle is set up for a version, then any test which gets executed is reported against an “ad-hoc” cycle. |
Bug/Defects | Bug is a discrepancy between an application/system desired behaviour and their actual behavior. |
Actual Results | It is the result that a tester receives after executing the test cases. After executing all test cases, the actual result is compared with its expected outcome. |
Defect Management | It is a process to identify, report, prioritize, track, and resolve defects in the earlier stages of the software development lifecycle. |
Gadgets | AIO Gadgets can be added to Jira Dashboards to see cross-project view or to track multiple metrics in one dashboard |
Burndown Chart | A Burndown Chart is a depiction of work left to do, and the time its completion will take. |
Audit Log | A chronological record of the deleted actions performed by different users on cases, sets, and cycles. |
API | API stands for Application Programming Interface. It acts as a source of communication between two or more computer applications. |
API Token | A generated authentication key, used to identify the user making API calls, from an external system. |
Support portal | A support portal is a self-serve web platform for customers to get help and resolve their problems online, it also helps the customers with their queries. |
Tickets | A ticket is an issue raised by a user or customer when they find a fault in software. It is mostly used to notify the coders about a bug that needs to be fixed. |
Jira Cloud | Jira Cloud is a group of cloud-based applications provided by Atlassian, designed to streamline project management and make the workflow better. Jira cloud instances normally have .atlassian.net in their host names |
Migration Method | It is the technique or approach which is used to transfer data from one system or environment to another . It can involve various methods like data integrations, bulk imports, or APIs. |
Test coverage | A technique that determines whether test cases are covering the application code and how much code is exercised when we run those test cases |
Defect Report | A defect report is a report issued addressing the problem of a case. It also explains how severe and urgent the problem is and how to find it. |
API integration | API Integration, also known as Application Programming Interface Integration, is a connection between two or more systems through their APIs that allows them to exchange data. |
TCM Applications | Test Case Management means creating, Organizing, managing, and tracking test cases while testing software. When an application does all of this, it is called a TCM Application. |
Accessibility Testing | Also known as 508 Compliance Testing, accessibility testing is a type of software testing that helps to discern how the software works from the point of view of a disabled person. |
Severity | Also known as Bug Severity, Severity is the amount of impact a defect creates on the outcome of a test run. |
Test Summary Report | Also known as Test Closure Report, a test summary report is a document that contains a summarized version of the test outputs and evaluations. It is mostly used to give an overview of test outcomes. |
CI/CD (Continuous Integration and Continuous Delivery) | CI/CD is the practice of automating the integration of code changes from multiple developers into a single codebase. |
Jenkins | Jenkins is an open-source automation server that runs in servlet containers such as Apache Tomcat, and it helps automate the parts of software development. |
Test Script | The set of instructions that are necessary to perform and test in the process of software testing is called a Test Script. |
JUnit | JUnit is a unit testing open-source framework that helps you write more reliable and testable code for the Java programming language. |
TestNG | A testing framework inspired by JUnit and NUnit, TestNG is a framework created for the Java programming language. It covers a wide range of test categories such as end-to-end, unit, Integration, functional, etc. |
Cucumber | Equipped with a parser language tool called Gherkin, Cucumber is a software tool that enables you to use BDD (Behaviour Driven Development). |
Robot | Robot is an open-source test automation framework based on Python. It can support Acceptance Test-Driven Development (ATDD), Behavior-Driven Development (BDD), and Robotic Process Automation (RPA). |
NUnit | NUnit is a unit-testing framework for automated testing of components in Microsoft .Net applications. |
Test Driven Development | A developer-centric software development process in which the software requirements are made into test cases to develop the software through testing cases. |
Open AI | Open AI is an AI research and deployment company founded in the year 2015. It gained fame after making revolutionary AI tools like Chatgpt, Sora and DALL-E. |
Permissions | Access controls setup at user or group levels to control who has readonly or write access over functions in AIO Tests, like creating entities, deleting entities, contact support etc |
Re-Indexing | A process to change the testcase keys, squashing empty spaces in the sequence of keys. Helps to negate the effects of deletion of cases on case keys. |
Key Entities
For a better understanding of Cases, Sets, and Cycles on AIO Tests, we have used Venn diagrams. It helps you to understand the key entities of the test management tool.
Cases
Sets
Cycles
Workflow Diagram
With AIO Tests, Cases can be created and mapped with Jira requirements. Once you create a case, you can merge them logically to form a Set. The Cases can also be added to Cycles for execution. With the help of Cycles, Reports can be generated and progress can be tracked to verify mapping with the Jira Requirements. This forms a testing cycle.
For further queries and suggestions, feel free to reach out to our customer support via help@aiotests.com.