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
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 спільноти безкоштовні.Долучайся до ком'юніті та отримай безліч додаткових корисних матеріалів.
📈 Зі зростанням кількості 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⚡️ Отримуйте навички, які реально працюють на проєктах!
TGLIST.COM.UA
