Тест-аналітики – хто це Лабораторія Якості
Я пропоную читачеві скласти мені компанію та подивитися, чим протягом дня займається тест-аналітик (в мої обов'язки входить робота не лише тестувальником, а й тест-аналітиком). Отже, ласкаво просимо у світ аналітики!
Як виглядає мій звичайний день у ролі тест-аналітика
Вранці мені на пошту надходить лист від замовника з даними для отримання дистрибутива продукту та формальними вимогами до нього. Погані новини – технічного завдання як такого ми не маємо. Хороші новини – представник замовника виявився відкритим для спілкування молодим чоловіком.
- дослідити продукт;
- скласти логічну карту товару;
- розбити програмний продукт на складові;
- розставити пріоритети тестування
Дослідження програмного продукту
Насамперед, мені необхідно зрозуміти мету створення цього продукту. Якими способами вона має досягатися? Які основні та допоміжні можливості надає продукт користувачам? Тільки після цього я виконую встановлення дистрибутива і намагаюся оцінити, чи зрозумів замовника розробник.
Логічна картка
Сформувавши попереднє уявлення про продукт, маю логічну карту (інтелект-карту).
Подібний підхід дозволяє досягти одночасно кількох цілей.
По-перше, цілісний погляд на весь проект даєможливість відстежити логічні зв'язки всередині продукту та виявити так звані «пляшкові шийки».
По-друге, при деталізації карти досягається поділ функцій до найменших, атомарних складових (власне, виконується декомпозиція продукту), представлений у графічному вигляді.
На карті відображаються функціональні модулі продукту, які потім поділяються на найдрібніші частини (аж до окремих форм, полів, чек-боксів тощо). По можливості картка повинна повністю поміщатися у полі зору. У центрі розташований центральний блок (система). Від центрального блоку за годинниковою стрілкою малюються гілки (починаючи з правого боку). Від гілок першого рівня йде розподіл більш глибокі рівні. Рекомендується використовувати від 5 до 7 гілок на рівні.
Всі вони відрізняються зручністю використання, набором параметрів та ціною (є і безкоштовні варіанти). Найпростішим інструментом служить лист ватмана та фломастер, але карту в електронному вигляді все-таки зручніше коригувати та доповнювати. Докладніше тема інтелект-карток розкрита тут. Зауважу, що під час процесу побудови картки вкрай бажано отримувати зворотний зв'язок від замовника.
Декомпозиція
Процес побудови карти нерозривно пов'язані з виконанням декомпозиції продукту. Як зазначалося вище, принаймні дослідження товару і побудови його карти виконується поділ функціоналу до найменших елементів. Найчастіше при декомпозиції я користуюся такими правилами:
2. Система розчленовується тільки по одному, постійному всім рівнів признаку.У тестуванні програмного забезпечення зазначеного поділу домогтися дуже складно, тому це правило можна дещо видозмінити:всі об'єкти одного рівня, є підсистемами однієї ітієї ж системи повинні розділятися за однією ознакою. Іншими словами, вони повинні відповідати на одне й те саме питання щодо свого батька. Наприклад, для інтернет-магазину це можуть бути каталоги товарів, товари, інформаційні блоки самого товару (характеристики, відгуки, фото тощо).
На кліку на картинку відкриється повна версія.
Глибина декомпозиції
Глибина декомпозиції (кількість рівнів) визначається зручністю сприйняття одержуваної ієрархічної структури конкретним фахівцем. Для фахівця, який добре знає систему, декомпозиція може бути неглибокою і менш деталізованою. Якщо ж результат декомпозиції призначений для фахівця, який раніше не працював із системою, то декомпозувати слід більш детально та глибоко.
На кліку на картинку відкриється повна версія. Як можна побачити на ілюстрації вище, для деяких модулів достатньо поділу до другого рівня (так звана «Пакетна установка»), а для інших – до четвертого (так звана «Розширена установка»). Трапляється, що для деяких модулів вистачає одного рівня. У прикладі ми узгодимо із замовником виділення кількох функціональних блоків, мають найбільшу важливість для продукту; всі вони поділені до елементарних елементів. «Другорядні» блоки ми розглядаємо на рівні великих модулів. Таким чином виявляється порушеним питання пріоритезації продукту.
Пріоритезація
Як альтернативний варіант ми можемо вибрати найбільш пріоритетні напрями і приділити їм найпильнішу увагу; при цьому решта функціоналу буде покрита лише смоук-тестами. Вислухавши мої аргументи, замовник погоджується на пріоритезацію.
У випадку виконувати пріоритезацію можна за такими критеріям:1. Вимоги клієнта.Вимоги клієнта дуже важливі і пов'язані з просуванням продукту та торговельною діяльністю.2. Ступінь ризику.Функціонал, відмова якого принесе найбільші втрати, необхідно тестувати насамперед і найбільш ретельно.3. Складність системи.Насамперед слід протестувати найскладніші властивості. Це допоможе уникнути перевитрат бюджету та часу.4. Тимчасові обмеження.Дуже важливо протестувати всі необхідні властивості до виходу релізу. Можна почекати з властивостями, що заплановані на наступний реліз. Корисні відомості про пріоритезацію тестування можна знайти у доповіді Наталії Руколь.
На кліку на картинку відкриється повна версія. Отже, мій робочий день практично закінчено. Залишилося всю отриману та оброблену інформацію передати тест-дизайнеру для розробки стратегії та написання тестів.
Висновок
Підбиваючи підсумки, можна сказати, що тест-аналітик – це своєрідна сполучна ланка між замовником та рештою команди тестування. Він першим знайомиться з новим матеріалом, систематизує та розкладає по поличках усю ту інформацію, яка обрушується на простого смертного тестувальника при отриманні ним у тестування продукту.
У компанії з повним циклом, де весь процес розробки від ідеї допередачі готового продукту в руки щасливого користувача не виходить за межі однієї команди, робота тест-аналітика починається ще до того, як розробниками будуть написані перші рядки коду. Вже на стадії формування вимоги до продукту він з'ясовує цілі тестування, спираючись на основне призначення ПЗ, що розробляється, закладається в нього логіку, цільову аудиторію і можливі особливі побажання замовника.