In previous articles, we shared some handy tips such as What shall a novice QA Automation Engineer read and watch. Today, we'd like to talk about concepts and terminology understanding which will perceptibly speed up your development in the competence you've chosen.

So, we asked Olena Kramar, Lead Software Test Automation Engineer, to explain in layperson’s terms ten automated testing concepts that every beginner should know.

1. Quality gate

Quality gates, as the term implies, are the milestones set at specific points in the process, to "slow" the progress of code that does not meet quality criteria. If the code passes the check, it moves on to the next gate. And what happens when some gates block it? Imagine the frame of a metal detector in airports: if you have prohibited items on you, the device beeps. Quality gates do the same thing — they signal the detected problem to testers (or to all other specialists involved in the process: manual testers, project managers, etc.) through a specified communication channel, i.e., e-mail or messengers used by the team.

2. Release Candidate (RC)

It is the last step before releasing a software product. The release candidate is the build of code that is considered final and can potentially go into production. The release candidate undergoes thorough testing; it can be reassembled if testers discover any defects or errors. Several release candidates are typically made available throughout the release, each successive one being "fixed and upgraded". At this stage, it is crucial to eliminate as many flaws as possible before the product reaches end users. Keep in mind that the cost of each bug found after the product release multiplies many times over and can result in losses for the customer, both financial and reputational.

3. Log

The log, a trusty assistant of the automation tester, stores the details of the tests in chronological order. The information, which is recorded with a specialized tool, the logger, often has a rigid structure. And the log itself can have different formats: from a simple text document to a complex system with its own database and clustering algorithms. It all depends on the project's needs, imagination, and budget.

4. Stack trace

A stack trace is a detailed report of individual stack frames at a certain point in time during code execution. It usually tracks the number and sequence of methods called. This data helps testers pinpoint the location and origin of errors down to the lines and characters of the source code. End users can also see stack traces as part of the error message.

5. Regression testing

This type of testing should follow any changes to the previous version of the development product: from the implementation of new functionality to changes in the visual design. Regression testing ensures that the new functionality has not introduced new errors or affected other parts of the product and will not cause unpredictable behavior. Often this term also refers to the process of preparing a Release Candidate. In that case, regression testing entails planning, providing information about the scope and types of testing, input data, actual testing (manual or automated), compiling a report on the results and bugs (if any were found), and fixing bugs and retesting them.

6. Breaking change

A rather broad concept that could involve moving the "Login" button on the home page or significantly restructuring the product architecture. Any change that can complicate the tester's routine is considered critical. Even the slightest, from the customer's or end user's point of view, manipulation (for example, changing the color of the "Order" button) can wreak havoc on the entire auto-test system. Why is this happening? Auto-tests are essentially the same software products as any application. You can forget about properly validating the product's behavior if auto-tests do not incorporate the latest business requirements. As a result, test automation engineers should be informed about all critical changes.

7. Non-functional requirements (NFR)

Auto-test has requirements that are not directly related to the type and method of validations it performs. Non-functional requirements are criteria by which the quality of auto-tests is evaluated. These are indicators critical to the framework: speed, number, percentage of source code or requirements covered by tests, etc.

8. Branch Strategy

Branch strategy describes the team's approach to the shared code development: a sort of agreement that outlines the stages the code must successfully pass before being merged into the master branch. Each "branch" splits off from the main one to perform a specific task and then rejoins it again. The branching strategy allows the team to cut down on time and improve the effectiveness of their collaboration.

9. Code Refactoring

Code refactoring is the process of restructuring the code, which does not change its functionality, but significantly changes how it works. Refactoring aims to make the code simpler, clearer, and faster to increase test automation engineers' productivity. Refactoring also boosts the team's morale since everyone prefers shiny new tools to old rusty ones.

10. Code Stabilization

Another type of code improvement is called stabilization. It is the process of debugging code so that its execution leads to the same (stable) result. Usually, it consists only in identifying and eliminating a certain malfunction and does not mean a significant rework of the code.

Code stabilization and refactoring can be illustrated with a simple everyday example. Think of a wardrobe. It serves its primary purpose as a piece of furniture by shielding items from dust and dirt and giving the appearance of order in the room. Inside it, however, creative chaos may reign. In this scenario, stabilization would mean arranging things on shelves to prevent the closet door from opening at the most inconvenient moment, for example, during an online interview, and the clothes ending up on the floor in the middle of the room. And refactoring would mean sorting clothes by season, carefully putting them on shelves and in special organizers, etc.

Did we spark your interest? It is only the tip of the iceberg of what you can learn at ЕPАМ Test Automation training programs.