Telegram statistics channel - @ryconsulting

Друзі, сьогодні я хочу поговорити з вами про метрики в QA, які ми маємо збирати для того, щоб покращити наші процеси.Почнемо з першої метрики ⬇️Для початку давайте домовимося, що зараз ми поділяємо метрики на кількісні та якісні.🔹 Кількісні — збирають кількісні показники,🔹 а якісні — збирають показники якості.Перша з кількісних метрик, яку я пропоную впроваджувати на проєкті — це Escaped Bugs 🐞Що це взагалі за така метрика?Коли ми тестуємо наш софт, ми знаходимо різні баги.І нам потрібно підраховувати всю кількість багів, яку ми знайшли.А якщо на проді виявляються баги — то ми маємо заміряти, який відсоток багів проникає на прод з тієї кількості, що була загальна.Таким чином ми будемо розуміти:який відсоток наших багів потрапляє на продакшн.Ця метрика дає можливість визначати, як часто баги прориваються на прод, згідно з цією кількістю.📌 Якщо ти хочеш поглиблено зрозуміти, як працювати з цією метрикою, як вона допомагає нам визначати баги — заповнюй анкету на безкоштовну персональну консультацію до мене 👇🏼https://forms.gle/boJPMtoKspT7tDeQ8

🧠 Як підготуватись до співбесіди так, щоб отримати свою омріяну роботу? Поради QA з 12-річним досвідомУ 2012 році я йшов на свою першу співбесіду, маючи в голові лише одне питання: «А що взагалі там питатимуть?» Гуглив списки питань, зубрив терміни, хвилювався.Сьогодні, маючи 12 років досвіду, я сам проводжу співбесіди і точно знаю, чого очікують від кандидата, і що допомагає виділитись серед десятків претендентів.🔹 Ось кілька практичних порад, які реально працюють: ▫️Розумій свою цінність. Не просто повторюй, де працював, а показуй, які проблеми вирішував ▪️Готуй приклади. Твої кейси — найкраще підтвердження твоїх навичок ▫️Знай компанію. Знання про продукт і бізнес показує твій інтерес, а не просто пошук «будь-якої роботи» ▪️Питання = інтерес. Продумай, що сам запитаєш. Це діалог, а не допит ▫️Впевненість. Її дає тільки хороша підготовкаІ головне — бути собою, але у версії 2.0: чітким, сфокусованим, професійним📌 Якщо готуєшся до співбесіди або вже мав невдалі спроби — приходь на мій розбір: Розберемо твої відповіді, підготуємо сильні кейси, і я покажу, як уникнути типових помилок.👉 Напиши мені «Співбесіда» — і домовимось про формат#qa #співбесіда #qaпоради #тестування

Чому новачки в ІТ залишаються без роботи? 🤔Після курсів здається, що ось-ось все буде — і робота, і оффер, і перша ЗП в доларах. Але проходять тижні, а відгуки — без відповіді. Знайомо?✅ Ось 5 причин, чому так трапляється:💻 Немає практики. Курс — це добре, але без прикладів реальних проєктів у портфоліо роботодавцю складно оцінити твої навички📉 Сире резюме. Часто або занадто загальне, або навпаки — повне технічних термінів, які ти сам погано розумієш⚡️ Пасивність. Просто відгукуватися на вакансії недостатньо. Потрібно бути активним: писати рекрутерам, нетворкати, бути видимим🚫 Провальні співбесіди. Боятись питань типу “Розкажи про себе” — це ок, але з цим треба працювати. Бо часто саме на цьому етапі все і зупиняється. Ви навіть не можете впевнено розповісти про себе, що вже говорити про технічну співбесіду💰 Завищені очікування. Всі хочуть одразу у великий проект і з хорошою ЗП. Але часто треба починати з простішого, щоб далі зростати. Маленькі компанії, швидше дадуть вам ріст і можливість працювати Якщо ти зараз у цьому стані — не панікуй. Я бачив сотні схожих ситуацій і знаю, як з цього вибратись.Пиши мені в телеграм @yakymchuk_roma «+» та я підкажу лайфхаки, як швидше знайти першу роботу та почати заробляти в ІТ 📩

