Вимоги. Low Tech, High Life.

ℹ️ Disclaimer: те що написано далі не є найсучаснішим, й найоптимальнішим способом працювати зі змінами в документах, але це дуже просто й це працює!

Якщо спростити: є маленькі проекти, а є великі.
На маленьких не часто виникає потреба мати всі вимоги до продукту в одному документі, зазвичай достатньо сумлінно вести беклог з користувацькими сценаріями.
А от на великих проектах кількість вимог в беклозі достатньо швидко, вже за декілька десятків ітерацій, може перебільшити той обсяг, який ще дозволяє тримати загальну картину продукту в голові. Тому дуже корисною виявляється наявність детальних вимог до продукту, або до кожної з його великих фіч, оформлених у вигляді документу. Як правило такий документ називається SRS – Software Requirements Specification. В мене на проекті він називається FSD – Functional Specification Document. Й ці документи доводиться оновлювати кожну ітерацію.
Тестувальникам доволі часто доводиться не тільки читати вимоги, а й писати їх. Як от мені довелось оновлювати документи з вимогами на великому проекті декілька ітерацій поспіль.

Питання: як оновити документ з вимогами так, щоб було зрозуміло які саме зміни були впроваджені в певній ітерації?

Ми це вирішили дуже просто, але й дуже дієво в той самий час.
Наприклад в ітерації №40 було декілька змін в функціональності Login.
1️⃣ Створюємо папочку з назвою “Release 40”
2️⃣ З папочки “Release 39” копіюємо документ “Login 39” в новостворену папочку “Release 40”
3️⃣ Перейменовуємо “Login 39 “в “Login 40”
4️⃣ Відкриваємо Login 40, виділяємо весь текст та скидаємо колір заливки тексту
5️⃣ Додаємо наші зміни
6️⃣❗️Й найголовніше – виділяємо наші зміни заливкою жовтим кольором

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

А чи доводиться вам займатись оновленням вимог на проекті?

Позначки:,
3 Грудня 2020
Автор: 
Mikhail Chub

Залишити коментар

Залишити вiдгук