Traceability, прозорість та тест рани

Прийшла пора поговорити про traceability — запоруку впевненості у якості продукту і гаранта адекватності прийнятих рішень. Traceability пов’язує різні процеси, аспекти та артефакти розробки між собою таким чином, що загальна картина стає цілісною і починає мати сенс. Без цього механізму вимоги, імплементація та тестування лишаються “приблизно про схоже”, але без жодної конкретики, тож в разі необхідності аналізувати стан речей, вирішувати проблеми чи артикулювати певні рішення, вам доведеться пояснювати на пальцях.

Отже, що таке traceability?

Для нас з вами, занурених у процес розробки, traceability — це зв’язок одного процесу чи артефакту з будь-яким іншим процесом чи артефактом. Це якийсь осмислений зв’язок, формат, значення та зміст якого встановлюємо ми.

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

Епік / Юзер сторі до фіч.

Коли в роботу береться новий епік чи юзер сторі, хорошою практикою є заздалегідь визначити, які частини продукту можуть бути затронуті змінами, які буде впроваджено. Це спрощена версія того, що називається impact analysis — аналізом впливу. Пов’язуючи таким чином теоретичні фічі із фактичними ми нарощуватимемо мапу взаємозв’язків, яка може стати в нагоді пізніше, особливо при плануванні регресії. Але це не тільки про те, щоби простіше жилося тестувальникам. Мапа взаємозв’язків допоможе приймати рішення про (не)доцільність розробки фічі в умовах серйозних ресурсних обмежень. Наприклад, якщо від фічі відходить аж надто багато “ниточок”, то можливо має сенс відкласти зміни в ній до більш спокійних часів, якщо вона не становить первинний пріоритет.

Імплементується такий зв’язок зазвичай через функціонал пов’язаних тікетів (“relates to” в Jira абощо)

Фіча до тест кейсів (і тест кейси до фіч).

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

Такий зв’язок зазвичай імплементується через налаштування інтеграції вашого issue tracking software в вашу тулу з менеджменту документації. Це вважається Backward Requirement Traceability Matrix, хоча, як на мене, цей порядок важливіший.

Якщо зв’язок тест кейсів з тікетами працює, так би мовити, на тестувальника, то зворотній зв’язок допомагає решті команди. Коли тікет посилається на тест кейси, якими його покрито, то розробники мають змогу, не покидаючи умовної Jira, подивитись, як саме їх роботу будуть перевіряти тестувальники. Розробнику дуже корисно мати перед очима написані тестувальником тести. Крім того, деякі інтеграції тут же показують статус відповідних тест кейсів з останнього тест рану. Доволі зручно знати, в якому стані тікет і коли востаннє перевірявся.

Такий зв’язок зазвичай імплементується відповідними плагінами у вашому issue tracking software. Це вважається Forward Requirement Traceability Matrix, хоча, як на мене, цей порядок найважливіший. Комбінація обох зв’язок називається Bi-Directional Traceability.

Тест кейс до типу тестування.

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

Такий зв’язок зазвичай імплементується через використання відповідного поля тест кейсу в тулі для менеджменту тестової документації.

Зафейлений тест кейс до дефекту (і дефект до зафейленого тест кейсу).

Це дискусійний зв’язок, тому що деяка класика притримується думки, що заводити всі дефекти в системі не є обов'язковим. Я ж притримуюсь, що якщо створення дефектів не вносить мутації у якісь ваші метрики, то немає жодної причини не зарепортити знайдений дефект. А отже і пролінкувати його до відповідного запису про зафейлений тест кейс в тест рані. Тоді ви зможете дотримуватись принципу про те, що жоден фейл не може бути порожнім і зобов’язаний мати посилання на дефект. Якщо ви залишатимете фейли порожніми, тобто не будете фіксувати роботу над виправленням того, що ви описуєте документацію, то який тоді сенс в документації, яка не відповідає дійсності і невідомо, чи взагалі буде відповідати колись?

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

Трошечки про тест рани.

Якщо звернутися до визначення тест рану в ISTQB, то читаємо: “Test run - The execution of a test suite on a specific version of the test object.” Тобто маємо тест сьют — набір тест кейсів, логічно поєднаних певною ідеєю — який ми тестуємо об продукт в якомусь його стані.

Мовою тулзів і практики тест рани — це певний скоуп тест кейсів, який раниться за потреби і агрегує видиму статистику і звіт. Кожен тест кейс в тест рані має свій статус. Тест рани — дуже потужний інструмент в роботі. Почнемо з того, що під час процесу збирання тест рану тестувальних ретельно продумує спектр активностей. Якщо документація побудована коректно, із відповідними типами і traceability за тікетами, то зібрати тест ран через фільтр — справа пари кліків. Повна регресія? То просто відфільтрувати за типом regression або конкретний сьют, якщо ви виносите регресію окремо. Потестувати конкретну фічу? Фільтр за референсом на відповідні тікети. Часткова регресія? Комбінація попередніх двох рішень.

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