Сидячи без світла довгими зимовими вечорами, почав читати більше тих книжок, які відкладав “на потім”. Одна з них – по бізнес аналізу (давно хотів глибше зрозуміти, як аналітики аналізують та описують вимоги, щоб ефективніше їх тестувати). Не обіцяю регулярні інсайди, але цікавими знахідками хочеться поділитись.
Тема дня – аналіз даних! Будь-який застосунок отримує, віддає, обробляє чи зберігає дані. Інтернет магазин – товари, готельний сервіс – номери та гостей, навіть конвертор валют – власне валюти і їх поточний курс.
🔰 Перше, що має зробити хороший аналітик – визначити, які дані є (мають бути) в системі та як вони пов’язані між собою. Якщо це комплексні дані, наприклад товар в магазині, має визначити його назву, кількість, ціну, характеристики
🔰 Далі можна намалювати модель даних у вигляді схеми, для кращого розуміння. Є різні способи: UML нотація, Diamond нотація (по суті все – квадратики та стрілочки 😁)
🔰 Потім визначити, які дані є натуральними, тобто використовуються користувачами, як от ціна товару, а які – штучні. Наприклад, id товару в системі. Так, він необхідний в розробці, але користувачі зазвичай ним не оперують, надаючи перевагу назві. Нащо це визначати – щоб розуміти, які дані треба показувати користувачу, а які – можна приховати, щоб не відволікати
Чек ліст питань по даним, які варто спитати (для нас – знайти відповідь в уже написаних вимогах):
Для об’єктів:
✅ Яке ім’я має цей об’єкт в програмі? Як це ім’я співвідноситься з іншими іменами, що використовуються користувачами в їх бізнес домені?
❕ Часто буває, що користувач магазину оперує товарами, а всередині системи вони називаються просто як item, unit чи entity – варто розуміти, що є що. А як в вашій програмі є локалізація, цей набір інформації стає ще більш суттєвим
✅ Які відношення цей об’єкт має з іншими об’єктами?
❕ Покупець може купити багато товарів, але 2 покупці вже не можуть купити 1 і той самий товар
✅ Чи є випадки, коли об’єкт не має типового зв’язку з іншим об’єктом?
❕ Користувач може переглянути список придбаних раніше товарів. Але цілком можливо, що він нічого ще не купляв, тому список ще порожній. І це не має викликати жодних помилок
✅ Чи маємо ми знати про щось особливе, створюючи чи видаляючи об’єкт?
❕ Створюючи нового користувача, ми маємо впевнитись, що його email – унікальний. Видаляючи – ми маємо видалити список придбаних ним товарів, корзину та інші пов’язані дані
✅ Чи є приклад типового об’єкту? Чи є приклад не типового об’єкту?
❕ Потрібні конкретні дані, які ви зможете скопіювати і реально створити в програмі, щоб проводити тестування. Якщо замовник знає про якісь унікальні конфігурації об’єктів, що має, наприклад, 1 на 1000 – хай теж надає!
Для кожного атрибуту:
✅ Звідки в цьому домені беруться значення?
❕ Ціна товару – більше за 0 + його валюта
✅ Які значення використовуються в цьому домені
❕ Наприклад, замовник продає іграшки в діапазоні цін від 100 до 500 грн
✅ Які значення можливі для атрибута?
❕ Мінімальне, максимальне, за замовчанням
✅ Чи може атрибут мати спеціальне значення, як от пробіл чи спец символ, і якщо так, то в яких випадках?
❕ Наприклад, в html є тип поля вводу number, і типово в нього можна вводити тільки цифри. Але є можливість ввести букву e, що потрібно для чисел з експонентою
✅ Чи є приклад типового атрибуту? Чи є приклад не типового атрибуту?
❕ Типова ціна – 100 грн. Не типова ціна – 0.01 грн, подарунок по акції
Я, так чи інакше, шукаю відповідь на всі ці питання у всіх вимогах, що аналізую та збираюсь тестувати. Але радий був натрапити на структурований чек ліст.
Напишіть в коментах, чи була ця інформація для вас корисною?