Ручне тестування та якість продукту
Дослідницьке, функціональне, smoke- й регресійне тестування. Проєктування тестів, зрозумілі описи дефектів і перевірка релізів.
Краків, Польща
Mykola Khytra.
Старший QA-інженер, з яким релізи — без зайвих сюрпризів.
Ручне тестування, перевірки API та автоматизація. Ризики продукту, дослідницьке тестування й обґрунтовані рішення про реліз.
QA з підтримкою ШІ Claude Code і Codex для проєктування тестів, налагодження й документації. Як це працює
5+років у QA
11k+сценаріїв у спільній тестовій екосистемі
До 4×швидше виконання CI-джоб
QAручне + автоматизація
Про мене
Якість —
спільний орієнтир.
П’ять років досвіду в ручному, комплексному й автоматизованому тестуванні вебзастосунків, десктопного ПЗ, API та WebSocket.
Моя робота охоплює весь цикл тестування: аналіз ризиків продукту, проєктування тестів, дослідження поведінки, опис дефектів, перевірку релізів і створення автоматизації, яку легко підтримувати. ШІ допомагає з аналізом, проєктуванням тестів і реалізацією.
Напрями й інструменти
Підхід відповідно
до ризику.
Ручне дослідження продукту, перевірки API та зручна в підтримці автоматизація на всіх етапах QA.
Тестування API та інтеграцій
Тестування API й WebSocket, бізнес-правил і обробки помилок, дослідження дефектів. Jest, Vitest та Axios для автоматизованих перевірок API.
Автоматизація та процеси доставки
Автоматизація UI з Playwright і TypeScript. Повторне використання тестового коду, швидший зворотний зв’язок у CI та діагностика збоїв.
QA з підтримкою ШІ
ШІ на практиці.
Перевірені результати.
Щоденне використання Claude Code й Codex для аналізу репозиторіїв, проєктування тестів, коду автоматизації, налагодження та документації.
Зрозуміти контекст
Дослідження репозиторіїв, пошук ідей для тестів та аналіз збоїв із допомогою ШІ. Запитання формуються на основі ризиків продукту та його наявної поведінки.
Створювати й покращувати
Створення й підтримка тестового коду, рефакторинг спільних утиліт і підготовка документації. Агенти допомагають із повторюваними QA-завданнями та аналізом проблем.
Перевіряти результат
Рев’ю запропонованих змін, запуск відповідних перевірок і ручна перевірка поведінки там, де це потрібно. Технічні рішення залишаються за інженером.
Вибрані роботи
Менше очікування.
Більше ясності.
Приклади покращень автоматизації та процесів у Shelf. Ширший досвід ручного й комплексного тестування описано нижче.
01Продуктивність CI
60 хвилин → 15
Паралельне виконання з кількома воркерами прискорило багато регресійних CI-джоб до чотирьох разів.
Кейс про CI02Регресійне тестування API
Від ручного до повторюваного
Створив майже всі автоматизовані перевірки API для одного проєкту, використовуючи спільні клієнти, фікстури й тестові дані.
Кейс про API03Командна інженерна робота
Автоматизація для команди
Підтримував і розвивав спільну екосистему з 1 200+ специфікацій та 11 000+ API- й UI-сценаріїв.
Кейс про команду01 / Швидший результат регресії
Менше очікування, без послаблення перевірок.
Контекст. Тривалі регресійні CI-джоби сповільнювали отримання результатів, а нічні регресійні процеси потребували постійної підтримки.
Мій внесок. Впровадив паралельне виконання в багатьох CI-джобах із кількома одночасними воркерами та іншими оптимізаціями. Окремо підтримував нічну регресію приблизно для 30 із близько 70 CI-джоб і досліджував збої за логами й тестовими артефактами.
Результат. До чотирьох разів швидше виконання оптимізованих CI-джоб, зокрема скорочення тривалості приблизно з 60 до 15 хвилин. Покращення охопили багато CI-джоб, але не всі джоби й не весь пайплайн доставки.
02 / Повторювана регресія API
Спільна основа перед новим тестовим кодом.
Контекст. В одному проєкті компанії регресійні перевірки API виконували вручну, хоча їх можна було зробити повторюваними.
Мій внесок. Створив майже всі автоматизовані перевірки API цього проєкту: повторно використовувані клієнти Axios, фікстури, допоміжні функції та явну підготовку й очищення тестових даних.
Результат. Зменшив обсяг повторюваної ручної регресії та створив основу для майбутніх перевірок, яку легко підтримувати.
03 / Екосистема, яку зручно підтримувати
Корисна діагностика потребує спільної відповідальності.
Контекст. Екосистема на TypeScript із 1 200+ специфікацій та 11 000+ API- й UI-сценаріїв. Нею спільно користувалися приблизно 10–15 QA-інженерів, інженерів автоматизації та розробників із різних команд.
Мій внесок. Підтримував і рефакторив спільний код, майже щодня проводив рев’ю змін, допомагав QA-інженерам і розробникам працювати з фреймворком та створив дашборд у Datadog для моніторингу виконання.
Відповідальність за процес. Самостійно переніс управління тест-кейсами з TestRail до Testomat, створив документацію, настанови та стандарти автоматизації.
Результат. Краща видимість виконання та послідовніший підхід до підтримки автоматизації й управління тест-кейсами. Розмір набору тестів описує спільну екосистему, а не тести, написані лише мною.
Січ 2024 – Лип 2026 · Shelf · Віддалено
Старший інженер з автоматизації тестування
Спільна автоматизація, оптимізація CI, покриття API, рев’ю коду та самостійна міграція з TestRail до Testomat.
Жов 2022 – Січ 2024 · Shelf · Львів
QA-інженер: ручне тестування й автоматизація
Поєднував ручне тестування продукту й перевірки API з автоматизацією на TypeScript, Playwright, Jest та CircleCI.
Лис 2021 – Жов 2022 · Shelf · Львів
Молодший QA-інженер
Ручне тестування, перевірки API й WebSocket, тестова документація, опис і дослідження дефектів.
Кві 2021 – Жов 2021 · StarApps · Львів
QA-інженер-стажер
Ручне тестування веб- і десктопних застосунків для заряджання електромобілів та енергетичних продуктів.
Як я працюю
Факти важливіші за припущення.
Ризики насамперед
Починаю з того, що може зашкодити користувачам або бізнесу, а не лише з того, що найпростіше автоматизувати.
Збої мають давати відповіді
Перевірка, що впала, має давати достатньо контексту, щоб відтворити проблему, дослідити її та визначити наступні кроки.
Залишати зручним у підтримці
Зрозумілі фікстури, документація та пайплайн, який легко налагоджувати, важливі й після того, як автор переходить до інших завдань.
Інженерні нотатки
Три запитання,
які варто поставити.
Практичні міркування для щоденних рішень про якість.
Інженерія якості
Чи варто залишати цей тест?
Корисна перевірка захищає важливу поведінку, а її збій дає зрозумілу підставу для дій. Якщо тест нестабільний або дорогий у підтримці, варто виправити його основу чи переглянути, що саме він перевіряє. Більший набір тестів не обов’язково кращий.
Дослідницьке тестування
Чого не помічає скрипт?
Дослідницькі сесії починаються із запитань: де користувачі стикаються з труднощами, які припущення не справджуються та як продукт поводиться в незвичних станах? Знахідки стають відтворюваними дефектами, новими ідеями тестів або кандидатами на автоматизацію.
CI/CD
Що насправді означає зелений CI?
Лише те, що запущені перевірки пройшли. Довіра також залежить від їхнього покриття, пропущених перевірок, підходу до дослідження збоїв і того, чи вчасно надійшов результат, щоб вплинути на рішення.
Контакти
Поговорімо
про якість.
Потрібна допомога з якістю продукту? Обговорімо ручне тестування, покриття API, перевірку релізів та автоматизацію з підтримкою ШІ.
Ручне, комплексне й автоматизоване тестування.
Краків · Відкритий до віддаленої роботи