Всім привіт! З вами Попелюха, і сьогодні ми поговоримо про матрицю відстежуваності Traceability Matrix та аналіз впливів, Impact Analysis. Матриця відстеження це документ, який написаний, як правило, в формі таблиці, і він використовується для визначення повноти зв'язків і взагалі для дуже багатьох різних характеристик. Він використовується шляхом співвідношення будь-яких двох документів. Це можуть бути тест-кейси, вимоги, дефекти, тест-рани.
Матрицю відстеження можна використовувати, наприклад, для перевірки, чи виконуються вимоги поточного проєкту, для перевірки, чи одні вимоги не повпливали на другі, чи немає залежності між вимогами, між тестами і так далі. І загалом трасибіліці матриця поділяється на дуже багато підвидів, наприклад, матриця відстеження вимог, Requirements Traceability Matrix, або матриця покриття вимог, Test Coverage Matrix. І навіть Impact Analysis є під видом Traceability матриці. Але про це трошки згодом.
Загально, як використовувати Traceability матрицю? Для цього потрібно взяти ідентифікатор для кожного елемента одного документа. Наприклад, це будуть вимоги, тоді ідентифікатори кожної вимоги будуть, наприклад, Requirement 1, Requirement 2 і так далі. І розміщення цих даних в лівій колонці. А ідентифікатори іншого документа, наприклад, тест-кейсів CC1, CC2, розміщуються в верхньому рядку.
І коли елемент у лівому стовпці пов'язаний з елементом у верхньому рядку, то клітинки, що перетинаються, вони позначаються певною позначкою плюсиком, хрестиком, кольором і так далі. Кількість зв'язків додається для кожного рядка та для кожного стовпця. І саме це значення… показує нам незалежність або відображення двох елементів. Давайте покажу вам приклад, щоб все було зрозуміло.
Наприклад, на цій матриці це в нас матриця покриття вимог. Тому що вгорі в нас написані вимоги від requirement1 до requirement13, а збоку, зліва, в нас тест-кейси від test-case1 до test-case10. І плюсиками ми позначали ці випадки, коли тест-кейс покриває вимогу. Наприклад, з цієї діаграми ми бачимо, що перший тесткейс покриває першу вимогу, також восьмий тесткейс покриває першу вимогу.
Тобто декілька тесткейсів можуть покрити одну вимогу. Може бути таке, що один тесткейс покриває декілька вимог, наприклад, як в четвертому кейсі, коли він покриває вимогу 2 і вимогу 3. А бувають такі варіанти, коли тесткейс зовсім не покриває певних вимог, наприклад, тесткейс 6. І тоді ми можемо вважати, що цей тест-кейс, напевно, useless, тобто, що він не покриває ніяких вимог, тоді що він перевіряє, що він тестує. А також бувають випадки, коли в нас вимога не покрита жодним тест-кейсом, як у випадку з 11-ю вимогою, коли в нас немає жодного плюсика. Це дуже важливо, тому що кожна вимога повинна бути протестована і перевірена, тому ми обов'язково одразу все кидаємо і сідаємо писати 11-й тест-кейс, який би покривав. Одинадцяту вимогу, тому що кожна вимога має бути покрита.
В даному прикладі в нас вимоги співвідносяться до вимог. В моєму прикладі я перевіряла, чи вимоги не протирічать одна одній. Також можна спитати, чи вимоги незалежні одна від одній.
Можна намалювати тут абсолютно різні випадки, в моєму випадку це протиріча. Наприклад, вимога 3 протирічить вимозі 4. Десь там серед вимог, найгрубіший приклад, звичайно, таких в реальній ситуації немає. IT. Але все-таки, для вашого розуміння.
Десь на початку вимог клієнт сказав, що він хоче білий фон веб-сайту. І бізнес-аналітик це записав, написав, що фон повинен бути білим, а десь всередині опису вимог клієнт сказав, що він хоче, щоб на фоні була якась картинка машини Феррарі. І відповідно, ця вимога одна протирічить одній. Тобто, десь він сказав, що хоче білий фон, десь він сказав, що хоче машину Феррарі на фон. І ці дві вимоги ми не можемо реалізувати і те, і те.
Це буде як в прикладі, там, де потрібно намалювати сім ліній, з них чотири червоних, чотири зелених, і дві прозорих, і які ніде не перетинаються, але перпендикулярні одна одній, і щоб одна була в формі кота. Якщо ви не знаєте цього приколу, то посилання буде в описі під відео. І це саме той кейс.
Тому для того, щоб перевірити, що вимоги не протирічать одна одній, нам потрібна така діаграма. Загалом... Я хочу ще з власного досвіду сказати, що такі діаграми ніхто не заставляє робити.
Тобто ми не прокинемося, не відкриємо нашу таску в джирі, і там не буде писати на малю діаграму для співвідношення вимог тест-кейсами. Але це робиться для власної зручності. Тому такі вимоги можуть складатися з будь-яких документів, які нас цікавлять.
Це можуть бути дефекти на тест-кейси, щоб побачити, який дефект там знайдений на якому тест-кейсі. Це можуть бути вимоги до вимог і вимоги до тест-кейсів, ви це вже бачили. Це навіть можуть бути фіча до фічі.
Наприклад, чи функціонал однієї фічі впливає на функціонал другої. Про це ми сьогодні також поговоримо. І що я хотіла сказати, що ці трисабіліці-матриці, вони малюються швидше для себе, ніж для якогось загалу.
Тому вставляти в них можна будь-яку інформацію, яка зробить вашу роботу простішою та зручнішою. Рухаємось далі. Можливості трисабіліці-матриці. Головні можливості це показати покриття вимог тест-кейсами, показати статус створення, а також статус виконання певних тестів. Якщо користувачі повинні виконати юзерах сеттинг-тестинг, то ми також можемо його зафіксувати в тій самій матриці.
А також відповідні дефекти і поточний статус тесту також можуть бути згадані в цій самій матриці відстежуваності. І крім того, щоб малювати її в звичайному Excel або Google Table, команда тестувальників може обрати спеціальні інструменти керування тестуванням, тобто... Тест TOOLS для відстеження вимог. Є три типи матриці відстежуваності. Перша Forward Trisability, тобто попереднє відстеження.
Ця матриця використовується для перевірки, чи просувається проєкт у бажаному напрямку, та для правильного продукту. Вона гарантує, що кожна вимога застосована до продукту, та що кожна вимога ретельно перевірена. Також вона показує зв'язки вимог із тест-кейсами. Наступний тип Backward or Reverse Trisability, тобто зворотні відстеження. використовується для того, щоб переконатися, що поточний продукт залишається на правильному шляху.
Мета такого типу відстеження полягає в тому, щоб переконатися, що ми не розширюємо обсяг проекту шляхом додавання коду, елементів дизайну, тестування чи іншої роботи, яка не вказана в вимогах. Тобто, що ми додаємо тільки все те, що вказано у вимогах. Матриця зіставляє тесткейси із вимогами, як і в попередньому випадку.
І байдирекшнл трейсабіліті, тобто двонаправлена відстежуваність, Ця матриця гарантує, що всі вимоги покриті тест-кейсами. Матриця аналізує зміни в вимогах, на які повпливали певні виправлення дефектів. Адже коли ми виправляємо якийсь баг, то ми, відповідно, щось змінюємо в програмі, і це вже може протирічити вимогам, не дай Бог.
Тому ми перевіряємо і ті зміни, які відбулися в вимогах під час виправлення багів. А ми переходимо до аналізу впливу, імпакт-аналізу. Імпакт-аналіз це аналіз впливу змін у продукті чи програмі.
Він... тісно йде разом з регресією. Якщо пам'ятаєте, регресія це такий процес, в якому працюють всі тестувальники, коли перед релізом нам потрібно перевірити, що всі наші зміни, які ми робили протягом, наприклад, цього релізу, протягом цих декількох спринтів, що ці зміни не повпливали і не пошкодили якісь попередні функції, які були написані до того і добре працювали. Відповідно, аналіз впливу це такий процес, коли ми визначаємо, що потрібно протестувати, щоби переконатися, що наші нові зміни не зламали попередній працюючий функціонал. Аналіз впливу надає інформацію про області системи, на які може вплинути зміна в певному розділі або функціях програми.
Цей вплив аналізується на рівні вимог, дизайну і архітектури, впливу на тестування та може бути навіть вплив на графік. З додаванням нових функцій в програму чи продукт обов'язково необхідно перевірити вплив цих нових функцій або змін на продуктивні системи. Із цієї причини виконується аналіз впливу. А ще для того, щоб під час регресії не тестувати тупо все, всі тест-кейси, які в нас є, навіть якщо їх 11 тисяч, для цього виконується аналіз впливу, для того, щоб зрозуміти, що нам в першу чергу потрібно протестувати.
А що, можливо, і зовсім не треба трогати, тому що воно було ніяк не пошкоджено і на нього нічого не могло б повпливати. Навіщо нам робити аналіз впливу? Аналіз робиться для розуміння можливого результату впровадження змін. Надбірна функціональність продукту може знизити загальну продуктивність цього самого продукту.
Також для того, щоб визначити всі файли, документи та моделі, які, можливо, доведеться змінювати, якщо команда вирішить внести зміни в продукт. Також, щоб оцінити зусилля, необхідні для впровадження змін, та визначити завдання, необхідне для впровадження змін. А також в аналізі впливу буде перераховано залежність від певного елемента. То як, таке, виглядає цей аналіз впливу, спитаєте ви, і ось він. Аналіз впливу може бути позначений кольором для того, щоб показати критичність змін або вплив змін на систему.
Давайте глянемо на цю таблицю. Значить, і вгорі, і зліва в нас написані певні фічі. Що це може бути? Звичайна логінка, реєстрація, пошук товару, додавання товару в кошик, сортування товару, фільтрація товару, додавання товару в обране, порівняння товару. Тобто, буквально фічі, які можуть бути реалізовані в, наприклад, програмі або веб-сайті.
І ми трьома кольорами, ну взагалі це залежить від проєктів, але в даному випадку дуже класний кейс, коли ми позначаємо залежності кольорами. Де червоний означає сильний вплив однієї фічі на іншу, жовтий означає помірний вплив. І зелене означає слабкий вплив. В даному випадку ми можемо бачити, що фіча 1 сильно впливає сама на себе, слабко впливає на фічу 2 і помірно впливає на фічу 3. Також ми можемо бачити, що четверта фіча дуже сильно впливає сама на себе, помірно впливає на фічу 5 та дуже сильно впливає на фічу 6. Це означає, що якщо ми щось виправили або додали в фічу 4, то нам обов'язково критично треба протестувати фічу 6. Саме так ми і визначаємо аналіз впливів. Поговоримо про приклади запитання, які необхідно відповісти для виконання аналізу впливу.
Які несприятливі побічні ефекти або ризики внесення запропонованих змін? Чи потрібно придбати будь-який інструмент для впровадження та тестування змін? Тут мається на увазі програма для тестування якась.
Далі, якщо зміна буде прийнята, то скільки зусиль, які вже було докладено, буде втрачено? Чи впливають негативно запропоновані зміни на вимоги до продуктивності? Для перевірки запропоновані зміни.
Чи потрібні додаткові дії якогось нового користувача? Чи збільшує зміна вартість продукту? Чи є запропонована зміна тим, що поточний персонал вже знає?
Чи це те, що потрібно ще дохчати? Чи створює запропонована зміна якийсь неприйнятний попит на будь-який комп'ютерний ресурс? Тобто, якщо ми дамо відповідь на ці запитання, то ми будемо знати, чи потрібна нам ця зміна, чи... просто її реалізовувати і чи нічого стороннього в нас не зіпсується, і також, чи варта ця зміна своїх коштів і часу, витраченого на неї. На сьогодні це все.
Я дуже дякую вам за перегляд та увагу. І також буду вдячна за ваші вподобайки, коментарі більше чотирьох слів та за те, що поділитися цим відео із своїми друзями, які хочуть безкоштовно вивчити професію коліці ашуренс-інженера. А на сьогодні це все і до зустрічі в наступному відео.