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

Ринок тестування змінився. Просто вміти тестувати UI та писати test cases уже недостатньо. Від сучасного QA все частіше очікують розуміння системи в цілому: API, автоматизації, CI/CD, баз даних, контейнеризації та роботи з AI. У цьому відео розбираю 10 ключових напрямків, які формують сучасного QA Engineer. Дивитись на YouTube

Якщо дивитися на цей репозиторій не як на “ще одну добірку посилань”, а як на карту розвитку, то він виглядає доволі якісно. Він будує навчання не навколо інструментів, а навколо знань: Web fundamentals (HTTP, DNS, браузери, cookies, сесії). Linux та командний рядок. Networking. Burp Suite. OWASP Top 10. API Security. Authentication/OAuth/JWT. Cloud Security. Active Directory. Mobile. Bug bounty methodology. Практичні лабораторії та CTF. Саме така послідовність зазвичай і рекомендується досвідченими багхантерами: спочатку зрозуміти, як працює веб, а вже потім шукати вразливості. https://github.com/1ndianl33t/Bug-Bounty-Roadmaps

QA Engineer в Bookmap віддалено 👉 https://dou.ua/goto/KvbL Senior QA Engineer (Manual + Automation) в Sherlock, recruitment agency віддалено 👉 https://dou.ua/goto/hNR3 Test Manager (QA Automation Lead) в Academy SMART віддалено 👉 https://dou.ua/goto/Tghm Middle Manual QA Engineer (Web Testing) в GPTinf Львів 👉 https://dou.ua/goto/1eSQ Middle General QA Engineer (Python and Pytest) в Poklyk Київ, за кордоном, віддалено 👉 https://dou.ua/goto/lyQa

4 серпня о 19:00 у Суворому QA ком'юніті — лекція Марії Терлецької: «Вітаємо! Ви тепер ще й Business Analyst. Як вижити QA без виділеного BA». Одного дня вам можуть сказати: «Поспілкуйся із замовником», «Уточни вимоги», «Напиши User Story» або «Онови беклог». Формально ви все ще QA. Фактично... вітаємо, ви вже Business Analyst. На реальних прикладах поговоримо про те: 🔹чому аналітичні задачі переходять до QA; 🔹 які BA-обов'язки найчастіше доводиться виконувати тестувальникам; 🔹 яких помилок варто уникати; 🔹 які інструменти бізнес-аналізу допоможуть працювати з вимогами; 🔹 як вижити, поки на проєкті немає виділеного аналітика. Лекція буде корисною тестувальникам, які вже виконують частину BA-обов'язків або хочуть бути до цього готовими. Кілька тез про Марію: 🔹 Business Analyst із понад 20-річним досвідом роботи в IT. 🔹 Працювала в командах, де BA було забагато, не було взагалі або його роль виконував той, хто не встиг втекти з мітингу. 🔹 Займається консалтингом і проводить корпоративні тренінги. 🔹 Авторка одного з найбільших українських онлайн-курсів із Business Analysis. 🔹 Переконана, що хороші вимоги економлять набагато більше часу, ніж потім забирає виправлення дефектів. Коротше, треба йти. 📅 Коли: 28 липня, 19:00 🎟 Квитки (50% з кожного квитка іде на ЗСУ) 🔴 Запис буде 🔗 LinkedIn Марії: https://www.linkedin.com/in/mariya-terletska/ Всі заходи для учасників Суворої QA спільноти безкоштовні. Долучайся до ком'юніті та отримай безліч додаткових корисних матеріалів.

Дві архітектури під сплеском дають однаковий success rate, але протилежний UX.  Генадій Сердюк досліджує поведінку систем і на відкритій моделі доводить, що тихе запізнення гірше за миттєву відмову. А ще розповідає, як перевіряти систему на те, де саме вона ламається під сплеском навантаження — на вході, у черзі, на обробці чи вже після порушення SLA. 👉 https://dou.ua/goto/CPfQ

‼️Набираємо діток на безкоштовний онлайн-майстер-клас зі створення власного AI-мультфільму! 🎬 Від “Young Coder School” Взяти участь можуть діти 8-15 років: як повні новачки, так і ті, хто вже обожнює технології ☺️ Будемо працювати з топовими нейромережами: ChatGPT, NanoBanana, Google Flow та CapCut🔥 Ціль нашої зустрічі — зробити перший крок у світ штучного інтелекту, провести час мегацікаво та з користю ☺️ І найголовніше — за ОДИН урок пройти повний шлях від сценарію до готового мультика, де ГОЛОВНИМ ГЕРОЄМ у 3D-стилі буде сама дитина! 🤩🚀 Проєкт розрахований всього на 10 учасників, щоб ми могли приділити увагу кожному🥹 🔥РЕЄСТРАЦІЯ

