Тестові оточення: які бувають і навіщо кожне потрібне?Щоб якісно протестувати продукт, недостатньо просто «запустити автотести». Важливо розуміти, де саме це відбувається. Саме для цього і використовуються тестові оточення.Можливі варіації в назвах та кількості, але можна відокремити основні типи, які варто знати QA:1. Local (локальне)Тестування відбувається прямо на комп’ютері розробника або тестувальника.Використовується для:– швидкої перевірки нових змін;– розробки та налагодження автотестів.2. DEV (development)Оточення для розробників. Може бути нестабільним, часто оновлюється.Використовується для:– перевірки нових фіч під час розробки;– інтеграційних тестів;– тісної взаємодії QA + Dev.3. QA / TEST / STAGEОфіційне тестове середовище для ручного та автоматизованого тестування.Використовується для:– повного циклу тестування;– регресії;– прийомки перед демо.Тут дані максимально наближені до реальних, але без впливу на прод.4. UAT (User Acceptance Testing)Може бути підготовлено окреме оточення для приймального тестування замовником або бізнесом.Використовується для:– перевірки функціоналу з точки зору користувача;– демонстрації нових можливостей. 5. PRE-PROD / STAGINGМайжекопія продакшену.Використовується для:– фінальної перевірки перед релізом;– smoke-тестів;– performance-тестування.6. PROD (Production)Реальне середовище, з яким працюють користувачі.Використовується для:– моніторингу;– перевірки фіксів після релізу (post-release validation);– дуже обережного тестування (якщо дозволено).Висновок:Тестові оточення — це як «пісочниці» з різним рівнем ризику. Чим ближче до продакшену — тим обережніше треба грати. Вміти правильно використовувати їх — дуже важливо для будь-якого QA.
🧩 Помилка в консолі — фронт чи бек? Як зрозуміти тестувальнику?Класика: відкрив F12, щось червоне в консолі, щось не працює. І ти стоїш із цим error'ом — наче з гарячою картоплиною: кому його передати? 🤯Розбираємось, як швидко зрозуміти, де причина — фронт чи бекенд 👇🔍 1. Подивись на тип помилки.TypeError, ReferenceError, Cannot read property...→ Фронт. Це JS-помилки в браузері, часто через поганий рендер, null, неправильну логіку у фронті.Failed to fetch, CORS error, NetworkError, timeout→ Може бути бек або мережа. Часто — бек не відповідає або не віддає правильний CORS-заголовок.🌐 2. Перевір вкладку Network (в Chrome DevTools).Запит має статус:▪️ 4xx (наприклад, 404, 403) → часто проблема на фронті: неправильний шлях, відсутній токен.▪️ 5xx (500, 502, 503) → це вже бекенд, сервер не впорався.▪️ 200, але дані дивні або null → можливо, фронт щось не так обробив.👉 Якщо відповіді взагалі немає — перевір, чи сервер живий, чи є VPN/інтернет.🧠 3. Читай stack trace.Якщо в консолі є шлях типу main.js:156 або App.jsx:48 — це фронт.Якщо в response від API є json з полем message, error, stack — часто це бекенд сам передає помилку.🛠 4. Спробуй повторити запит вручну (Postman або curl).Якщо помилка повторюється — справа в бекенді.Якщо там все ок, але UI ламається — проблема у фронті.💡 Практика = досвідЗ часом ти навчишся за 10 секунд по консолі та Network вкладці розуміти, що зламалось і куди бігти. Не соромся писати в команду уточнення типу:“Отримую 500 при POST на /api/orders. Чи є проблема на бекенді?”📦 Тестувальник, який розбирає консоль — це вже пів девелопера 😉...чи чверть, якщо розробник дуже високий 😂
🎬 Ця історія могла завершитись провалом. Але стала квитком в ІТ.🎙 LIVE-інтерв’ю: Випускник VS Тренер QALight😳 Уяви:Ти готуєшся до співбесіди. Знаєш усе.І тут… зависаєш на легкому SQL-запиті. Тиша.І раптом:“Ти не витримаєш напругу на проєкті.”❌ Все. Фінал?👉 Ні. Це був лише початок.У суботу ми покажемо реальну історію людини, яка: – хотіла здатися– боялася не виправдати очікування– потонула в потоці знань– пройшла 21 співбесіду за місяць– і все одно дійшла до мети💡 Ти почуєш:— Як вчитися, щоб не згоріти на півдорозі— Чому навчання в QALight відкриває двері в реальне IT— І як стати тим, кого хочуть наймати, навіть після факапів🎙 Випускник VS Тренер QALight — розкажуть усе, про що зазвичай мовчать.🎯 Без прикрас. Без “успішного успіху”.Просто чесно, відверто. 🔥БОНУС! Цієї суботи до діалогу приєднається карʼєрний менеджер з досвідом понад 5 років Лев Волевський. Він провів понад 3 тисячі співбесід і точно зможе порадити, як стати кандидатом, якому надішлють офер. Розмова, яка зруйнує міфи і включить реальність.🟢Коли? У суботу, 12 квітня, о 18:00 у прямому ефірі!📍Посилання на реєстрацію: https://testing.qalight.com/?page_id=661&et_fb=1&PageSpeed=off
🧪 Тестові дані: що готувати заздалегідь і чому це важливо?Успішне тестування часто залежить не лише від сценаріїв і чеклістів, а й від готових тестових даних. Бо коли знайдено баг, але ти 20 хв. створюєш акаунт вручну та готуєш дані — це вже не дуже 😅Отже, які дані тестувальник зазвичай готує заздалегідь? 👇📌 Типові приклади тестових даних:Користувачі з різними ролями– admin, manager, guest, readonly– Перевірка доступів, відображення, авторизаціїАкаунти з особливими станами– Підтверджений/непідтверджений email– Тимчасово заблокований користувач– Преміум-тариф / без підпискиТранзакції / замовлення– Оплачені, скасовані, в очікуванні– З різними валютами, сумами, помилкамиДокументи / файли– З різними форматами, розмірами, назвами– Вірні й зламані (для негативних кейсів)Продукти / товари– В наявності / немає на складі– Зі знижкою / без, із варіаціями– Видимі / прихованіAPI-токени, ключі, сесії– Валідні, прострочені, з різними правами– Тестові JWT або OAuth-токениПовідомлення / нотифікації– Прочитані / непрочитані– З різними типами: помилка, успіх, інфоІсторія дій (лог)– Для перевірки аудиту, фільтрів, звітів– Коректна дата/час, джерело, IP🛠 Як зручно з цим працювати?✅ Використовуйте фабрики/фікстури (наприклад, у Pytest, FactoryBoy)✅ Робіть SQL-дампи з тестовими наборами✅ Готуйте мокові дані для автотестів✅ Попросіть девів або devops створити "тестові сценарії" для БД📦 Готові тестові дані = готовність до реального світуЦе зменшує час на ручне налаштування, дозволяє швидше ізолювати баги та працювати більш стабільно.
🧾 ADR для тестувальника — навіщо це тобі?ADR (Architecture Decision Record) — це документ, у якому команда фіксує важливі архітектурні рішення про систему: що вирішили, чому, які були альтернативи.На перший погляд здається, що це тільки для архітекторів і девелоперів. Але ні! Для тестувальника ADR — це дуже корисний документ 🗝🔍 Навіщо тестувальнику читати ADR?✅ Розуміння архітектури– Знаєш, чому обрали певний підхід: наприклад, REST замість GraphQL або Redis для кешу.– Це дає контекст для створення тест-кейсів, перевірки сценаріїв відмов, продуктивності тощо.✅ Покриття ризиків– ADR часто описують компроміси — наприклад, «не підтримує офлайн-режим».– Це сигнал: треба протестити edge cases або попередити бізнес.✅ Формування тест-стратегії– Рішення впливають на рівень тестування (UI/API), середовище, мокові сервіси.– Якщо впроваджується нова бібліотека або сервіс — ти вже знаєш, що і де може впасти.✅ Підготовка до змін– Коли архітектура змінюється, ADR допомагає зрозуміти, чому саме і що слід ретестити.🧠 Як працювати з ADR📖 Читайте нові ADR — або підписуйтесь на зміни у репозиторії.✍️ Коментуйте — якщо бачите потенційні проблеми для QA (наприклад, недокументований API).🧩 Використовуйте у тест-плані — додавайте витяги з ADR як аргументацію.🔄 Піднімайте ADR самостійно — якщо тестувальник виявив проблему на архітектурному рівні — це не табу.💡 ADR — не тільки для розробників. Це must-have інструмент і для QA, який хоче бачити всю картину й робити тестування усвідомлено, а не «на око».
🔍 Outline vs Confluence — що обрати для документації?В сучасних командах розробки важливо мати зручне місце для документації, обміну знаннями та співпраці. Два популярних інструменти для цього — Outline і Confluence. Порівняю їх за ключовими параметрами 👇🧠 Простота використанняOutline — мінімалістичний, швидкий, схожий на Notion. Ідеальний для команд, яким важливо просто й швидко документувати знання.Confluence — потужніший, але складніший. Має більше можливостей, але UI іноді перевантажений.🛠 ІнтеграціїConfluence легко інтегрується з Atlassian Jira, Bitbucket та іншими інструментами Atlassian.Outline підтримує GitHub, Slack, Zapier тощо, але інтеграцій менше.📁 Організація знаньOutline — структура на базі колекцій та документів, дуже зрозуміла.Confluence — сторінки, простори, дерева — гнучко, але з часом може стати хаотично.🔐 Безпека та контроль доступуConfluence — потужні ролі, права, SSO, корпоративний рівень безпеки.Outline — простіший контроль доступу, але достатній для більшості невеликих і середніх команд.⚡️ ШвидкодіяOutline — працює дуже швидко, з мінімальними затримками.Confluence — може бути повільнішим, особливо у великих інстанціях.💰 ВартістьOutline▪️ Безкоштовно з відкритим кодом (self-hosted)▪️ SaaS-версія: від $10/користувача/міс.▪️ Ідеально для команд, які хочуть заощадитиConfluence▪️ Безкоштовно до 10 користувачів▪️ Платні тарифи: від $5.75/користувача/міс (Cloud)▪️ Дорожче в Enterprise-сегменті, але дає потужні корпоративні можливості✅ Що обрати?- Якщо стартап або шукаєш простіше — підійде Outline.- Якщо середній/великий бізнес і потрібна повна інтеграція з Atlassian — обирайте Confluence.
Інцидент. Що таке інцидент? Коли трапляється? Як визначається? Що з цим робити?Інцидент — це несподівана подія, яка порушує нормальну роботу системи або ставить під загрозу її стабільність, доступність чи безпеку. Наприклад:— сайт раптово перестав відповідати— зламався ключовий API— користувачі масово скаржаться на помилкиКоли трапляється інцидент?— Після релізу з багами— Через збій інфраструктури (сервер, БД, CDN тощо)— Внаслідок атаки або неправильних змін у конфігураціїЯк визначити інцидент?— Моніторинг сповіщає про помилку (наприклад, спайк 500-к)— Алерт із систем логів— Зворотній зв’язок від користувачів або сапорту— Автоматичні тести не проходять після деплоюЩо робить команда? 1. Ідентифікація — визначити суть і масштаби проблеми 2. Ескалація — залучити потрібних людей (DevOps, бекенд, підтримку) 3. Мітинг/канал — швидко зібратися для обговорення 4. Розв’язання — хотфікс, відкат, ізоляція багу 5. Постмортем *— аналіз причин, висновки, поліпшення процесівГоловне правило: швидка реакція + чітка комунікація.
Чому data-test-id — це біль? • Бо їх треба прокидати в коді всюди, хоча реально вони потрібні тільки для автотестів. • Таска “додати data-test-id” — це завжди лоу пріоріті. Її бере самий лінивий дев, якому нема шо на стендапі сказати. Або береш і робиш сам. 🙃 • В React’і це часто болюче — щоб прокинути айдішнік кудись глибоко, треба модифікувати купу вкладених компонентів. • Це техборг: • змінюється компонент — міняй data-test-id; • редизайн або рефакторинг — компонент зник, що робити з тестами? Натягувати айдішнік на новий компонент чи переписувати півпейджобджекта? • на проді треба вирізати ці атрибути для мінімізації — ще одна порція складності в коді.І все це — тільки для автотестів, які парсять DOM і намагаються працювати з UI як юзер. Хвилинку… А ще ж є скрінрідери — вони теж так роблять 👀🎯 Вихід: accessibility-based локаториARIA-атрибути, ролі, лейбли — це вже не просто “та знову ті куеї якусь херню хочать, потерплять”, це про юзерів на проді.І тепер, якщо “тест не може знайти кнопку” — це не тільки проблема QA, це проблема, бо реальні юзери теж не можуть її знайти або натиснути! 🔥От вам і союзник — accessibility. Впроваджуйте раз, і користь всім.
🎧 Скрипт для розпізнавання аудіо українською мовоюЩо робить:- Обробляє всі файли у папці audio/- Розпізнає українську мову (Whisper Large)- Зберігає текст у файл- Відкриває результат у VS CodeЯк запустити:1. Встановити Python: https://www.python.org/downloads/2. Встановити FFmpeg: - Mac: brew install ffmpeg - Windows: https://ffmpeg.org/download.html3. Встановити бібліотеки:pip install openai-whisper ffmpeg-python4. Створити папку audio/ і додати туди файли (.mp3, .wav, .m4a, .flac)5. Запустити скрипт:python transcriber.pyРезультат:- Для кожного файлу з’явиться текстовий файл з розпізнаним текстом.Сам код:import whisperimport osimport subprocessimport time # ⬅️ Додаємо імпорт timeprint("=== Скрипт стартував ===")# Вимірюємо час стартуstart_time = time.time()# Завантаження моделі Whisperprint("Завантаження моделі...")model = whisper.load_model("large") # ⬅️ Тут обираєш точну модельprint("Модель завантажено!")# Шлях до аудіофайлівaudio_dir = "audio"supported_formats = [".mp3", ".wav", ".m4a", ".flac"]# Сканування аудіофайлівaudio_files = [f for f in os.listdir(audio_dir) if os.path.splitext(f)[1].lower() in supported_formats]if not audio_files: print("⚠️ Аудіофайли не знайдено в папці 'audio/'.")else: print(f"Знайдено файлів: {len(audio_files)}") for file_name in audio_files: audio_path = os.path.join(audio_dir, file_name) print(f"\n▶️ Обробка: {audio_path}") result = model.transcribe(audio_path, language="uk") recognized_text = result["text"] output_file = os.path.join(audio_dir, f"{os.path.splitext(file_name)[0]}_transcription.txt") with open(output_file, "w", encoding="utf-8") as f: f.write(recognized_text) print(f"✅ Збережено у файл: {output_file}") subprocess.run(["code", output_file]) # Автовідкриття VS Code# Вимірюємо час завершенняend_time = time.time()elapsed = end_time - start_timeprint(f"\n⏱️ Обробка завершена за {elapsed:.2f} секунд")print("=== Скрипт завершено ===")
✅ Чек-лист для перевірки авторизації та автентифікації.Перевіряємо надійність та безпеку доступу до системи!🔑 1. Автентифікація (перевірка особи користувача): • Використовуються надійні паролі (мінімум 8 символів, великі та малі літери, цифри, спеціальні символи). • Є можливість зміни пароля користувачем. • Налаштована багатофакторна аутентифікація (2FA або MFA). • Використовуються сучасні методи аутентифікації (OAuth, SSO, JWT). • Дані облікового запису зберігаються в зашифрованому вигляді (наприклад, хешування паролів). • Захист від брутфорсу (обмеження кількості спроб входу).👥 2. Авторизація (керування правами доступу): • Чітко визначені ролі та права доступу користувачів. • Правила доступу регулярно переглядаються та оновлюються. • Доступ до конфіденційних даних обмежений тільки авторизованими користувачами. • Використовуються принципи мінімальних прав (least privilege). • Логуються всі спроби доступу до чутливих даних.🕵️ 3. Безпека сесій: • Сесії автоматично завершуються після періоду неактивності. • Токени доступу мають обмежений термін дії. • Застосовується захист від крадіжки сесій (наприклад, прив’язка до IP або пристрою).📝 4. Логування та моніторинг: • Логуються всі успішні та невдалі спроби входу. • Логуються спроби доступу до адміністративних панелей. • Проводиться регулярний моніторинг логів на предмет підозрілої активності.🚨 5. Реакція на інциденти: • Впроваджено механізм блокування підозрілих користувачів. • Є процедура повідомлення про злом або спробу несанкціонованого доступу. • Створений план реагування на інциденти безпеки.#AllAboutQA
TGLIST.COM.UA
