Прокачайся в код-рев’ю: для перших 50 учасників — курс безкоштовний

час читання: 3 хв

Скажи щось айтішною: тестувальник

Баг, мітинги, дейлі, борд, тікети та фіча — цим та іншим термінам дала «людське» пояснення Senior Software Testing Engineer Ірина Гольцева спеціально для блогу Anywhere Club.

Senior Software Testing Engineer Ірина Гольцева

— В ІТ часто говорять поміссю мов. Коли я вперше влаштувалась працювати в ІТ-компанію, я майже не розуміла діалогів колег, — згадує Ірина, — На той час я уже добре вміла тестувати, але не звикла спілкуватися цим міксом англійської, російської та айтішної. Було дуже складно та образливо. Розуміючи цю «біль», хочу поділитися набором слів та виразів, які допоможуть відчувати себе на одній хвилі із досвідченими колегами.

Як говорить тестувальник

Слово, яке відоме кожному тестувальнику, — баг.

Баг — це невідповідність поведінки застосунка запитам замовника. Іще можна сказати, що баг — це неочікувана для користувача, небажана поведінка додатка чи програми.

Окрім багів тестувальники часто пропонують команді «імпрувменти» — пропозиції щодо покращення сайту чи програми.

— Знаходити баги — одне із основних завдань тестувальника. Однак найголовніше, і найбільша відповідальність QA, — забезпечення якості застосунка в цілому. Для цього тестувальники не лише шукають, але і відвертають баги, придумують сценарії тестування, створюють тестові дані, пишуть тестову документацію, автоматизують процес регулярної перевірки основних функцій додатка. Якщо тестувальник професіонал, то користувач не натрапить на краш (від англійського crash — аварія чи крах), не зустрінеться із непередбачуваними кнопками і неодмінно повернеться на сайт знову.

Кожен день на тебе чекають мітинги (вони ж міти), коли, сінки та дейлі.

  • Meeting — це робочі наради. Зазвичай назначаються наперед і відображаються в календарі. Можна отримати інвайт (запрошення) на мітинг чи зашарити лінк (поділитися посиланням) на мітинг зі своїми колегами.
  • Call — зідзвонювання з одним чи кількома колегами. Часто можна почути «пробач, у мене терміновий кол, мені треба відповісти».
  • Sync — скорочення від synchronization. Це той же мітинг чи кол. Зазвичай кажуть «давай сінканемося з цього приводу окремо». Що означає «давай синхронізуємо наші знання і розуміння щодо цього питання».
  • Daily (скорочення від daily meeting) — щоденна нарада команди. Зазвичай проходить зранку. Але буває по-різному.

На мітингах ви будете обговорювати борд, тікети, апдейти.

  • Board — це робоча дошка чи робоче місце кожного члена команди окремо і всієї команди в цілому. Найчастіше використовують застосунок Jira, щоб трекати (відстежувати) свою щоденну роботу. Залежно від проєкту, можна використовувати, наприклад, Scrum board або Kanban board. У кожному випадку, дошка має вигляд набору завдань, відповідальних і статусів.
  • Ticket — це і є саме завдання, виражене у письмовій формі. Тікети мають вигляд стікерів на дошці. Вони можуть містити дуже велике завдання (епік), чи завдання поменше (сторі), чи ще менше (таск). А можуть містити опис бага. Найголовніші для тебе тікети ті, що мають статус RFQA (Ready for QA).
  • Update — це новини. Зашарити апдейти означає «поділитися новинами чи статусом якогось завдання».

Заверифаїти тікет означає перевірити його і впевнитися, що все працює як слід.

— Якщо, наприклад, ви перевірили баг-тікет, і все працює як слід, це означає, що баг пофіксили (від слова fix — ремонтувати, лагодити). Якщо після перевірки видно, що баг все ще там, то можна реопнути тікет (від слова reopen — повторно відкрити) і повернути тікет розробнику.

Інколи не вдається заверифаїти баг-тікет тому що, наприклад, у вас немає прав доступу в тестове середовище чи немає відповідного девайса для перевірки. У разі, якщо щось заважає перевірити тікет, можна його заблокувати (змінити статус тікета на Blocked) доти, доки проблема не буде вирішена.

Інколи ми тестуємо якусь цікаву сторі (story) і створюємо екзотичний сценарій, за якого застосунок поводиться погано (є баги або не до місця випливають якісь попередження). Тестувальнику може здаватися, що це жахливо і треба терміново це пофіксити. Але бізнес-аналітик (він же ВА) або продакт-овнер (він же РО) може сказати «нічого страшного, це corner case — відкладіть поки що в backlog». Що-що?! — думаєте ви. Який-такий кейс?! Куди його відкласти?! Насправді колега сказав наступне: «Цей сценарій — винятковий. Користувач навряд чи зустрінеться із цим багом. Можна поки що відкласти його і помістити в скарбничку багів і завдань, які чекають на свою чергу».

«Баг або фіча»

— Часто між розробником і тестувальником виникають суперечки на тему «баг або фіча». Якщо ви, до прикладу, знайшли неочікувану поведінку додатка, то можна прийняти його за баг. Але девелопер може заперечити, що все виконано відповідно до вимог. У такому випадку, щоб розв’язати суперечку, треба керуватися аксептанс-критеріями (acceptance criteria) відповідної сторі. Аcceptance criteria — набір вимог, розроблених ВА. Фіча (feature) — це особливість застосунка, якась опція, розроблена спеціально (не баг).

Коли якусь нову функцію додатка уже доробили (дописали код, перевірили її), кажуть, що фічу заімплементили (implemented).

Як все знати

— У ході своєї роботи тестувальники застосовують різноманітні види, методи, рівні, техніки тестування. Залежно від проєкту і поточних завдань можна тестити локалізацію, компетібіліті, аксесебіліті і так далі. Можливо, доведеться вручну зробити регресію або смоук тест після релізу, — ділиться Ірина, — Усі ці слова, безперечно, мають бути частиною професійного лексикону. Однак в двох словах розказувати про це —неправильно. Замість цього я пропоную дослідити спеціалізовані матеріали та курси і засвоїти ці поняття самостійно. Вони точно знадобляться на співбесіді.

Знайти відповідний курс