Коли я тільки починав у тестуванні, всі мої тести жили в Excel'і. Сторінка за сторінкою, кольорові комірки, якісь формули, коментарі збоку. І тоді це здавалося нормальним. Поки не настав момент, коли:🔸 потрібно було швидко знайти конкретний тест — і я гортав десятки рядків🔸 менеджер попросив прогрес по регресії — і я малював діаграми вручну використовуючи чарти в ексельці🔸 з’явилась нова людина в команді — і я витрачав години, пояснюючи, “де що лежить”Тоді я вперше глянув у бік тест-менеджмент систем. І чесно — зміни були відчутні вже з першого тижня.Тест-менеджмент системи — це не просто зручність. Це структура, прозорість і масштабованість:✔️ Всі тести — в одному місці✔️ Зрозуміла структура — як для новачка, так і для ліда✔️ Можна бачити історію змін, запускати тест ранс, будувати звіти✔️ Легко пов’язати тести з багами, вимогами, задачами в Jira✔️ І головне — це економить час і нерви всієї командиЗараз я просто не уявляю, як можна ефективно працювати без такої системи, особливо коли проект не з одним-двома флоу, а великий, живий, складний.Тож, якщо ви досі працюєте в Google Sheets або Word — подумайте, скільки часу ви витрачаєте на те, що вже давно можна було автоматизувати.І не треба одразу щось велике типу TestRail. Є купа безкоштовних або доступних рішень — Testomatio, TestLink, Xray, PractiTest, Zephyr...Ваша робота заслуговує на зручні інструменти. А не на хаос з табличок 🧩

А навіщо ці Bug Triage мітинги?Часто на проекті настає час, коли накопичується дуже багато багів і ми маємо хоч якось їх менеджити. І ось для того щоб правильно впорядкувати та відсортувати баги, нам потрібно проводити ці Bug Triage мітинги. На такому мітингу мають бути присутні, QA, це може бути або лід або хтось хто добре знає систему, Dev або Tech Lead, PO продукт овнер.На мітингу в першу чергу звертають увагу на критичні дефекти та порядок їх виправлення. Тому що деякі баги можна відкласти, а деякі можуть бути вже не актуальні, і їх взагалі потрібно закрити.Задача мітингу актуалізувати ситуацію по багам, визначити пріоритет їхнього усунення, почистити дублікати або баги які вже не актуальні. Часто навіть під час мітингу вдається перевірити чи баг досі актуальний і або додати йому відповідний пріоритет або закрити, якщо він вже не актуальний.Bug Triage бажано проводити регулярно хоча б раз на тиждень. В результаті можна оформити табличку в Confluence з переглянутими багами та відсортувати їх за пріоритетами. Закриті баги та дублікати також вказуємо, щоб команді було зрозуміло, які вже неактуальні. Ну і щоб вони пам'ятали що ці баги були закриті і мати на увазі коли буде проводитись регресія, переглядати цей список, як ризикові.

Привіт колеги 👋Продовжуємо тему тест-менеджменту і сьогодні поговоримо про види стратегій тестування Аналітична Стратегія ◽️Узгодження тестування з чітко визначеними базисами тестування (Вимоги, дизайни, прототипи, діаграми і т. д.) ◾️Вимірювання тестування на основі тестових базисів (Матриця трасування вимог, матриця трасування багів по відношенню до тестів) ◽️Запобігання дефектам шляхом раннього аналізу тест базисів (Аналіз вимог, аналіз ризиків, дослідження за допомогою декомпозиції)Стратегія на основі моделей ◾️Моделювання на основі реальних статистичних даних, наприклад навантаження на систему, як от аналіз кількості клієнтів у магазині на чорну п’ятницю ◽️Аналіз вхідних і вихідних даних, наприклад шифрування конфіденційних даних або паролів користувачівМетодична стратегія ◾️Використання чеклістів та тест кейсів ◽️Використання чітлістівРеактивна Стратегія ◾️Використання тест чартерів та інших підходів дослідницького тестування ◽️Тест кейси розробляти згідно технікам основаним на попередньому досвіді або на попередніх дефектахКонсультативна Стратегія ◾️Зацікавлені сторони з бізнесової сторони надають інформацію по девайсам, платформам та іншим можливим конфігураціям, на яких потрібно провести тестуванняРегресійна Стратегія ◽️Використання аналізу залежностей для відбору тестів ◾️Використання пріоритезації і кластеризації функціоналуСтратегія Автоматизації ◽️API тестування ◾️UI тестування ◽️Інтеграційне тестування ◾️Мобільне тестування

Сьогодні хотів би підняти черговий раз таку тему, як Обговорення беклогу перед початком ітерації. Завжди коли я бачу в компаніях якісь проблеми з нерозумінням кінцевої мети по написаній документації або різне розуміння того, як мають бути реалізовані вимоги, то найчастіше у цих командах немає стадії на якій обговорюються вимоги.Чому важливо мати стадію обговорення вимог:- це дає можливість краще зрозуміти, що має бути виконано під час майбутньої ітерації- можливість обговорити існуючі вимоги та виявити якісь неточності або суперечності в них- обговорити з командою та можливо внести правки в вимоги- ну і найважливіше, розуміти що має бути реалізовано на командному рівні, коли всі обговоривши знають, як це має бути виконано і як буде тестуватися.Ну і найчастіші проблеми - це виявлення багів на більш пізній стадії, через нерозуміння вимог. Втрата часу на зайву комунікацію для вияснення проблемних моментів і знову ж таки на пізніх етапах розробки. Тому старайтеся, якомога раніше долучатися до розробки та підвищувати якість своїх продуктів.

