Моя концепція есенціалізму в керуванні QA-процесами

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, любий зацікавлений читач 🙂 Давай познайомимося? Я Аня. Займаю посаду Head of QA у невеликій, але потужній продуктовій компанії. У цій статті я розповім, як я будувала свій шлях до есенціалізму через автоматизацію процесів.

Ось сидиш ти на міті, а паралельно фафакає купа повідомлень, просять терміновий звіт, хтось пінгує про допомогу, комусь треба дати дедлайни по блокеру, на борді купа тікетів, а метрики шось показують деградацію... Впізнаєш себе, так?

Сучасний лід постійно балансує між десятками задач і «пожеж», які потрібні ще «на вчора». В нашій роботі все є важливим, все «необхідно» і все на зараз.
Але чи дійсно це так? Саме з цієї точки відштовхнуся і почну свою розповідь.

Спочатку давай я коротко нагадаю, що таке есенціалізм 🙂

Есенціалізм — це філософія свідомого вибору: робити те, що справді має значення. І у керуванні, і у бізнесі, і у повсякденному житті — це мистецтво визначати, де зусилля приносять результат, а де лише створюється ілюзія діяльності, яка просто жере ресурси.

Есенціалізм — це не про «лінь» як таку і не про «спрощення заради спрощення», і навіть не просто про визначення пріоритетів та тайм-менеджмент — це про усвідомлений вибір: куди вкладати енергію для більшої ефективності.

Як я прийшла до ідеї есенціалізму

Як і у багатьох перевтомлених постійним перенавантаженням людей, які несуть на собі велику купу відповідальності, завдань та випрацювання до вигоряння, в мене відбувся той самий переламний момент, який і привів до перегляду свого буття через призму есенціалізму.

В один «прекрасний» втомлений день, дійшовши до точки кипіння, я зрозуміла що все, з мене достатньо — потрібні зміни. Я забукала собі дейоф, взяла товстий нотатник, відерце кавки та сіла провітрювати думки на свіжому повітрі. Ось тут вже починається щось цікаве...

Мої перші кроки «Усвідомлення»

Сторінки блокнота я розділила на три колонки та потрошку почала їх заповнювати.

• В першу колонку збирала пункти: що мене відверто бісить, що жере мої ресурси і що жере мій час.
• У другу колонку навпроти кожного пункту ставила собі питання: «що мені потрібно для того, щоб цього позбутися?».
• В третю колонку вписувала свої відповіді (рішення). Для тих пунктів, на які я не могла дати собі відповіді, ставила великі червоні позначки.

💡Вже на цьому етапі я зловила певні інсайти про те, що для вирішення деяких питань треба просто почати діяти, а деякі питання, на жаль, приводять мене у глухий кут.

Отриманий перелік я переглянула через підхід есенціалізму, що допомогло мені багато побачити й прокласти наступні кроки.

Цими кроками стали такі дії:

👣 Побудувала собі чіткий чек-ліст послідовних дій.

👣 Визначила, які дані та інструменти мені потрібні для реалізації.

👣 Виділила собі місяць на спостереження та адаптацію до нового напряму.

👣 Прописала план «розчищення» шляху для побудови «майбутнього».

Наступним етапом стало розчищення та спрощення простору.

За виділений на адаптацію час (місяць) мені вдалося виявити та поборотися з кількома головними пожирачами часу, назвемо їх дементорами 😉Розповім про кожного з них детальніше.

Перший дементор — Slack

• Всі канали розклала за категоріями: важливі / інформаційні / загальні / розважальні.
• Канали, де протягом 30 днів мене не пінгували, не писали мені, не писала я — просто вийшла з них.
• Інформативні, які містять потрібну (не критичну) інформацію — зам’ютила.
• Важливі та критичні залишила як є.

💡 На цьому етапі теж були виявлені певні інсайти. Тумблювання між постійними фафаканнями сильно виснажували увагу та давали відчуття постійної втоми.

🏆 Перші результати

