Я працюю в  американській консалтинговій компанії спеціалістом з якості вже 4 роки. За цей час я побувала у багатьох проєктах. Усього в сфері айті я вже понад 9 років.

Більшість ІТ-команд працюють за методологією Agile та використовують JIRA: продукт, розроблений Atlassian, який дозволяє відслідковувати помилки та гнучко керувати проєктами. JIRA має стандартний вигляд  дошки зі стовпцями:

To Do: задачі, які треба зробити

In Progress / in development: задачі, над якими працюють зараз 

In Testing: колонка для тестувальників 

Done: коли робота завершена, все перевірено, код йде на продакшн

Практично у будь-якому проєкті, де є тестувальники, буде передбачено стовпець “IN QA / TESTING”.

Хіба буде логічно , як що я, як QA, запропоную вам видалити «IN TESTING» колонку?

Першою реакцією буде думка,  що ми (тестувальники) знімаємо з себе будь-яку відповідальність, цілими днями нічого не робитимемо, лише дивитимемось YouTube? Тоді і якість продукту взагалі мала б стрімко впасти, ми — плавати в багах, а наші клієнти стануть незадоволені?

Звучить дивно та малоймовірно? Зазвичай, такою є перша думка команди, коли ти пропонуєш позбавитися цієї колонки.

Зараз розповім суть цієї ідеї , але спочатку я попрошу вас зупинитися на кілька секунд і подумати, в чому може бути проблема, коли у таблиці колонка «IN TESTING» йде аж після «IN PROGRESS»?

Колонка «IN TESTING»  (у тестуванні)  після «розробки» передбачає:

• «IN TESTING» охоплює лише те, що можна зробити після «розробки»;
•  «IN TESTING» – це здебільшого  «тестування» (єдина дія, що має сенс після «розробки»);
• «IN TESTING» – це незалежна діяльність від «розробки»;
• ця колонка належить тестувальникам і тестувальник стає bottleneck та gate keeper’ом
• членам команди можна розслабитися і не надто хвилюватися  за потенційні помилки, адже їх “виловлять” при тестуванні, а якщо не виловлять і баг потрапить у продакшн –то тут очевидна провина тестувальників, могли б трохи більше часу приділити роботі!

Головне питання, яке у мене виникає, коли я бачу колонку «IN TESTING»: чому якість –  це те, про що ми повинні піклуватися тільки в кінці тривалого процесу розробки?

Адже найважливіше – це запобігання помилкам, а не виявленню помилок наприкінці.

І неможливо додати «трохи якості» після того, коли завдання було реалізовано (зроблено програмістом) і переведено у колонку «IN TESTING».

Від теорії до практики

Під час реалізації останнього проєкту я обговорювала з командою видалення колонки «IN TESTING» і хочу поділитися з вами, як все відбулося.

Дуже важлива ремарка:  у нас є kick off-мітинги: короткі зустрічі перед тим, як пара програмістів або програміст перетягує задачу з “TO DO” в “In Progress” На цих зустрічах ми обговорюємо питання, як будемо тестувати, щоб зрозуміти, що і як. Також у нас є desk check-мітинги, коли задача виконана і програмісти показують, що було зроблено, зокрема код та інше. Детальніше про ці мітинги я розкажу в іншому дописі.

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

Отож, план видалення колонки виглядав у мене таким чином:

1. Обговорила з business analyst / іншими тестувальниками, яка проблема цієї колонки.
2. Запропонувала команді півгодинний мітинг, щоб усе обговорити.

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

Перша частина: ми почали з маленької вправи – я попросила кожного члена команди написати, що для нього означає стовпчик «IN TESTING», ліміт часу – 3 хв.

Ми проаналізували  усі стікери і, якщо було щось незрозуміле, ми швиденько обговорили це в команді.

Друга частина: бізнес-аналітик, тестувальники (я і колега) розповіли, які проблемні моменти бачимо ми; ці стікери були заздалегідь написані, але приховані, поки їх час не настав зараз.

Третя частина: пропозиції – групове обговорення того, що ми можемо зробити і чи потрібно щось робити.

Четверта частина: наступні кроки – команда разом шукає відповідь на запитання: “Що можна зробити?” і “Хто буде відповідальним?”.

Порада: видалення колонки може бути досить стресовим і великим кроком для команди, тому я рекомендую запропонувати команді спробувати цей новий формат (без колонки) упродовж  наступних 3-4 спринтів (кожен спринт – це 2 тижні у звичайному Agile проєкті) і опісля зробити власний висновок: залишати такий формат чи ні.

Дайте команді зрозуміти, що це не назавжди і, якщо їм не подобається, завжди можна повернути все до попереднього формату!

План “Б”: команда не хоче позбутися колонки.

У такому разі: 

1. команда повинна зрозуміти, що колонка не особисто «твоя»;
2. команда розуміє, що турбота про якість – це більше, ніж тестування;
3. команда розуміє,що ви не можете додати “трохи якості” до програмного забезпечення після того, як воно було створено.

А як у вас відбувається процес тестування? Чи є у вас колонка «IN TESTING», чи допомагає вона і чи ви задоволені процесом?