Всім привітПочнемо з головних новин, багато хто з вас вже знає, а хтось ще ні. Я виїхав з України.В липні цього року мене мобілізували, не по моїй волі звичайно. Спочатку я прийняв цю ситуацію та намагався знайти виходи на ІТ підрозділи, де дійсно можу бути корисним. Проходив різні співбесіди. І все наче вже мало бути добре…Але паралельно на навчаннях, багато хлопців розповідали різні історії про те, що з цієї частини всіх відправляють відразу на 0, і ти не зможеш перевестися. Я також уточнював цю інформацію у своїх командирів, які прямо відповіли, “Ти можеш зробити відношення (документ про перевід між частинами), але відразу скажу що можеш засунути його в одне місце, бо у нас це не працює, куди скажуть туди й тебе відправимо” Ця ситуація звісно ж не сильно мене влаштовувала. Також на навчаннях в польових умовах, я сильно захворів та ліг в госпіталь на лікування з високою температурою та постійним кашлем, що не зупинявся вже кілька тижнів. Певний час поки я лікувався, я все ще намагався якось перевестися в інший навчальний центр, щоб звідти попасти в ІТ підрозділ, але всі дії які я робив, не давали бажаного результату.Хлопців з якими я навчався вже відправили на фронт і через тиждень, я дізнався що половини складу вже немає, що мене дуже засмутило. Тоді я вирішив залишити терени нашої країни. Для себе я зробив вибір, жити і приносити користь там, де я можу. Більшість людей мене підтримує, це дуже приємно, але є ті, хто засуджує цей вчинок. Але це моє життя, яке в мене одне, і мій вибір. Я хочу жити і продовжувати забезпечувати свою сімʼю, виконувати свою місію - навчати. Та донатити, як і робив це весь час.

І так, давайте почнемо з візуального штучного інтелектуVisual AI - це грубо кажучи комп’ютеризоване око людини, яке дозволяє розпізнавати елементи на сторінці та порівнювати їх з очікуваними.Зазвичай ми сконцентровуємо свою увагу на функціональне тестування і часто не переймаємось за кожну деталь UI елементів на сторінці чи навіть в різних браузерах. В свою чергу Visual AI тестування допомагає нам наконфігурувати області, які ми хочемо перевіряти, виставити браузери і так далі, щоб воно все це перевірило за лічені секунди.І якщо говорити про звичайну автоматизацію, де ми пишемо тести, шукаємо селектори і витрачаємо купу часу, тут же все робиться в рази швидше і доступніше.Для автоматизаторів воно значно спрощує роботу і перевірку тисячі асершенів вже може виконувати штучний інтелект, для тих хто перевіряв завжди все вручну, це дасть можливість тільки дивитися на результати проблем, які виникають і вже після цього заводити баги.Звісно що це все не 100% досконало працює, але зараз вже дає дуже високу якість. Я вам залишу ряд інструментів, які дозволяють працювати з Visual AI автоматизацією:- Applitools- Browserstack- Katalon- LambdaTestІ закину вам відосик, як приклад, щоб ви хоч розуміли, що то такеhttps://www.youtube.com/watch?v=SfbkC2tBI2k

Ну раз просили про AI в тестуванні, погналиAI-Driven Test Automation - ця штука зробила революцію в автоматизації. Ще в далекому 2016 році, коли я вперше почув про те, що тести за допомогою штучного інтелекту можуть самі себе пофіксити. Тобто він аналізує зміни, які були внесені в вашому додатку і підправляє тест згідно тим змінам. Це неабияк зменшило час на підтримку тестів та підвищило ефективність автоматизації.Regression Suite Optimization - це просто те, чого я давно чекав, штучний інтелект дозволяє проаналізувати зміни в коді та вибрати найбільш релевантні тести, що значно скорочує час на тестування та оптимізує покриття.Intelligent Test Case Generation - штучний інтелект може допомогти з генерацією тестів, аналізуючи вимоги, це те що ви можете робити з GPT та іншими AI генераторами. Це допомагає нагенерувати ідей для тест кейсів. З досвіду використання одного з таких інструментів у нас на проекті, скажу що досить якісно створює тест кейси, але важливо робити рев'ю тестів та додавати степи або тестові дані, більш лаконічно.Насправді ця тема досить обширна, постараюся підготувати ще кілька статей про різні види тестування за допомогою штучного інтелекту, та спробую показати приклад генерації тестів за допомогою AI інструментів.