Повна добірка статтей по тест-дизайну, про які є матеріали в каналі All about QA: Вступ до Технік Тест-Дизайну та Класи Еквівалентності Аналіз Граничних Значень (Boundary Value Analysis) Таблиці Рішень (Decision Table Testing) Діаграми Станів та Переходів (State Transition Testing) Передбачення Помилок (Error Guessing) Тестування на основі Варіантів Використання (Use Case Testing) Покриття Операторів (Statement Coverage) Покриття Рішень/Гілок (Decision/Branch Coverage) Покриття Умов (Condition Coverage) Тестування попарно (Pairwise/All-Pairs Testing) Покриття Модифікованих Умов/Рішень (MC/DC) Тестування на Основі Сценаріїв Використання (Use Case Testing) Ортогональні Масиви (Orthogonal Array Testing - OATs) Дослідницьке Тестування (Exploratory Testing) Таблиця Переходів Станів (State Transition Table) Граф причинно-наслідкових зв’язків (Cause-Effect Graphing) Метод Класифікаційних Дерев (Classification Tree Method — CTM) Тестування на основі ризиків (Risk-Based Testing) Тестування на основі Історій Користувача (User Story Testing) CRUD Тестування (Create, Read, Update, Delete) Фазінг (Fuzz Testing / Fuzzing) Тестування на основі Чек-листів (Checklist-Based Testing) Аналіз Домену (Domain Analysis Testing) Тестування Синтаксису (Syntax Testing) Порівняльне Тестування (Comparison / Back-to-Back Testing) Ad-hoc Тестування (Інтуїтивне Тестування) Тестування Сценаріїв (Scenario Testing) Мутаційне Тестування (Mutation Testing) Тестування Шляху Користувача (User Journey Testing) Тестування на Основі Моделей (Model-Based Testing — MBT) Тестування Синтаксису (Syntax Testing) Тестування життєвих циклів / процесів (Process Cycle Testing) Синтаксичне vs Семантичне Тестування (Syntax / Semantic Testing) #AllAboutQA #QA #ТестуванняПЗ #Тестування All About QA - все про тестування ПЗ

Є одна проблема з кібербезпекою: що більше в неї занурюєшся, то складніше зрозуміти, де ти взагалі знаходишся. Раніше я писав вже про цей репозиторій на GitHub в 2024, але тоді там був тільки про NMAP mind map, а тепер він такий наповнений що містить тепер і: OWASP, Red Teaming, Active Directory, OSINT, Cloud і Container Security, Burp Suite, Nmap, Wireshark, MITRE ATT&CK, форензика та багато іншого. У колекції вже близько 300 комітів і понад 9 тисяч зірок. Карти доступні у PNG та PDF, тому їх зручно використовувати для навчання, підготовки курсів або побудови власного security roadmap. Але мене більше зачепив інший момент. Такі карти добре показують, що сьогодні цінність спеціаліста вже не лише в тому, скільки інструментів він знає. Запам’ятати всі назви стає майже неможливо, та й не дуже потрібно AI швидко підкаже команду чи синтаксис. https://github.com/Ignitetechnologies/Mindmap

📈 Зі зростанням кількості IoT- і MilTech-проєктів компанії активніше шукають QA-фахівців, які вміють тестувати не лише софт, а й hardware. Побудуйте embedded QA workflow: від тестування пристроїв, роботи з обладнанням і протоколами та автоматизації тестів на Python — до аналізу результатів та використання сучасних інструментів, — на курсі «Embedded QA Engineer». Після 20 занять ви зможете: ⚙️ писати тести на Python і pytest ⚙️ працювати з UART, GPIO, I2C, SPI, BLE, Wi-Fi та MQTT ⚙️ створювати HIL-стенди для automated hardware testing ⚙️ запускати hardware-тести в CI/CD ⚙️ дебажити firmware, hardware та network-проблеми ⚙️ зібрати власний embedded QA toolkit У фіналі — презентуєте свою розробку та отримаєте технічне ревʼю від лектора й фідбек щодо презентації від HR-ів та рекрутерів. Лектор: Богдан Горбанич — Senior Embedded QA Engineer у SQUAD, який має понад 7 років досвіду в QA Engineering: тестував software та embedded-рішення для hardware-продуктів. Старт: 28 липня Деталі, програма та реєстрація ⬅️

