IT language of the Tester

— In IT, people often speak a mixture of languages. When I first started working in an IT company, I rarely understood the dialogues of my colleagues. By that time, I was good at testing, but I was not used to communicating in the mixture of English, Russian, and IT. It was very difficult and frustrating. Understanding this "pain," I want to share a set of words and expressions that will help you be on the same wavelength as your experienced colleagues.

How a tester communicates

A word that every tester knows is bug.

— A bug is an inconsistency between an application's behavior and the customer's requirements. We can also say that a bug is an unexpected, undesirable behavior of an application or program.

In addition to bugs, testers often bring to the team's attention "implements" — suggestions for improving a site or program.

Finding bugs is one of the main tasks of a tester. The main task and responsibility of QA, however, is to ensure the quality of the application as a whole. To do this, testers not only look for bugs, but also prevent them, come up with test scenarios, create test data, write test documentation, and automate the process of regularly checking the application's main functions. If the tester is a professional, the user will not encounter a crash, will not encounter unpredictable buttons, and will inevitably return to the site again.

Every day you are expected to have meetings, calls, syncs, and dailies.

• A “meeting” is a business meeting. They are usually scheduled in advance and marked on the calendar. You can get an invitation to a meeting, or you can share a link to a meeting with a colleague.
• A “call” refers to a phone or video communication with one or more colleagues. Often, you may hear "sorry, I have an urgent call, I have to take this”.
• “Sync” is short for synchronization. It's the same as a meeting or call. It's common to say, "let's sync on this one separately." Which means "let's synchronize our knowledge and understanding on this issue."
• “Daily” (short for daily meeting) refers to a daily team meeting. It usually takes place in the morning, but this may vary.

At meetings you will discuss the board, tickets, updates.

• A “board” is a working board or workspace for each team member individually and for the team as a whole. Most often, people use the Jira application to track their daily work. Depending on the project, it is possible to use a Scrum board or Kanban board. In any case, the board looks like a set of tasks, responsibilities, and statuses.
• A “ticket” is just a task, expressed in written form. Tickets look like stickers on the board. They may contain a very large task (epic), or a smaller task (story), or an even smaller task. Or they can contain a description of a bug. The most important tickets for you are those that have status RFQA (Ready for QA).
• An “update” is news; recent developments. Sharing updates means "to share the news or the status of a task.”

“Verifying the ticket” means checking it and making sure everything is working as it should.

— If, for example, you have checked the bug ticket, and everything works as it should, then the bug is fixed. If, after checking, you see that the bug is still there, you can reopen the ticket and return it to the developer for additional work.

Sometimes, it is impossible to check the bug ticket because, for example, you do not have access rights to the test environment or do not have the appropriate device for testing. If something prevents you from checking the ticket, you can block it (change the status of the ticket to Blocked) until the problem is solved.

Sometimes, we test an interesting story. We invent an exotic scenario in which the application behaves badly (there are bugs or some inappropriate warnings popping up). The tester may think that this is awful, and that it is urgent to fix the problem. But the business analyst (BA) or product manager (PM) may say "no big deal, this is a normal case — put it in the backlog for now." What-what?! Put it where?! In fact, the colleague may be saying: "This scenario is rare. The user is unlikely to encounter this bug. You can put it aside for now and put it in the piggy bank of bugs and tasks that are waiting to be dealt with later."

Bug or feature

— There is often an argument between the developer and the tester about whether something is a bug or a feature. If you find, for example, an unexpected behavior of an application, you may consider it a bug. But the developer can argue that everything is working as required. If this is the case, the acceptance criteria of the respective story should be used to resolve the dispute. “Acceptance criteria” is a set of requirements developed by a BA. A “feature” of an application is some option that is specifically implemented (not a bug).

When a new feature is finished (code is written, tested), the feature is said to be implemented.

How to know everything

— In the course of their work, testers use different types, methods, levels, and techniques of testing. Depending on the project and current tasks, you can test localization, compatibility, accessibility, and so on. You may have to manually do a regression or smoke test after release. All these words should definitely be part of your professional lexicon. I suggest studying specialized materials and courses and mastering these concepts yourself. They will come in handy in a job interview.