📈 Зі зростанням кількості 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 липняДеталі, програма та реєстрація ⬅️
🤖 З чого починати писати автоматизовані тести?Одна з найпоширеніших помилок — почати автоматизацію з першого сценарію, який потрапив під руку.У результаті можна отримати сотні автотестів, які довго виконуються, часто падають і майже не допомагають оцінити реальний стан продукту.Автоматизацію потрібно починати не з написання коду, а з відповіді на питання: що саме ми хочемо захистити від регресії та де помилка коштуватиме найдорожче?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".Більше подробиць - у огляді книги в моєму блозі.
Думаєте, що програмування — це «складно і не для вас»?А що, якщо вже за кілька тижнів ви зможете створити власну CMS-систему з нуля? 👇Розробка CMS на основі PHP — це не просто навчання.Це перехід від «дивлюсь на код» → до «я створюю продукт».Цей курс — третій етап шляху FullStack Web Developer, де ви перестаєте бути новачком і починаєте мислити як розробник.💡 Ви не просто вивчаєте PHP —ви будуєте власну систему управління контентом:✔️ працюєте з базами даних✔️ створюєте авторизацію та особисті кабінети✔️ реалізуєте CRUD-функціонал✔️ вивчаєте безпеку (SQL Injection, XSS)✔️ впроваджуєте ООП у реальному проєкті📚 Програма побудована так, щоб крок за кроком привести вас до результату:від основ PHP → до повноцінної CMS з адмінкою та користувачами.🎯 Після курсу ви отримуєте:✔️ власний готовий проєкт у портфоліо✔️ практичні, затребувані навички❗️ Важливо:Для старту вам достатньо знань HTML, CSS та базового JavaScript.🚀 Це той самий момент, коли варто перестати відкладати.Ринок потребує тих, хто вміє створювати, а не просто «розуміє теорію».📅 Початок навчання — вже 22 квітня📍 Формат: онлайн, у реальному часі з тренером🕒 Графік: Пн., Ср., Пт., 19:00–21:00📲 Telegram: @QALight_admin (реєстрація)📞 +38 (063) 78-010-78 | +38 (097) 78-010-78 | +38 (099) 78-010-78 Почніть зараз — і вже скоро ви будете тим, хто створює сайти, а не просто користується ними.
Ретро, яке не змінює процес — це просто розмова заради розмови.Якщо подивитись на ретро, що проводять деякі команди, можна зрозуміти просту річ: більшість команд робить їх формально. Але ретро — це один з небагатьох інструментів, який реально може впливати на результат.Як проводити ретро так, щоб був ефект 👇1. Чітка структура (і не імпровізуй кожного разу) Мінімум:- Що було добре - Що не ок - Що змінюємо Якщо цього немає — у вас не ретро, а балачка.2. Не збирай “думки” — збирай проблеми “Було складно”, “не дуже зручно” — це шум. Нормально звучить так:- “ADR приймаються, але не зрозуміло, що далі”- “Немає прозорості для менеджменту”- “Немає механізму впливу на рішення”Проблема має бути чітка і болюча.3. Кожна проблема → дія Якщо після ретро немає конкретних дій — ти витратив годину команди в нікуди.Формат:- Проблема - Рішення - Відповідальний - Дедлайн Без цього — це театр.4. Менше “як відчуваю”, більше “як вимірюємо” Замість:❌ “Комунікація слабка” ✅ “2 задачі заблоковані >2 днів без ескалації”Як тільки з’являється метрика — з’являється контроль.5. Не уникай незручних тем Ретро без конфлікту = ретро без користі.Якщо всі “в цілому задоволені” — значить або:- всі мовчать - або команда деградує повільно6. Роби follow-up (це головне, що всі ігнорять) На наступному ретро:- що зробили з минулого?- що реально змінилось?Якщо цього немає — команда швидко розуміє, що ретро нічого не вирішує.7. Візуалізація має допомагати, а не просто висіти на стіні Стікери — це не магія. Магія — це коли:- проблеми агрегуються - повторювані патерни видно - рішення відслідковуються📌 Висновок: Ретро — це не про “поговорити”, це про керування системою через зворотний зв’язок.Якщо після ретро нічого не змінилось — у вас не ретро, а імітація процесу.#AllAboutQA #qa #ретро
🔍 Тест-рев’ю: чому це не “формальність”, а контроль якості самого QA.У більшості команд тест-рев’ю сприймають як щось другорядне:“Та що там дивитись, тест же написаний…”А потім: • flaky-тести падають в CI; • автотести перевіряють “не те”; • вимоги трактуються по-різному; • в проді вилітають дефекти, які “мали бути покриті”.❗ Що таке тест-рев’ю насправді?Тест-рев’ю - це перевірка: • ✅ коректності покриття вимог • ✅ логіки сценаріїв • ✅ негативних кейсів • ✅ граничних значень • ✅ узгодженості з бізнес-логікою • ✅ якості автотест-коду (якщо це code review для QA).🎯 Навіщо це потрібно?1️⃣ Контроль покриттяЧи всі acceptance criteria реально перевірені?Чи немає “ілюзії покриття”?2️⃣ Запобігання дублюваннюДва тестувальники часто пишуть однакові сценарії — але по-різному.3️⃣ Підвищення якості автотестів • Немає hardcode? • Є адекватні очікування? • Немає залежності від стану середовища? • Чіткі assert-и?4️⃣ Зниження технічного боргу в QAПогані тести = нестабільний CI = недовіра до automation.🧠 Як проводити тест-рев’ю правильно?🔹 1. Рев’ю до імплементації.Спочатку перевіряємо тест-кейси — потім пишемо автотести.🔹 2. Чек-лист для рев’ю.Мінімальний набір питань: • Чи є позитивні та негативні сценарії? • Чи покриті permission / roles? • Чи враховані boundary values? • Чи описані передумови? • Чи немає логічних дір?🔹 3. Peer-review в automation.Якщо це автотест: • Чи відповідає патернам проєкту? • Чи немає flaky-локаторів? • Чи стабільні очікування? • Чи зрозумілий тест без додаткових пояснень?⚠️ Типові помилки❌ Рев’ю “для галочки”❌ Перевірка тільки форматування❌ Ігнорування бізнес-логіки❌ Відсутність зворотного зв’язку💡 Лайфхаки для сильних QA-команд • Робити рев’ю обов’язковим перед merge • Використовувати шаблони для тест-кейсів • Проводити групові review-сесії для складної логіки • Вести базу типових помилок • Аналізувати дефекти з продакшену через призму тест-рев’ю.🏁 ВисновокТест-рев’ю — це:🔐 контроль якості самого процесу тестування🧱 фундамент стабільної automation🚀 спосіб зменшити прод-інцидентиСильний QA — це не той, хто багато тестує.Сильний QA — це той, чиї тести неможливо “пробити”.#AllAboutQA
Старт кар’єри в IT без досвіду – з правильним фундаментомЯкщо ви прагнете увійти в професію QA швидко та ефективно, курс "Базовий модуль тестування" забезпечує саме те, що потрібно.Тут формують справжнє QA‑мислення: бачити баги там, де інші їх не помічають, правильно працювати з AI в команді та створювати портфоліо вже з перших тижнів.👨🏫 Ваш наставник — Микола Бобошко — засновник тренінг‑центру QALight, практик з понад 15‑річним досвідом у сфері тестування ПЗ. Він не лише розробив авторську методику навчання, а й щодня допомагає студентам трансформувати знання у реальні навички та працевлаштування в IT. Його підхід — не просто навчитись тестуванню, а формувати мислення QA‑інженера з перших занять.💻 Програма (130 годин):Тестування ПЗ – практика на реальних проєктахПрактичний SQLОснови Unix та мережТестування навантаженняWeb‑сервери та сервісиЯк правильно скласти резюме та пройти співбесіду🏆 Результат:4–6 місяців → реальний досвід, готове портфоліо та впевненість на інтерв’ю → позиція Junior QA з конкурентною зарплатою.🎓 13 років досвіду, понад 20 000 випускників, акредитація ISTQB — тренінг‑центр, який реально готує до роботи в IT.🎁 Перше заняття — безкоштовне, щоб ви могли оцінити методику навчання без зобов’язань.🗓 Старт: 3 березня💻 Онлайн наживо, Вт., Чт. 19:00–21:30Деталі 👉 https://qalight.ua/kursy/bmt/📲 Telegram: @QALight_admin (реєстрація)📞 +38 (063) 78-010-78 | +38 (097) 78-010-78 | +38 (099) 78-010-78⚡️ Отримуйте навички, які реально працюють на проєктах!
🧩 Nomad + Consul + Vault у тестуванні: як QA реально використовує цей стек у проєкті.Ці інструменти часто вважають “тільки для DevOps”.Але на практиці Nomad, Consul і Vault сильно підсилюють процес тестування — роблять його стабільнішим, безпечнішим і ближчим до продакшену.Розберемо, яку роль кожен відіграє саме для QA 👇🚀 Nomad — запуск тестового середовища та тестівЩо дає QA: • підйом ephemeral середовищ під PR / фічу • запуск автотестів як Nomad job (smoke / regression / perf) • перевірка поведінки сервісів при рестартах • тестування rolling update / canary • контроль ресурсів (CPU / RAM)👉 Тести стають частиною інфраструктури, а не “скриптом з ноутбука”.🧭 Consul — service discovery та health checksЩо використовує QA: • старт тестів тільки коли всі сервіси passing • відсутність хардкоду URL та IP • перевірка readiness сервісів • виявлення flaky через нестабільні сервіси • контроль доступності залежностей👉 Менше false-fail тестів, більше реальних багів.🔐 Vault — секрети та доступиЩо зберігаємо у Vault: • API tokens • DB credentials • service keys • OAuth secretsПереваги для QA: • секрети не лежать у коді • окремі доступи для DEV / TEST / STAGE • короткоживучі токени • мінімальні права доступу • відсутність витоків у логах👉 Безпека + чисті автотести.🔄 Як виглядає QA-флоу на практиці:1️⃣ Nomad піднімає тестове середовище (app + db + mocks)2️⃣ Сервіси реєструються в Consul3️⃣ Vault видає секрети для тестів4️⃣ QA-пайплайн чекає, поки всі сервіси стануть passing5️⃣ Запускаються smoke / regression / perf тести6️⃣ Збираються логи, метрики, репорти👉 Повністю автоматизований і відтворюваний процес.🧪 Що реально можна тестувати з цим стекомNomad: • рестарти сервісів • ліміти ресурсів • поведінку при деплої • стабільність під навантаженнямConsul: • readiness та health checks • правильну реєстрацію сервісів • маршрутизацію • залежності між сервісамиVault: • ротацію токенів • доступи по ролях • відсутність секретів у логах • роботу сервісів після оновлення ключів.⚠️ Типові помилки: • хардкодити URL у тестах • зберігати токени в .env або Git • запускати тести без перевірки readiness • використовувати один ключ для всіх середовищ • не ізолювати тестові середовища.🧠 Висновок:Nomad + Consul + Vault = це не просто DevOps-стек.Для QA це: • стабільні автотести • реалістичне середовище • безпечна робота з секретами • менше flaky • більше довіри до результатів тестуванняQA починає тестувати не тільки API, а й саму інфраструктурну поведінку системи.#AllAboutQA#qa
Майстер анонсів знову з вами 🌚Хоча ми намагаємось анонсувати події заздалегідь в наших соц. мережах, але я щось у себе в блозі викладаю з деякою затримкою. Мені хочеться щоб було більше заходів про мобільне тестування і платіжки, і як раз сьогодні у нас ці дві теми зійдуться в однині виступ. Де Анастасія розповість про платежі в середині мобільних застосунків. Анастасія Брижа: In-App Purchases під мікроскопом: як тестувати покупки в iOS та Android📆 Вівторок, 27 січня о 19:00📢 Формат заходу: лекція🔎 Про що подія?In-App Purchases є одним з ключових механізмів монетизації мобільних застосунків і водночас зоною підвищеного ризику для QA. Тут легко пропустити критичні баги, якщо не розуміти, як саме працюють стор, транзакції та контроль доступів.На лекції розглянемо:• що таке IAP і які типи покупок існують• ключові відмінності IAP у iOS та Android• як налаштовувати тестові середовища для покупок• як перевіряти Purchase та Restore Flow• типові помилки інтеграції і як їх знаходити• інструменти та сервіси, які допомагають QA у тестуванні IAP🎙 Анастасія про себеЯ QA Engineer в MEGOGO з 6-річним досвідом роботи. Працювала з мобільними застосунками в різних доменах, тому добре знаю, як по-різному можуть поводитися покупки в реальних продуктах. Люблю психологію, цікавлюсь тим, як люди взаємодіють із технологіями. Зумер, який внутрішньо відчуває себе міленіалом.🔎 Де знайти АнастасіюLinkedIn: https://www.linkedin.com/in/anastasiia-bryzha/Telegram: @anbryzha 🎟 Як взяти участь?• Придбати квиток (50% з вартості кожного квитка йде на ЗСУ). Посилання в шапці профілю ;)• Для учасників Суворої QA Community заходи спільноти безкоштовніДо зустрічі на лекції☃️
Figma у роботі QA: не просто «подивитись дизайн» 👀Якщо ти QA і досі сприймаєш Figma лише як «картинку від дизайнера» — ти недовикористовуєш потужний інструмент. Ось як Figma реально допомагає в щоденній QA-роботі 👇🔍 1. Чіткі вимоги без зайвих слів.Figma = жива специфікація: • відступи, кольори, шрифти • стани кнопок (hover / disabled / loading) • поведінка компонентівМенше «а дизайнер мав на увазі…» — більше фактів.🧪 2. Джерело тест-кейсів.З макетів легко витягуються: • позитивні та негативні сценарії • edge cases (довгі тексти, порожні стани, помилки) • адаптив (desktop / tablet / mobile)👉 Хороший QA читає Figma так само уважно, як і requirement doc.🧭 3. Перевірка відповідності UI.Figma + реальний інтерфейс =: • pixel-perfect (або усвідомлені відхилення) • швидке знаходження UI-дефектів • аргументовані баг-репорти зі скрінами та координатами💬 4. Комунікація без хаосу.Коментарі в Figma: • прямо в потрібному місці • з історією змін • без 20 повідомлень у чатіQA → дизайнер → дев — в одному контексті.⚙️ 5. Must-have навички QA у Figma.✔️ Inspect panel✔️ Component / Variant / Auto Layout✔️ Design system✔️ Prototype flowsЦе вже не «nice to have», а база.🚀 Висновок:Figma для QA - це:📐 специфікація🧪 джерело тестів🐞 інструмент пошуку дефектів🤝 майданчик для командної роботиХто вміє читати Figma — той тестує на рівень глибше.#AllAboutQA #figma #qa
TGLIST.COM.UA