📣 Сувора QA Конференція #002 вже зовсім скоро — 28 вересня – 2 жовтня, онлайн. Тема цього разу — AI in Testing: 10+ спікерів, дві сесії щодня, практичні доповіді для QA-спільноти. Програма вже на 90% сформована — розклад і всіх спікерів можна подивитись на сайті conference.grygorenko.tech За промокодом yetanotherdiscount — знижка на квиток. Діє до кінця серпня, обмежена кількість — 15 квитків. Реєстрація: https://conference.grygorenko.tech

🔥 Добірка крутих можливостей для QA джунів Продуктова компанія Quarks (роблять high-load продукти у сфері social discovery & relationsip wellness) має одразу три вакансії для початківців. А робота в продукті — це завжди +100 до скілів, бо завдання різноманітні, а результати твоїх тестів впливають на мільйони реальних юзерів • Junior QA Engineer https://cutt.ly/Oyr7Zjfp • Junior Manual QA https://cutt.ly/1yr7ZHku • Junior QA Engineer https://cutt.ly/Kyr7Z5V7 💰 Бонус для тих, хто не шукає роботу: якщо у вас є талановитий знайомий джун, рекомендуйте та отримаєте $300 за успішний найм: https://cutt.ly/pyr7XsXz

Чи вбиває план креативність тестувальника? Або все ж рятує, коли мозок уже не хоче генерувати ідеї, а тестувати все одно треба?  На форумі користувачка розмірковує, як різні стани протягом дня впливають на QA-рутину - коли краще планувати тестування, коли йти за тест-кейсами, а коли досліджувати. 👉 https://dou.ua/goto/p2ob

Не наймайте ще одного Manual QA. Подивіться, де у вашій команді губиться контекст між «тестує» і «пише тести». Де регресія перетворилась на окрему фазу релізу, а не фоновий процес. Хороша система не ділить якість на ролі — вона робить так, щоб кожен відповідав за фічу до кінця. Роман Поботін, Lead AQA / SDET у Дії, у своєму блозі розбирає пастку локальної оптимізації та пояснює переваги моделі General QA, що економить місяці регресії. 👉 https://dou.ua/goto/cMcF

🤖 З чого починати писати автоматизовані тести? Одна з найпоширеніших помилок — почати автоматизацію з першого сценарію, який потрапив під руку. У результаті можна отримати сотні автотестів, які довго виконуються, часто падають і майже не допомагають оцінити реальний стан продукту. Автоматизацію потрібно починати не з написання коду, а з відповіді на питання: що саме ми хочемо захистити від регресії та де помилка коштуватиме найдорожче? 1️⃣ Критичні бізнес-сценарії У першу чергу варто автоматизувати функціонал, без якого продукт фактично втрачає сенс. Для інтернет-магазину це можуть бути: 🔹 авторизація; 🔹 пошук товару; 🔹 додавання до кошика; 🔹 оформлення замовлення; 🔹 оплата. Для банківського застосунку — вхід, перегляд балансу, переказ коштів та підтвердження операції. Це critical path — ключові сценарії, заради яких користувач приходить у продукт. 2️⃣ Smoke-тести Наступне завдання — створити невеликий набір тестів, який швидко відповідає на просте питання: Чи працює система настільки, щоб її можна було тестувати далі? Хороший smoke-набір перевіряє основні модулі, швидко виконується та запускається після кожного деплою. Тут не потрібні сотні тестів. Потрібен мінімальний набір, який однозначно показує, чи придатний білд для подальшої роботи. 3️⃣ Стабільний регрес Далі автоматизуємо сценарії, які: ✅ регулярно виконуються вручну; ✅ повторюються в кожному релізі; ✅ мають передбачуваний результат; ✅ працюють на відносно стабільному функціоналі; ✅ потребують перевірки великої кількості даних. Якщо тест доводиться виконувати вручну знову і знову — це хороший кандидат для автоматизації. 4️⃣ API раніше за UI Не потрібно намагатися перевірити всю систему через інтерфейс. UI-тести повільніші, складніші в підтримці та частіше стають нестабільними через зміни верстки, локаторів, анімації чи очікувань. Якщо бізнес-логіку можна надійно перевірити через API — краще зробити це саме там. Оптимальний підхід: 🔹 багато тестів на API та нижчих рівнях; 🔹 менше інтеграційних тестів; 🔹 невелика кількість наскрізних UI-тестів для ключових користувацьких сценаріїв. 5️⃣ Пріоритет визначає ризик Корисна модель: Імовірність дефекту × вплив дефекту × частота використання функціоналу Чим вищий ризик — тим раніше сценарій повинен потрапити в автоматизацію. Наприклад, дефект в оплаті може виникати рідко, але його вплив на бізнес критичний. Тому платіжні сценарії мають високий пріоритет. А перевірка маловикористовуваного елемента з мінімальним впливом може почекати. 6️⃣ Не автоматизуйте все підряд Якщо функціонал змінюється щотижня, вимоги ще не сформовані, а UI постійно переробляється — підтримка автотестів може коштувати дорожче за ручне тестування. Автоматизація найбільше окупається там, де функціонал достатньо стабільний, але потребує регулярних перевірок. 📌 Отже, мій порядок пріоритетів: Критичні бізнес-сценарії. Smoke-тести. Стабільні API та інтеграції. Основний регрес. Ролі та права доступу. Негативні та граничні сценарії. Рідкісні й низькопріоритетні кейси. Мета автоматизації — не написати якомога більше тестів і не отримати красиві 100% покриття. Потрібно швидко отримувати надійну інформацію про стан продукту та зменшувати ризик критичних дефектів. Краще мати 50 стабільних тестів, які захищають ключові бізнес-процеси, ніж 500 нестабільних UI-тестів, результатам яких команда вже не довіряє. #QA #AutomationTesting #TestAutomation #SoftwareTesting #AllAboutQA

