All about QA - Все про тестування ПЗ

LAST CALL ⏰ Завтра стартуємо! 6 днів, реальні AI-кейси з продакшену, Баклажановий рейтинг із подарунками та вечірні бари. Останні квитки чекають. Не проґав свій шанс розвинути навички в AI в тестуванні! 👉🏻 Купуй квиток за посиланням: https://conference.grygorenko.tech

Middle Manual QA Engineer в Mobizon Київ, віддалено 👉 https://dou.ua/goto/YMXH Lead QA Engineer (Mobile) в memoryOS віддалено 👉 https://dou.ua/goto/3mB9 Trainee QA в BotsCrew віддалено 👉 https://dou.ua/goto/1rL8 Strong Junior QA Manual в PayForce Київ 👉 https://dou.ua/goto/gMYj Middle Automation QA (fintech) в COMPARUS UA віддалено 👉 https://dou.ua/goto/GEf9

QALight відкриває новий потік "Базового модуля тестування" — програми, яка вже допомогла тисячам людей без технічної освіти увійти в IT і почати заробляти в новій професії. Бухгалтери, банкіри, медики, освітяни...також люди без будь-якого досвіду — вони довели, що бекграунд не має значення. Має значення бажання діяти. Чому саме зараз — найкращий момент: 🔹 Найнижчий поріг входу в IT — жодного досвіду чи техосвіти не потрібно 🔹 Робота зі штучним інтелектом з першого заняття — AI-інструменти стають вашими помічниками 🔹Навчання на реальних проєктах — а не абстрактні приклади з підручника 🔹Затребуваність професії — попит на QA-фахівців з навичками ШІ зростає щомісяця 🔹 Реальний результат — портфоліо та готове резюме вже через 4 місяці 🔹 Перспектива, а не просто диплом — шлях від QA-інженера до автоматизації, аналітики, тім-лідерства Ринок IT потребує фахівців, які вміють поєднувати класичні навички з ШІ. Ви можете стати одним з них — уже сьогодні зробивши перший крок. Місця в групі обмежені. Хто зволікає — втрачає можливість. 📅 Старт: 22.09.2026 ⏱️ 130 годин онлайн-практики 💻 Вт., Чт., 19:00–22:00 Це не тільки навчання, а ваш вхід у професію. 👉 Програма: https://qalight.ua/kursy/bmt/ 👉 Запис: @QALight_admin Почніть писати свою нову історію успіху.

Втомились від flaky email тестів в CI? 🫠 Всі через це проходили — sleep(5000), IMAP polling, токени Gmail що протухають о 3 ночі, паралельні тести що хапають чужі листи MailCatch вирішує це двома API запитами: 1️⃣ POST /inboxes → унікальна адреса @mcatch.dev 2️⃣ GET /wait → лист + OTP код автоматично Без IMAP. Без Gmail хаків. Без sleep(). Playwright, Cypress, Python, Java — будь-який HTTP клієнт. Середній час від створення inbox до отримання OTP — 2 секунди. 🔹 Безкоштовний план — без картки, без ліміту часу 🔹 Реєстрація за 30 секунд — email і пароль, все 🔹 API ключ одразу в дашборді — копіюєш і працюєш Один тест щоб переконатись → mcatch.dev

Middle General QA в OXOIX віддалено 👉 https://dou.ua/goto/QG3j Senior Test Engineer в MoonAgency за кордоном, віддалено 👉 https://dou.ua/goto/MuDW QA Engineer (Siebel CRM) в Bank Pivdenny Київ, Одеса, віддалено 👉 https://dou.ua/goto/IfxV General QA Engineer в Цитрус, $2200–2500 віддалено 👉 https://dou.ua/goto/Xaqk QA Engineer в NUMO Robotics Львів 👉 https://dou.ua/goto/x9FT

General QA Максим Кравченко створює Noviora — мобільну RPG, у якій реальні справи та розвиток навичок перетворюються на квести. У статті він розповідає, як будував застосунок за допомогою AI, чому QA-підхід став частиною розробки та як тестування допомагає працювати з агентами, складними сценаріями й релізами. 👉 https://dou.ua/goto/VEjA

Втомились від flaky email тестів в CI? 🫠 Всі через це проходили — sleep(5000), IMAP polling, токени Gmail що протухають о 3 ночі, паралельні тести що хапають чужі листи MailCatch вирішує це двома API запитами: Створюєш inbox → отримуєш унікальну адресу @mcatch.dev Викликаєш /wait → отримуєш лист + OTP код витягнутий автоматично Без IMAP. Без Gmail хаків. Без sleep(). Працює з Playwright, Cypress, Python, Java — з будь-чим що вміє робити HTTP запити Безкоштовно, без картки → mcatch.dev

