Soft скіли тестувальника: комунікація, аналітичне мислення, quality advocacy
Чому soft скіли вирішують кар'єру
Технічні навички відкривають двері на співбесіду. Soft скіли визначають чи залишишся в команді і чи будеш рости. Senior QA — це не той хто пише найкращі тести, а той хто робить якість продукту системною.
«QA — не той хто ловить баги. QA — той хто не дає їм з'явитись.»
1. Комунікація
Чіткі баг-репорти без конфліктів
Баг-репорт — технічний документ, не скарга і не звинувачення. Мета: розробник відтворить і виправить, а не захищатиметься.
Що робить репорт конфліктним:
❌ «Знову зламали оплату! Це вже третій раз!»
❌ «Ваш код не працює»
❌ «Як можна було таке задеплоїти?»
❌ «Очевидна помилка, легко знайти»
Нейтральний технічний тон:
✅ «Знайдено: кнопка Оплатити активна при порожньому кошику»
✅ «Після оновлення v2.15 з'явилась регресія в модулі оплати»
✅ «Відтворюється на 100%, скріншот і HAR файл додані»
Спілкування з розробниками
QA і розробники — союзники в боротьбі за якість, не супротивники. Баг — проблема системи, не людини.
Під час code review:
❌ «Ти не перевірив edge case»
✅ «Я бачу що не покрито сценарій з порожнім кошиком —
чи потрібен тест або валідація на рівні компонента?»
❌ «Це неправильно зроблено»
✅ «Якщо відправити запит без поля name, сервер повертає 500 —
можливо варто додати валідацію і повертати 422?»
При обговоренні багу:
❌ «Я вже казав про це»
✅ «Схожа проблема була в BUG-142 — можливо та сама root cause?»
❌ «Чому це ще не виправлено?»
✅ «Цей баг блокує 3 тест-кейси — коли приблизно можна очікувати фікс?»
Спілкування з менеджерами і продуктом
Менеджеру не потрібні технічні деталі — потрібна відповідь на «чи можемо ми релізити?»
Технічний звіт для розробника:
"Faithfulness score 0.78, нижче порогу 0.85.
3 тест-кейси в модулі auth заблоковані через
ENV змінні в CI. Stack trace: [...]"
Для менеджера:
"Знайдено 3 критичних баги в модулі оплати.
Реліз не рекомендую до їх закриття.
Оцінка виправлення: 1-2 дні.
Решта функціональності — готова."
Формула звіту для менеджера:
Статус: [готово / не готово / з застереженнями]
Що знайдено: [цифри — N критичних, M major, K minor]
Ризик релізу: [низький / середній / високий]
Рекомендація: [реліз / відкласти / реліз з workaround]
Що потрібно: [N днів на виправлення / прийняти ризик]
Асинхронна комунікація (Slack, Jira)
❌ Погано:
"Є питання"
[чекає відповіді]
"Щодо тесту"
[чекає]
"Він не проходить"
✅ Добре:
"Привіт! Тест AUTH-TC-042 не проходить у staging.
Помилка: 401 при валідному токені.
Відтворюється з 9:00, можливо пов'язано з деплоєм.
Можеш подивитись коли буде час? Не терміново."
Правило повного питання: один меседж — повний контекст. Не змушуй людину витягувати інформацію по частинах.
2. Аналітичне мислення
Задавати правильні питання
Хороший QA не просто виконує тест-кейси — він думає що може піти не так і чому.
П'ять питань перед тестуванням:
1. «А що якщо...?»
Поле приймає числа → що якщо ввести від'ємне? Нуль? Дробове?
2. «Хто ще залежить від цього?»
Зміна в кошику → чи впливає на оплату? На знижки? На сповіщення?
3. «Що відбувається на межах?»
Ліміт 100 символів → що при 99? 100? 101?
4. «Що якщо мережа повільна або падає?»
Відправка форми → що при timeout? При частковій відправці?
5. «Як це виглядає для різних ролей?»
Адмін бачить всіх → а якщо звичайний користувач відкриє URL?
Мислити як користувач і як зловмисник
Два режими мислення для хорошого QA:
Режим користувача:
«Я поспішаю, натискаю кнопки хаотично»
«Я скопіював-вставив текст з Excel — є зайві пробіли»
«Я відкрив дві вкладки одночасно»
«Я натиснув Back після оплати»
«У мене повільний інтернет»
Режим зловмисника:
«Я вставляю SQL у поля пошуку»
«Я підставляю чужий ID в URL»
«Я надсилаю запит без авторизаційного заголовку»
«Я змінюю ціну в payload перед відправкою»
«Я відкриваю 1000 вкладок з запитами»
Аналіз першопричин (Root Cause Thinking)
Ситуація: тест впав
Слабкий QA: "Тест впав, баг є, відкрив тікет"
Сильний QA задає питання:
→ Чому впав тест?
"Кнопка Submit не активна"
→ Чому не активна?
"Форма вважає дані невалідними"
→ Чому невалідними?
"Email validation regex занадто строгий"
→ Чому regex змінився?
"Оновили бібліотеку валідації"
→ Що ще використовує цю бібліотеку?
"Ще 5 форм у системі"
Результат: один баг-репорт покриває 6 форм,
а не 6 окремих тікетів.
Пріоритизація — що важливо, а що ні
Матриця: Вплив × Ймовірність
Висока ймовірність | Низька ймовірність
Великий вплив: КРИТИЧНО | Важливо планувати
Малий вплив: Виправити колись | Ігнорувати
Приклад:
КРИТИЧНО: оплата ламається у 30% юзерів
Важливо: рідкісний crash при upload великого файлу
Пізніше: орфографічна помилка у футері
Ігнор: пікселів відступ в незайманому розділі
3. Quality Advocacy — якість як стратегія
Що таке shift-left
Традиційно: розробники пишуть код → QA перевіряє наприкінці. Знайдений пізно баг коштує дорого.
Shift-left: QA бере участь з першої фази.
Вартість виправлення дефекту:
У вимогах: $1
У дизайні: $10
У коді: $100
У тестуванні: $1,000
У продакшені: $10,000+
Як виглядає shift-left на практиці:
Sprint Planning:
QA ставить питання до User Stories
«Що станеться якщо користувач не заповнить поле X?»
«Як обробляється timeout при оплаті?»
→ Відповіді стають acceptance criteria
Refinement:
QA ревʼює вимоги до початку спринту
Знаходить суперечності і прогалини
Пропонує тест-кейси як частину definition of done
Design review:
QA перевіряє testability рішення
«Чи можна це протестувати без реального платіжного шлюзу?»
Метрики якості — говорити мовою бізнесу
Технічні метрики (для команди):
- % покриття тестами
- Кількість багів на спринт
- Pass rate
- MTTR (час виправлення)
Бізнес-метрики (для менеджменту):
- Кількість багів знайдених у продакшені
- Час від знаходження бага до виправлення
- % релізів без критичних інцидентів
- Вартість дефектів (час розробника × вартість години)
Definition of Done з QA перспективи
DoD (Definition of Done) — угода команди що вважати «готовою» задачею.
Приклад DoD зі strong QA participation:
Код:
□ Code review пройшло
□ Unit тести написані (coverage > 80%)
QA:
□ Acceptance criteria перевірені вручну
□ Edge cases покриті
□ Regression тести оновлені / не сломані
□ Security перевірки (auth, IDOR, injection)
□ Performance: response time < 2 сек
Документація:
□ API документація оновлена
□ Release notes для нових фіч
Тільки після всього цього → задача "Done"
Як впливати на якість без повноважень
Стратегія 1: Дані замість думок
❌ «Мені здається якість знизилась»
✅ «За останні 3 спринти кількість prod багів
зросла з 2 до 8. Ось дані по кожному спринту.»
Стратегія 2: Запропонувати рішення разом з проблемою
❌ «Треба більше тестів»
✅ «Якщо додамо smoke тести в CI — будемо ловити
регресії за 15 хвилин замість наступного дня.
Можу зробити за 1 спринт.»
Стратегія 3: Робити прозорим що приховано
❌ Мовчки знаходити баги в продакшені
✅ «Цього тижня 3 бага з продакшену можна було
знайти на staging якщо мати 2 години на manual.
Пропоную ввести exploratory session перед релізом.»
Типові ситуації і як поводитись
«Ми маємо релізити сьогодні, але є баг»
Погана реакція:
«Ні, не можна! Є баг!»
або
«Добре, релізьте» (без фіксації)
Правильна реакція:
1. Оцінити severity і impact:
«Баг Critical? Хто і як часто стикається?»
2. Запропонувати варіанти:
А) Відкласти реліз на N годин/днів
Б) Реліз з workaround (описати)
В) Реліз з feature flag (відключити фічу)
Г) Реліз і хот-фікс завтра (прийняти ризик)
3. Зафіксувати рішення:
«Команда вирішила релізити з варіантом В.
BUG-201 залишається відкритим, фіксуємо у v2.16»
«Розробник каже що баг не є багом»
Кроки:
1. Уточнити очікувану поведінку:
«Згідно вимог REQ-042 поле обов'язкове.
Я відправив форму без нього і отримав 200.
Моє розуміння коректне?»
2. Якщо вимоги неоднозначні:
«Давай уточнимо у BA/PO — яка поведінка очікується?»
3. Якщо це навмисна поведінка:
«Зрозумів. Можеш оновити вимоги або додати коментар
у тікет щоб наступного разу не було плутанини?»
4. Якщо не можете домовитись:
Ескалювати до tech lead або PO — це їх рішення.
Зафіксувати власну позицію в тікеті.
Прийом зворотного зв'язку
Критика тест-кейсу:
«Твої тести флакі і ламають pipeline»
Правильна реакція:
«Дякую що сказав. Покажи які конкретно падають?
Розберемось разом — схоже що є race condition
в налаштуванні середовища. Виправлю до кінця дня.»
Неправильна реакція:
«Та це середовище проблемне, не мій код»
або
Мовчки виправити без зворотного зв'язку
Питання на співбесіді
«Як ти спілкуєшся з розробниками при знаходженні бага?»
Нейтрально і технічно. Баг-репорт — документ з кроками, фактичним і очікуваним результатом, без оціночних суджень. При обговоренні фокусуюсь на поведінці системи, не на людині. Якщо незгода — звертаємось до вимог або ескалюємо до PO.
«Що таке shift-left і як ти його застосовуєш?»
Участь QA з початку спринту, а не тільки в кінці. На планінгу ставлю питання до User Stories — відповіді стають acceptance criteria. На рефайнменті ревʼюю вимоги. Це дозволяє знайти дефекти у вимогах до написання коду, що набагато дешевше.
«Як ти пріоритизуєш баги коли їх багато?»
За матрицею вплив × ймовірність. Critical + висока ймовірність = перше. Косметика з низькою ймовірністю = останнє. Також враховую бізнес-контекст: баг на головній сторінці з низьким severity може мати High priority бо його бачать всі клієнти.
«Як ти впливаєш на якість коли немає повноважень?»
Через дані — показую тренди, а не думки. Через пропозиції — завжди з рішенням, не тільки проблемою. Через прозорість — роблю видимим те що приховане: «ці баги можна було знайти раніше якщо зробити X». QA — це адвокат якості, а не поліцейський.