🧪 Тест-кейси не знайдуть усі баги в продукті #testing #books Тест-кейси перевіряють те, що ми очікуємо. Але найцікавіші проблеми часто живуть там, де ніхто не очікував їх побачити: у несподіваних сценаріях, спотворених даних, граничних значеннях і припущеннях команди. Ось тут і потрібне дослідницьке тестування. Таке тестування - це не просто “поклацати навмання без плану”. Дослідницьке тестування має свої структуру та правила. Одна з найкращих книжок на тему дослідницького тестування - це "Explore It!" від Elisabeth Hendrickson. Поділюся трьома неочевидними інсайтами з книги: 1. Tested = checked + explored. Частина checked - це там, де ми перевіряємо чи система працює так, як було задумано в очікуваних умовах. Таке тестування можна (й треба) автоматизувати. А частина explored - це дослідження додаткових ризиків. 2. Для того, щоб почати дослідницьке тестування треба підготувати чартер - короткий опис конкретної сесії тестування. Він складається з цілі, ресурсів та інформації яку ми хочемо дослідити. 3. Щоб заохотити команду робити аналіз ризиків разом, можна зіграти з ними в спеціальну гру під назвою "Nightmare Headline Game". Більше подробиць - у огляді книги в моєму блозі.

🤖 Корисні ресурси для автоматизаторів Артур Шевченко, Systems Architect, інженер, програміст, Ph.D., із 12+ роками досвіду в тестування та тренер курсу підготовки до сертифікації ISTQB Advanced Test Automation Engineer, підготував для вас добірку джерел, які варто переглядати усім автоматизаторам, щоб тримати руку на пульсі і не пропускати важливі апдейти. 📝 Блоги від практиків On Test Automation — блог Баса Дейкстри, незалежного консультанта й тренера з тестування з майже 20-річним досвідом. Практичні статті про підходи до автоматизації, поширені помилки (наприклад, чому UI-тести так часто "флакі") та розвиток кар'єри в тест-автоматизації. Автор також розробив бібліотеку RestAssured.Net для тестування API на C#. 🔗 ontestautomation.com/blog 🔗 LinkedIn: linkedin.com/in/basdijkstra Automation Panda — блог Ендрю Найта, інженера, що спеціалізується на побудові систем тест-автоматизації з нуля. Глибокі матеріали про Python, Java, C#, JavaScript, поведінково-орієнтовану розробку (BDD), фреймворки на кшталт behave і pytest-bdd, патерн Screenplay та власний open-source інструмент Boa Constrictor для .NET. 🔗 automationpanda.com/about 🔗 LinkedIn: linkedin.com/in/andrew-leland-knight 📡 Технологічні тренди Thoughtworks Technology Radar — двічі на рік Thoughtworks публікує зріз актуальних технік, інструментів, платформ, мов і фреймворків, заснований на реальному досвіді своїх команд. Кожна позиція потрапляє в одне з 4 кілець — Adopt, Trial, Assess або Hold. Чудовий спосіб відстежувати нові інструменти для тестування (accessibility-тестування, mutation testing, AI в QA) і загальні тренди в розробці ПЗ. 🔗 thoughtworks.com/radar 🎥 YouTube-канали Raghav Pal (Automation Step by Step) — канал автоматизаційного архітектора, який очолював команди автоматизації та DevOps-інженерів. Прості покрокові туторіали: Selenium, Appium, Cypress, Playwright, Katalon Studio, API-тестування, Postman, Jenkins, Docker, Kubernetes. Також безкоштовні онлайн-курси та прямі ефіри з відповідями на запитання. 📹 youtube.com/@RaghavPal SDET Pavan — канал про автоматизацію тестування, орієнтований на SDET-напрямок (Software Development Engineer in Test), де тестувальник поєднує навички розробника й автоматизатора. Багато контенту з різними мовами й інструментами. 📹 youtube.com/@sdetpavan 📬 Новини та дайджести Software Testing Weekly — щотижневий дайджест Давіда Диловича, який виходить щоп'ятниці й об'єднує понад 9000 тестувальників. Автор самостійно відбирає найцікавіші статті, інструменти та новини тижня, супроводжуючи посилання коротким описом. В архіві — сотні минулих випусків. 🔗 softwaretestingweekly.com Ministry of Testing — одна з найбільших світових спільнот для тестувальників і QA-інженерів, заснована у 2007 році. Ціла екосистема: форум The Club, Slack-спільнота, мітапи й конференції TestBash, навчальна платформа з курсами й бібліотекою доповідей, включно з матеріалами про автоматизацію. Частина контенту безкоштовна, розширений доступ — за Pro-підпискою. 🔗 ministryoftesting.com/software-testing-news 🏛️ Класика архітектури Martin Fowler — без нього нікуди. Chief Scientist у Thoughtworks, один з авторів Agile-маніфесту та автор культових книг "Refactoring" і "Patterns of Enterprise Application Architecture". На своєму сайті пише глибокі статті про архітектуру ПЗ, еволюційний дизайн, рефакторинг і мікросервіси. Розуміння цих принципів напряму впливає на те, наскільки добре можна побудувати стійку систему автоматизації. 🔗 martinfowler.com ___________________________________________ 🦄А від себе ми щиро радимо канал Артура From A | Все про IT, де він ділиться власним досвідом і думками про програмування, тестування, автоматизацію, архітектуру та ІТ загалом 📩https://t.me/from_artur 🤓 Які ресурси читаєте/дивитеся ви? Діліться в коментарях — доповнимо список! 👇