🔐 Що ви давно хотіли запитати про Security? 15 вересня о 19:00 — Q&A з Анастасією Войтовою, Head of Security Engineering @ Cossack Labs, CISSP. Обговоримо те, що цікаво саме вам: кіберзагрози, AI & Security, реальні кейси, Security Engineering та інші питання. 💬 Залишайте свої питання під час реєстрації — розберемо їх наживо з Анастасією. 📅 15 вересня, 19:00 💻 Online 🎟 Безкоштовно, реєстрація обов’язкова: https://forms.gle/vkTQD429YfttcPX36

Денис Туровський продовжує розповідати про власну трейдингову систему на Python. Ще недавно в його Binance trading bot було 130+ тестів, а тепер full-suite run налічує 5595. Автор показує, як тестування виросло від перевірки окремих функцій до recovery, idempotency, fault tolerance, replay та parity, та які проблеми приніс уже сам великий test suite. 👉 https://dou.ua/goto/sQVM

AQA/Manual (офіс, Київ) в Eleven Київ 👉 https://dou.ua/goto/3tXV General QA (Manual + Automation) — mobile клієнт-банк (Middle/Senior) в ТОВ «АЛЬЯНС ДІДЖИТАЛ» віддалено 👉 https://dou.ua/goto/yIfB Senior QA Automation Engineer — macOS Desktop в devPulse, $3000–4000 віддалено 👉 https://dou.ua/goto/lO6h Trainee AQA (iOS) в Sombra Київ, Львів, Івано-Франківськ, віддалено 👉 https://dou.ua/goto/TqFX Middle QA Engineer (API & Integrations) в Meest Львів 👉 https://dou.ua/goto/YoUP

🟢 «У нас усі тести зелені» — і це нічого не гарантує/ Зелений колір у звіті означає рівно одне: жоден написаний assert не впав. Це геть не те саме, що «функція працює». Три способи, якими зелений suite тихо бреше: 1. Тест, який нічого не перевіряє. Замість assert — logger.info("статус не той"). Він не впаде ніколи, бо йому нема на чому падати. Такий тест може бути зеленим роками й давати фальшиве відчуття покриття. 2. Тест, що проходить за будь-якого результату. Класика: чекаєш 401, а сервіс віддає 200 з помилкою в тілі — і перевірка, яка дивиться лише на код, зеленіє. Або гейтвей взагалі не перевіряє токен, а всі тести ходять з валідним і цього не помічають. 3. Фантомне покриття. Тест готує дані, зберігає у файл… який жоден інший тест не читає. Виглядає як складний end-to-end сценарій, а по суті — мертвий код, що імітує роботу. Мораль: довіряй не кольору, а тому, що саме впаде, якщо зламати продукт. Тест, який не червоніє від внесеного дефекту, — не тест, а декорація. #QA #автоматизація #тестування #AllAboutQA

Цього тижня маємо класну рекомендацію від спільноти — SQL-тренажер Sqlstep. Жодних страшних syntax error чи нудної теорії. Лише візуальні підказки, перетягування блоків і прості завдання. Ідеально, якщо бази даних поки здаються магією. 👉 https://dou.ua/goto/jY4q Маєте якісь цікаві ресурси, якими ви готові поділитися зі спільнотою? Заповнюйте форму, не тримайте їх в секреті 😎

GPT-6 Astra - що цікавого для QA/Automation інженера: • Код і робота з проєктами. Terminal-Bench 4.0: 57,9% проти 37,3% у Sol. Astra краще розбирається у великих кодових базах, дебажить, запускає/перевіряє код і потребує менше ітерацій для отримання робочого результату. • QA прямо в браузері. Astra суттєво сильніша у computer-use: може працювати із сайтом, проходити UI-flow, знаходити проблеми та виконувати frontend QA. OSWorld: 72,6% vs 65,7%, ScreenSpot-Pro: 92,7% vs 76,9%. • Складні баги та системний аналіз. Вона краще тримає довгі ланцюжки залежностей і контекст. На тесті довгого контексту 512K–1M: 96,3% vs 73,8%. Це важливо, коли даєш документацію + API + код + логи + вимоги й просиш знайти причину проблеми. • Менше вигадує. На внутрішньому тесті OpenAI на хибні твердження про власні можливості — 4,2% проти 12,2% у Sol. • Краще виконує багатокрокові завдання. AutomationBench: 41,4% проти 18,1% — тут різниця вже більш ніж удвічі. • Значно сильніше абстрактне reasoning. Найбільш разючий результат — ARC-AGI-3: 99,9% проти 7,8% у Sol. Водночас не варто переносити один benchmark буквально на всі повсякденні запити.