«Шум» та постійні пінгування зменшилися в 4-5 разів. В процесі розчищення було виявлено багато застарілого «сміття», яке ми з командою видалили. Також налаштували щоденний дайджест (Recap) по відібраним каналам. Це стало маленьким бонусом і для інших.

Другим дементором стали мітинги

• За тим самим принципом, як і зі Slack, я відсортувала свій календар мітів: загальні (інформаційні), де я лише слухач / важливі, де я слухач / важливі з активною участю.
• Міти без «корисного навантаження» я видалила з календаря.
• Інформативні міти, на яких можна почути щось корисне, я замінила свою присутність аналайзерами на кшталт Sembly.
• Важливі залишила як є + додала Sembly.
• Почала казати «Ні» і виходити з мітів вчасно — навіть якщо вони ще тривали.

💡На цьому кроці я зловила важливу думку: світ не впав від того, що я пішла з міта вчасно. Страх та сором з цього приводу були даремні й ніхто мене за це не звільнив. Це навіть стало невеликим прикладом для інших.

🏆 Отримані результати

Кількість моїх годин на дзвінках скоротилася майже на 40%! А разом із тим потроху почало зникати відчуття постійної зайнятості без «вихлопу». Додатковим плюсиком стало те, що культура мітів трошки покращилася, тому що люди почали намагатися дотримуватися рамок та таймінгу.

Головним з дементорів стала бюрократія

Цей крок, звісно ж, об’ємний та важкий, тому для зручності я розділю його на декілька частин. В цьому кроці брала участь вся QA-команда.

• Ми переглянули наш Confluence, пооб’єднували схожі за сенсом доки.
• Повидаляли дублікати та просто застарілі блоки.
• Розсортували розпочаті доки та залишили лише актуальні.
• Переглянули нашу тестову документацію під питанням «що з цього нам дійсно потрібно для постійного вжитку?». Припинили підтримувати ті види, які є просто книжковими «еталонами» та ті, які просто хотіли бачити наші лайн-менеджери, без розуміння їх доцільності.
• Види звітів для різних рівнів об’єднали та скоротили до необхідного рівня.

💡На цьому етапі я вхопила ще один важливий інсайт. Якщо гарно в цифрах та метриках презентувати пояснення, чому нам «це потрібно» чи «не потрібно», то можна отримати потрібний мені результат.

🏆 Результати

Ми буквально полегшили Confluence майже на третину. Тестових артефактів стало помітно менше і відповідно звільнилася значна частка часу, який раніше йшов на підтримку зайвих рухів. Репортування спростилося в кількості та якості. А головне, відчуття гіпер-контролю помітно зменшилося.

Для правильного помірного навантаження тіми при проходженні нашого такого собі докатону (відсилка на хакатон/баготон 🙂) мені в нагоді став перегляд ставлення до делегування.

• Були назначені відповідальні за певний типи роботи.
• Всі види роботи були ± рівномірно розділені між всіма, що зменшило плутанину і прибрало подвійну роботу.
• Стан контролю виконання полегшився до рівня «підстрахувати», а не відстежити кожен пчих.

💡 Розподілена відповідальність зменшує кількість факапів. Працювати з факапами простіше на основі прогнозування ризиків, а не гіперконтролю. Підстраховувати значно простіше, аніж контролювати.

🏆 Результати

Рівень довіри та відповідальності між всіма членами команди підвищився. Рівень контролю пом’якшився та став пожирати менше моїх особистих ресурсів.

Ось так, повним інсайтів роздумів та перших перемог, завершився мій очисний адаптаційний період. Настав час шукати зони максимального результату.

Оскільки в мене вже з’явився розвантажений час, я почала наново вчитися його розподіляти та будувати нові правила свого тайм-менеджменту. Почала робити собі «тихі години», (методика зі списку корисних порад по ворк-беленсу, до речі). Під час цих годин я шукала, думала, експериментувала. І ось нарешті я зрозуміла, чого я хочу.

Я хочу зробити «автоматизований тижневик» своєї тіми!