Рік тому Олександр Хотемський давав коментарі для DOU щодо того, як штучний інтелект змінить роботу початківців у QA. Час перевірити, що з цього реально прижилося, а що виявилося хибним. У своєму дописі Олександр перевіряє власні передбачення та розбирає, чому безлімітний контекст ШІ створив зовсім нову проблему, як автоматизоване тестування доступності перетворилося на «пандус для галочки», і головне — хто такі сучасні джуни-вайбкодери та чому їх варто тримати якомога далі від реальних проєктів. 👉 https://dou.ua/goto/D24J

Head of QA Аня Куркотова автоматизувала тестування задач, що дозволило їй зекономити час та підвищити продуктивність. У своєму блозі авторка розповідає про власний кейс побудови AI-помічника, що виконує завдання під її наглядом, та детально пояснює, як це зробити. 📌 https://dou.ua/goto/X7ch

Добірка подій для тестувальників 06.07, онлайн Learning Program for future QA Engineers by Luxe Quality 07.07, онлайн Лекція Інни Осінної «Ідемпотентність. Речі, про які не говорять» 14.07, онлайн Благодійні вебінари «Все про Claude Code для тестувальників» 14.07, онлайн Лекція Євгена Пасєки «Human-in-the-loop: страх чи необхідність» 21.07, онлайн Благодійний вебінар «Все про Claude Code для тестувальників» (2 частина) 21.07, онлайн Лекція Володимира Обрізана «Типові помилки в автоматизації тестування веб-застосунків» 28.07, онлайн Лекція Артема Григоренка «Людська нейромережа: те, що жоден AI не замінить у твоєму професійному рості» #DOU_Календар