Як покращити якість на проєкті. Практичний досвід впровадження змін там, де вони треба, але про це не знали

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

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

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

Огляд проекту:

До моєї ролі менеджера з контролю якості процес розробки був націлений на ефективне надання нових функцій користувачам. Це був швидкий процес, але не масштабований. Ми зіткнулися з кількома критичними проблемами:

• Непослідовне планування виконання робіт: не було послідовності в плануванні та виконанні завдань. Роби на вчора. кидай все і роби іньше...
• Невизначеність у QA плануванні: Команда QA часто не знала коли і що буде релізитись. Часто команда дізнавалась про реліз постфактум.
• Відсутня документація. Через відсутність чіткої документації та вимог керівнику проекту та команді було складно відрізнити реалізацію від бажання клієнта.
• Планування завдань і терміни: Планування завдань і оцінка термінів доставки практично не існувала, що ускладнювало керування проектами.
• Регресійне тестування : наші цикли контролю якості були витрачені на регресійне тестування (Смоук по суті), яке не охоплювало всього функцінала.
• Погано структуровані завдання: багато завдань були погано визначені та не оновлювалися під час розробки.
• Відсутність відповідального за процес чи завдання: не було людини яка б відповідала за якийсь функціонал. Тому винні були всі і ніхто.

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

Потім я ініціював створення тестової документації. Це як створення будівельних блоків для міцної конструкції. Без документації не має точки узгоджень і тим самим не можливо далі покращувати процеси.

Покращення, які я спочатку пропонував, були досить простими:

1. Раннє тестування
2. Рання участь у забезпеченні якості (QA).
3. Участь в оглядах дизайну
4. Проактивне створення документації
5. Визначені спринти та часові рамки
6. Автоматизація регресійних тестів

Отже, ось план гри:

1. Окресліть поточний процес і отримайте схвалення керівництва.
2. Почніть із проектної документації
3. Розпочніть раннє тестування щоб виявляти проблеми, перш ніж вони переростуть у великі проблеми.
4. Тонко налаштуйте спринт і встановіть приблизний час для кожного завдання. Це як дати кожному дорожню карту.

Крок 1: Визначення поточного процесу

Проблема: Вічна зміна процесів і все на вчора , зміна пріорітетів по пару разів на день що було наче хаос. Як сказав один геніальний бізнес-аналітик,"Не працюйте у місці з невизначеними очікуваннями«.

Рішення: Побудуйте діаграма яка окреслює процес і підтвердьте що це бачення є правильним. Незважаючи на те, що керівництво не сприймало окреслення процесу, вони були вдячні за те, що зрозуміли, на чому вони стоять.

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

Крок 2: Створення тестової документації

Проблема: відсутність тестової документації мала не тільки серйозні наслідки, але й викликала головний біль. Тож це був найкращий другий крок: Не має документації, а хто знає як мало бути, я зробив як зрозумів...

Рішення: Започаткували тест документацію щоб було єдине бачення як працює фіча або функціонал. Почати з нових фіч а потім по трошку набивати беклог.

Вплив: Тестова документація відіграла вирішальну роль; вона стала міцним фундаментом проекту і процесів.

Крок 3. Ранне тестування

Після створення тестової документації мені стало зрозуміло, що наступний крок має бути залучення QA якомога раніше в процесах створення фіч і функціоналу можна порівняти на читання посібника користувача перед початком нової гри. Цей крок дозволив нам повністю зрозуміти нові функції ще до того, як розробники почали їх створювати

Вплив:

• Було збережено час для команд розробки, контролю якості та управління проектами, що дало нам більше часу, щоб зосередитися на тому, що дійсно важливо.
• Чіткий і стислий опис завдань зменшує кількість дефектів,роблячи нашу роботу більш гладкою та менш схильною до помилок.
• Якість релізів нашої проекту значно піднялась

Крок 4: визначені спрінти та покращений контроль якості

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

Вплив:

1. Покращена ефективність контролю якості: оновлений процес усунув втрату часу на роботу з контролю якості після спринту.
2. Підвищена якість продукту під час випуску : якість продукту значно підвищилася під час випуску.

Проблеми під час впровадження:

Опір менеджменту впхати пріорітетну таску у спрінт: перші виклики стосувалися того, що зацікавлені сторони часто наполягали на додаванні завдань як «обов’язкових» у спрінтах. Це перешкоджало ефективному виконанню процесів спринта. Однак цю проблему зрештою вдалося вирішити шляхом ознайомлення зацікавлених сторін з ключовими показниками ефективності (KPI) і наслідками запровадження гарячих завдань.
Опір розробників раннього залучення QA: спочатку розробники скептично ставилися до необхідності залучення QA до процесу. Однак, коли вони зрозуміли переваги спрощених процесів, таких як перегляд документації замість тривалих обговорень з QA або керівництвом проекту, ці сумніви були швидко вирішені.

Висновки:

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

1. Ефективне вдосконалення процесу розробки: впровадження вдосконалень у процес розробки дало значні переваги.
2. Створення надійної тестової документації: створення комплексної тестової документації сприяло більш ефективному робочому процесу і збереженню часу команди
3. Економія годин і спрінтів: зусилля з оптимізації призвели до економії часу та ресурсів для всіх членів команди.
4. Підвищені стандарти якості: встановлення стандартів якості відіграло ключову роль у пом’якшенні проблем, пов’язаних із виробництвом.

Стаття була перекладена автором статті на medium.com/...​h-baby-steps-7d805ae1ebbf