Хотілось створити єдину систему, де всі робочі активності, задачі, апдейти та показники збираються в одному зручному місці. Так, звісно ж, я можу подивитися щось в Jira, можу піти в Confluence, можу сходити по своїх запитах в будь-які інші місця або тули. Так, але я хочу, щоб мені було зручно, щоб можна було економити час на цих рутинних витратах.

Отже, центром ідеї став Календар. Саме він повинен був відображати все, чого я потребую. Я сіла малювати в Miro велику схему потреб, зв’язків, тулів та очікуваних результатів на кожному напрямі. Не з першого разу, з купою корекцій, але вийшло.

Перше, що я зробила — отримала дозволи згідно NDA та апруви на потрібні тули.

Трошки відхилюсь і коротко розповім про умови безпеки по NDA, які я пройшла перед початком втілення.

🔐 Отримала консультації та поставила питання про додавання в робочі контракти окремого розділу про AI-policy (дуже актуально наразі й дуже рекомендовано до виконання).

🔐 У Make та GPT не передаються чутливі дані користувачів.

🔐 З GPT працюємо лише за описами фіч або тікетів без персональних даних.

🔐 Для внутрішніх сценаріїв діє AI-policy команди.

🔐 Частки коду та інші «глибинні» деталі продукту не передаються в GPT.

🔐 Отримала письмове підтвердження про узгодження цих правил і почала діяти.

Повертаємося до нашого етапу «великого будівництва» 😁

Ось основний перелік інструментів, які знадобилися для реалізації:

Саме час дійти до обговорення схеми зв’язків та автоматизованих сценаріїв, які працюють на заповнення тижневика та репортів.

Зараз ми разом пройдемо логічний ланцюг одного потоку, від Jira-тікета (блакитний стікер) до репорту (помаранчевий стікер).

⚠️ Схема поверхнева і містить лише необхідний для розуміння приклад зв’язків.

Отже, підемо логічними кроками.

Коли тікет потрапляє у певний статус розробки, спрацьовує відповідний тригер для Make (малиновий стікер). По цьому тригеру запускаються сценарії «№ 1» та «№ 2».

• Перший сценарій генерує чек-ліст для тестування і повертає його в тікет у заготовлену під це колонку.
• Другий сценарій генерує необхідний мінімум тест-кейсів для покриття. Згенеровані кейси записуються в Sheets (або Testrail, або X-Ray, або інший аналог, доступний в інтеграціях Make). Після запису кейсів в тікеті заповнюється виділений під це чекбокс.

Таким чином тікет оброблений за методом Shift-left і готовий до тестування.

Поки він знаходиться в роботі у QA, іншими сценаріями в календар передаються «Live mode» дані, які записують туди, який тікет в роботі, скільки часу він в роботі, з позначкою, чи є АІ-покриття, чи був цей тікет запланованим в роботу та інші дрібні деталі.

Коли цей тікет успішно проходить реліз (деплой на прод), спрацьовує інший тригер і запускає сценарій «№ 3».

• Третій сценарій генерує якісний нарис статті для Confluence (або Notion, або інші аналоги, доступні в інтеграціях) і одразу публікує її.
• Після проходження сценаріїв «№ 2» та «№ 3», які записали готові дані в Sheets та Confluence, починають свою обробку сценарії «№ 4» та «№ 5», які рахуються відсоток покриття Goals, які є у команди. Наприклад, встановлена ціль написати 150 статей та 250 тест-кейсів. Відповідно сценарії рахують отриману з доки (тікета) кількість відносно цілі і записують відсоток покриття одразу в колонку відповідного Goal.
  (приклад на скріні, колонки «Вимога» та «Відсоток»).

  

• Необхідні дані аналітики з Goals передаються в календар сценарієм «№ 6». Таким чином виходить, що паралельна робота кількох сценаріїв за лічені хвилини виконує роботу замість мене та інших QA.

• Далі вже бюрократична репортувальна частина, вона вже виходить з усіх зібраних в тижневику даних. Сценарії «№ 7», «№ 8», «№ 9» (кожен відповідає за свій напрям) беруть свої дані, проводять аналітичні підрахунки та передають результати у заготовлені шаблони репортів.