«Флакі-тест» часто означає просто «ми не міряли» Був у нас UI-тест, який падав приблизно раз на десять прогонів. Класика жанру: таймаут 120 секунд, браузер не дочекався переходу, стектрейс на пів екрана. Найочевидніше рішення напрошується саме — підняти поріг до 180 і жити далі. Замість цього ми додали один рядок логування: скільки мілісекунд насправді тривало очікування. Не «впав / не впав», а конкретне число. А потім витягли з архівів Jenkins звіти за 8 прогонів. Виявилося, що в JUnit XML лежить <system-out> — увесь stdout тесту. Тобто вся історія вимірювань уже була, просто ніхто в неї не дивився. Скрипт на сотню рядків дав 396 замірів. І ніякої випадковості там не виявилось. Тест проганяє один і той самий сценарій шість разів поспіль — для шести різних довідників. Медіани: довідник 1 3,4 с довідник 2 52,4 с ← довідник 3 3,2 с довідник 4 2,4 с довідник 5 38,6 с ← довідник 6 5,4 с Дві позиції з шести повільні. І у всіх восьми прогонах це ті самі дві. Жодного винятку. Це не флакі — це детермінована поведінка бекенду, яка іноді просто не вкладається в поріг. Три висновки, які я забрав собі. Таймаут — це бінарна відповідь на неперервне питання. Він каже «встиг / не встиг» і викидає найцінніше: на скільки саме не встиг. Логуйте тривалість поруч із кожним очікуванням — особливо коли воно успішне. Підняти поріг — це не виправити, а перестати бачити. 180 секунд зробили б білд зеленим. А користувач у проді все одно сидів би хвилину перед незмінним екраном без індикатора прогресу. Тест не помилявся. Він показував правду, яку незручно було читати. Дані вже є, просто в незручному місці. Якщо ваш пайплайн архівує build/test-results/**, у вас уже лежить готовий датасет по кожному прогону. З нього будується розподіл — замість суперечок на відчуттях. Наступного разу, перш ніж написати в тікеті «flaky, перезапустив — пройшло», спробуйте поставити питання інакше: а скільки саме секунд? @AllAboutQA

Manual QA (Junior) в Gameloft Львів, віддалено 👉 https://dou.ua/goto/927d Middle Manual QA в Readeat, $1200–1500 віддалено 👉 https://dou.ua/goto/5N4E QA Engineer в Frontline Robotics Київ 👉 https://dou.ua/goto/hI1t Middle Manual QA в Hurma System віддалено 👉 https://dou.ua/goto/uveN Senior QA Automation Engineer, ASIC Simulation в NVIDIA Київ, віддалено 👉 https://dou.ua/goto/Btni

AI може за хвилини написати тисячі рядків автотестів, а потім виявляється, що вони перевіряють не те 🙂 QA Engineer Євген Шаповал показує на власному кейсі, як AI згенерував 2700 рядків тестів, а подальша перевірка знайшла false positives та сумнівні concurrency-тести. 👉 https://dou.ua/goto/cKel 

Якщо пишете автотести на Java, є кілька способів зробити їх коротшими та чистішими. У своїй статті Сергій Моренець розбирає JUnit Pioneer та його можливості для Automation QA. Автор показує, як спростити роботу з environment variables і системними властивостями, передавати тестові дані з JSON, створювати Cartesian-тести тощо. 👉 https://dou.ua/goto/IuIT

Щоб не дізнаватися про зміни в API через раптові баги на продакшені, Микола Міжигурський розробив власний фреймворк контрактного тестування.  У статті автор розповідає про свій підхід, який на проєкті зі 100+ ендпоінтами майже звів інтеграційні помилки між фронтом і беком до нуля. 👉 https://dou.ua/goto/voC6

У новому випуску розповідаємо про API From Hell — безкоштовний тренажер із 70+ підступними ендпоїнтами для практики API-тестування. Він допомагає навчитися помічати дивні та некоректні HTTP-відповіді та перевіряти, чи REST-клієнт не приховав проблему красивим форматуванням або власною обробкою. 👉 https://dou.ua/goto/MGlz  Маєте якісь цікаві ресурси, якими ви готові поділитися зі спільнотою? Заповнюйте форму, не тримайте їх в секреті 😎

Чи потрібен ISTQB тестувальнику у 2026 році? Навколо цієї сертифікації в QA-спільноті роками точаться суперечки. Для когось ISTQB — міжнародне підтвердження знань, для когось — просто ще один «папірець». Ми вирішили розібратися без крайнощів. У новій статті QALight говоримо про те: 🔹 що сьогодні дає ISTQB Foundation Level; 🔹 що змінилося у CTFL 4.0; 🔹 кому сертифікація справді може бути корисною; 🔹 як проходить іспит; 🔹 чи можна підготуватися самостійно; 🔹 і що про ISTQB говорять українські тестувальники, які вже проходили цей шлях. Буде цікаво почути й вашу думку: ISTQB — корисна систематизація знань чи переоцінений сертифікат? https://qalight.ua/novosti/istqb-foundation-level-ctfl-4-0/