What Are They Talking About? Technical Vocabulary Basics for Testing & Release
Tech, localization, and global strategy - decoded.
Have you ever heard a conversation about “pushing to prod,” “running tests,” or “checking the sandbox” and felt totally lost? Maybe you nodded along, hoping context clues would fill in the blanks (we’ve all been there). These phrases are common in agile, engineering-heavy environments, but they can sound like another language when you're new to tech or coming from a non-engineering background.
If that’s you, I’m writing this mini-series is for people like you! In this series I’m breaking down common technical vocabulary into clear, beginner-friendly explanations. It’s 100% beginner friendly, no judgment (if you need additional clarification on any of these please feel free to reach out to me). Whether you're in localization, product, design, or any cross-functional role, building your technical vocabulary helps you ask better questions, catch important details, and feel more confident in fast-moving conversations!
Each edition in this mini-series will highlight a group of words or concepts and explain how they show up in real workflows. In the last edition, we talked about Git, GitHub, repos, branches, PRs, and more. Today, we’re diving into testing and release vocabulary. These are the terms you'll hear when teams are building, reviewing, testing, and releasing features in an agile environment. If you have suggestions for future themes, I’d love to hear them!
Ok, let’s get started:
QA (Quality Assurance)
QA stands for Quality Assurance. It’s a process (and often a team) that ensures the product works as expected and meets quality standards before it’s released.
→ Example: "QA found a bug in the login flow, so we sent it back to the dev team."
Test Case / Test Script
A test case (or test script) is a specific set of steps used to test whether a piece of functionality behaves correctly. It often includes inputs, actions, and expected outcomes.
→ Example: "We wrote a test case to check if users can reset their password successfully."
Let’s say you wanted to write a test script for a localization bug, you would start by clearly describing the issue (ex: what language it affects, where it appears - such as a button label, error message, or layout), and what the incorrect behavior is. Then, define the expected behavior: what the correct translation, formatting, or layout should be. In the script, outline the steps to reproduce the bug (e.g. “Set app language to French > Navigate to Settings > Observe label on the Save button”), and include screenshots if helpful. Finally, specify the test conditions (like browser or device), and the pass/fail criteria (what must be true for the issue to be considered fixed). If you're working with engineers or QA, share the test script in a shared doc, ticket, or test case management tool so they can validate the fix when it's deployed.
Unit Test
A type of automated test that checks a very small part of the code (usually a single function or component) to make sure it works as intended.
→ Example: "The build failed because one of the unit tests didn’t pass."
Build
A build is a version of an app or website that has been packaged and compiled so it can run. Think of it as a “snapshot” of the code at a certain point in time, bundled up so it can be tested or released. When developers make changes to the code, they create a new build to see how it works. This might be sent to testers, pushed to a staging environment, or even deployed to production.
→ Example: "We just got a new build from the dev team. Can you check if the Japanese translations are showing up correctly?"
Integration Test
These tests check how different parts of the system work together. For example, does the login function still work when connected to the database?
→ Example: "The unit tests passed, but we found an issue during integration testing."
Regression Test
A test to make sure that something that used to work still works after you made changes. Bugs have a sneaky habit of coming back, and regression tests help catch that.
→ Example: "We ran regression tests after updating the payment flow."
Manual Testing vs. Automated Testing
Manual testing means a person is clicking through the app and checking if things work.
Automated testing means a computer runs tests automatically using scripts.
→ Example: "We’re using automated tests for the core features but still doing manual QA for edge cases."
Test Environment / Staging
A test environment (often called staging) is a copy of the app or website where teams can safely test changes before going live. It’s like a dress rehearsal for production.
→ Example: "The fix is deployed to staging, so QA can check it before we push to prod."
Deploy / Deployment
To deploy means to release code to an environment (like staging or production). It’s how new features, bug fixes, or updates get published.
→ Example: "We’ll deploy the new settings page to production tomorrow."
CI/CD (Continuous Integration / Continuous Deployment)
CI/CD is a set of practices and tools that help teams release software faster and more safely.
Continuous Integration (CI): Developers regularly merge their code into a shared repo, and automated tests run every time.
Continuous Deployment (CD): Code changes that pass tests get automatically released to production.
→ Example: "We use CI/CD so every change goes through automated testing before deployment."
Note: If you’re a paid subscriber, check out this Deep Dive I wrote for you on Cloud Infrastructure and Dev Ops - including how it applies to localization (+ cheat sheet of technical questions to ask to be a better partner to engineering teams)!
Release Candidate (RC)
A release candidate is a version of the software that might be ready for production - if it passes final testing. It's like saying, “This might be the one!”
→ Example: "RC2 is out for review. If it passes QA, we’ll ship it."
Ship / Ship It
To ship something means to release it to users, or to make it live. It can refer to releasing a feature, a fix, an update, or even an entire product. “Ship it” is often used informally as a way to say “let’s release this!” or “we’re done here!” It’s a celebratory phrase that signals the work is ready to go out into the world.
→ Example: "We fixed the language switcher bug, let's ship it in the next release."
Tip: Shipping doesn’t always mean it’s going straight to every user right away. Sometimes teams use staged rollouts, feature flags, or limited environments to control how and when features are shipped.
Rollout
A rollout is the process of gradually releasing a feature to more users. Teams often do this in stages to catch issues early.
→ Example: "We’re rolling out the new design to 10% of users to monitor performance."
Hotfix
A hotfix is an emergency fix pushed quickly to resolve a critical issue in production. It’s usually high-priority.
→ Example: "We deployed a hotfix for the crash affecting iOS users."
Feature Flag / Toggle
A feature flag lets teams turn features on or off without deploying new code. Great for rollouts, experiments, or quickly disabling buggy features.
→ Example: "The new dashboard is behind a feature flag while we finish testing."
Smoke Test
A quick, basic set of tests to check that the most important parts of an app are working after a change. Think of it like: "Is the building still standing?"
→ Example: "We ran a smoke test after deployment to make sure login and checkout still work."
Sandbox
A sandbox is a safe, isolated environment where teams can test code, features, or configurations without affecting real users or data. It’s often used for experimenting, prototyping, or validating localization and UI changes before they go to staging or production.
→ Example: "The new payment flow is in the sandbox if you want to test translations before we push it to staging."
Tip: Sandboxes can be especially useful in localization! Sometimes you need to test right-to-left languages, long strings, or translated content in a place that won’t break the real app. If your team has one, use it!
Bug vs. Issue vs. Ticket
Bug: A flaw in the code causing something to break or behave unexpectedly.
Issue/Ticket: A formal way to track a task or problem, usually in a tool like Jira, GitHub Issues, or Asana.
→ Example: "I filed a ticket for the bug QA found in the signup flow."
Automated QA Testing
Automated QA (Quality Assurance) testing means using software tools to automatically run tests that check whether your app or website is working as expected. These tests can cover anything from “Does the login button work?” to “Do all the pages load properly in multiple languages?”
→ Example: "Our automated tests caught a bug where the French version of the site wasn’t loading the help page."
Tip: Automated tests are fast and repeatable, which is great for catching bugs early. But they don’t always catch things like awkward translations or broken layouts in other languages, so pairing automated tests with human checks is ideal.
Bonus: here are four common types of automated QA tests for localization, all of which can be integrated into CI/CD pipelines to catch issues before release:
1. Missing Translation Keys
Goal: Ensure all supported locales have the same keys as the source language file (usually English).
Why it matters: Prevents fallback text or UI crashes due to missing strings.
What it checks: Every key in the base language file is present in every localized file.
Example issue caught: "Button label appears as welcome.button.label instead of 'Bienvenue' in French."
2. String Length Overflow
Goal: Detect when a translated string is too long for its UI container.
Why it matters: Languages like German or Finnish often expand text length, which can break layout or truncate critical information.
What it checks: Flags translations that exceed a safe character threshold or overflow visually during automated UI rendering.
Example issue caught: "The Spanish version of a settings label wraps awkwardly and breaks the layout on mobile."
3. Hardcoded Strings Detection
Goal: Identify UI text that is not coming from the translation system (i.e., written directly in code).
Why it matters: Hardcoded strings can’t be translated and often get missed.
What it checks: Scans source code for literal strings (like "Save" or "Cancel") instead of translation keys.
Example issue caught: "The word 'Next' in a flow is hardcoded in English and doesn’t get translated for Japanese users."
4. RTL (Right-to-Left) Layout Validation
Goal: Ensure UI elements flip correctly for RTL languages like Arabic or Hebrew.
Why it matters: If layout doesn’t mirror, the interface is confusing or unusable.
What it checks: Confirms the dir="rtl" attribute is applied, and that key layout components (navigation, text alignment, icons) adjust accordingly.
Example issue caught: "Navigation icons stay on the left instead of flipping to the right in Arabic."
These tests can be implemented with tools like Selenium, Cypress, or Playwright (for UI testing), or built into custom scripts that run during CI pipelines.
Ok, so how do these pieces fit together?
Ok, let’s say you’re working on a global website project:
You create a repository on GitHub to store your project files.
Each team member clones this repository to their own computer to work on it locally.
To test a new feature, you create a branch so your changes don’t disrupt the main code.
You make your updates, commit them, and open a Pull Request (PR) for review.
The team reviews the PR, and if everything looks good, they merge it into the main branch.
The updated code is deployed to a sandbox, where the localization team tests translated content.
Then it goes to staging, where automated QA tests check for issues before the feature is released.
Finally, the code is deployed to production, woohoo, real users can now see and use it! 🎉
I hope you walk away from this post feeling more confident in your technical vocabulary! You don’t need to be an engineer to understand this flow or contribute to it. But knowing the words lets you ask better questions, plan more effectively, and show up with confidence in technical spaces.
What’s Next? And subscribe for Deep Dives + *even more* focused resources
Next week I’ll share How I use AI as a Localization Product Manager + Tools I recommend (I’m super excited to share this one)!
And then on July 7th I will do a i18n Deep Dive for paid subscribers walking you through how to prep your teams and solve for for RTL (“right to left” or bidirectional) from a technical partner perspective. Subscribing is the cost of grabbing me a coffee each month, and it helps justify me spending a few Saturday afternoons creating these structured lessons.