Опишу трохи, з чого складається наш тижневик.

⚠️ Через зрозумілі умови я не можу показати справжній календар, тому перемалювала його за реальними мотивами.

В календарі міститься перелік:

• З каналів слаку передаються дані по day off та дейлі апдейти. Таким чином автоматично відмічається, хто відсутній сьогодні, які задачі були в роботі вчора та повинні бути сьогодні. В аналітику піде аналіз, наскільки збігаються очікувані та фактичні задачі в роботі, різниця між очікуваним та фактичним естімейтом.
• Зі звичайних календарів передаються дані по забуканих мітах у тіммейтів.
• З Jira фіксуються актуальні задачі. Тікети мають свої підтипи: тікети в тестуванні, на створення документації та інші. Кожен тип задач має свій колір задля легшого сприйняття. Наприклад, зеленим кольором помічені тікети, які пройшли обробку АІ-сценаріїв і мають покриття артефактами. Світло-зелені тікети — ті, які ще не були оброблені. В аналітику буде рахуватися кількість оброблених та необроблених тікетів і в результаті я побачу для себе пояснення, чи потрібно мені вносити якісь апдейти для покращень.

Що я маю у результаті:

• Автоматизована AI-генерація економить ресурси кожного з нас. До того ж рев’ю згенерованих даних займає до 70% менше часу та сил, аніж створення з нуля.
• Оскільки сценаріями можна будувати покриття неочікуваних/нестандартних кейсів (ad-hoc, test tours, risk-based testing), то якість покриття підвищена, бо тестувальнику не потрібно це тримати в голові, у нього вже є підказки (нагадування). Для динамічних продуктів це може бути основою мануал тестінгу задля економії часу.
• Через те, що всі необхідні мені дані зібрані в одному місці, я одразу можу бачити, які у нас йдуть перекоси або навантаження. Де у нас вимальовуються слабкі місця і що вимагає наших правок.
• Всі наші активності автоматично рахуються в Goals, OKR, KPI, метрики. Похибки в цих підрахунках значно зменшені. Мій час на це не витрачається.
• У нас є повна прозорість для кожного тіммейта та для менеджмента.

Моєю метою було дійти до суті — вважаю, що я її знайшла

Чи перетинається моя автоматизація з підходом есенціалізму? Впевнена, що так, оскільки я знайшла той ресурс, в який я направляю енергію та отримую більше результату.

Автоматизацією я заміняю багато рутини, яку ми виконували руцями і думали про неї 24/7. Наприклад, АІ-сценарій генерує готовий баг-репорт за парою речень від тестувальника. І не треба платити за тул, який це робить, і не треба контролювати, щоб цей тул був увімкнений. І через те що генерація відбувається у внутрішній АІ-частині, то я не піклуюся про витік інформації. Зручно? Швидко? Так.

Щоб знайти цей ресурс, я розчистила свою рутину. Саме тому в мене і з’явилася змога відшукати свої напрямки руху. Перетинається це з розумінням есенціалізму? Так.
Мої дії вивільняють ресурси — мої та моєї тіми. Приносять користь, підвищують якість, а головне — економлять гроші та час. Загалом ще й перетинаються з бізнес-правилом 80/20. Все це дає можливість легше дихати й шукати нові ресурси максимальної вигоди.

А ви задумувалися, де саме може ховатися ваш «прибутковий» ресурс? Чи давали собі можливість зупинитися, видихнути та прибрати зайве?

Наостанок напишу трошки легких порад 🙂

Підхід до автоматизації кожен будує для себе, виходячи зі своїх потреб та ресурсів (немає єдиного рецепта).

На мій погляд, простіше писати багато дрібних сценарів замість кількох об’ємних, оскільки їх легше фіксити та підтримувати. Есенціалізм не про швидкість, а про зважені кроки. До цього варто приходити поступово.

Бажаю вам знайти свій шлях до есенціалізму. Тримайте цукерку для натхнення.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.