СТАНІСЛАВ ПОЛЬСКОЙ
Трохи промене
Senior Software Qualty Engineer at
2
8 років в QA
4 роки тому почав лідати проєкт
(бо так сі стало)
0.5 року тому вирішив розповісти
про цей дсвід людям
HERE WE ARE
2 роки тому почав
реформування QA процесів на
проєкті
(бо зрозумів що по старому жити не можна)
3.
3
ОЧЕВИДНІ НЕОЧЕВИДНІ
ПРОБЛЕМИ
QA =Тестування
Tестувальники бачать тікет на грумінгу
вперше (в ліпшому випадку)
Проблеми із раннім залученням
Відсутність чітких критеріїв хто кому і коли
передає тікет
Відсутність чіткої відповідальності
Всі порсаються у власних пісочницях
Проблеми комунікації
Пошук винних замість пошуку рішень
Немає конструктиву
4.
4
ЯКІСТЬ — ЦЕСПРАВА
ВСІЄЇ КОМАНДИ
Якість залежить від кожного: BA, девів, QA.
Співпрацюйте
Вони необхідні для спільного розуміння стану задач.
Використовуйте DoD та DoR
Формалізація процесів
RACI матриця або Handover матриця
Ревью - для всіх
QA та деви беруть участь у рев’ю вимог (раннє
залучення QA).
BA і деви беруть участь у демо, тестуванні та рев’ю
імплементації (пізнє залучення BA).
Тестування - теж для всіх
6
Чіткі шаблони вимог,тасок,
багів.
Метрики якості та Quality
Gates для прозорості й
контролю процесів.
Зрозумілі Acceptance
Criteria, які узгоджені між
BA, розробниками і QA.
ПРОЗОРІСТЬ ПРОЦЕСІВ
7.
7
АТМОСФЕРА ДОВІРИ
ЧЕРЕЗ СПІВПРАЦЮ
Помилки— це проблеми
процесу, а не конкретних
людей.
Підтримуйте прозорість,
відкритість та заохочуйте
підсвічувати проблеми,
а не приховувати їх.
8.
8
ПОСТІЙНИЙ РОЗВИТОК ТА
АДАПТАЦІЯКОМАНДИ
Регулярно аналізуйте та
обговорюйте помилки,
конфлікти, непорозуміння
(ретро, фідбек-сесії,
«lessons learned»).
Використовуйте анонімні
ретро-борди, це чудовий
інструмент!
9.
9
ІТОГІ ПОДВЄДЬОМ
Не бійтесянав’язувати QA ініціативу
Процеси та документація хороші інструменти
поки вони мінімалістичні
Фіксіть процеси а не людей
Створюйте атмосферу в якій не страшно
розказати що ти налажав