Естимація тестових завдань. Техніки оцінювання і як їх використовувати
Привіт читачам DOU. Мене звати Наталія Князька, працюю в Astound Commerce майже три роки, загалом у мене понад чотири роки досвіду в тестуванні. Нині я Senior QA-інженер, також виконую роль QA Lead Responsible Person на проєкті.
У статті ми поговоримо про естимацію тестування. Це те, від чого залежить можливість проджект-менеджера ухвалювати правильні рішення щодо управління проєктом. Оскільки я неодноразово бачила, що людям важко зрозуміти, з чого починати оцінювання завдань, вирішила поділитися своїм досвідом і досвідом компанії, в якій працюю, щоб експертність QA-департаменту зростала.
Матеріал може бути корисний не тільки Junior QA-інженерам, а й усім, хто цікавиться естимацією тестових задач. Ми проаналізуємо основні техніки, з’ясуємо, з чого починати оцінювання, як закладати час на ризики, і розглянемо типовий темплейт оцінки, який я використовую у своїй роботі майже щодня.
Що таке естимація тестових задач і для чого її проводити
Якщо ми говоримо безпосередньо про QA effort estimation, то це оцінення часу, який потрібен QA-інженеру для завершення певної задачі, і часу, необхідного для всіх активностей, в яких спеціаліст братиме участь, виконуючи її. Маємо пам’ятати, що естимацію ми зазвичай робимо, коли ще немає повних вимог або вони не погоджені. Тому тут є багато питань, як правильно та ефективно цей час оцінювати.
Розберімось спочатку, навіщо нам взагалі оцінювати.
1. Бо до нас часто приходить проджект-менеджер або бізнес-аналітик чи хтось із команди розробників із питанням «Коли це завдання буде завершено?».
2. На проєкті з’являються нові люди, яких потрібно заонбордити, і ми ще не розуміємо, наскільки швидко спеціаліст працює. І ми теж запитуємо: скільки часу тобі необхідно, щоб протестувати задачу? Нам треба навчити людей правильно оцінювати свої зусилля і планувати час.
3. Найважливіше — оцінювання нам потрібне для того, щоб визначити дедлайни та надати клієнту інформацію про тривалість проєкту.
Техніки оцінювання і коли їх використовувати
Для того щоб проводити оцінювання, нам потрібні певні інструменти — техніки естимації. Глобально їх поділяють на Accurate (точні) та Rough (грубі).
Серед технік Accurate я виділила декілька, хоча їх існує більше. Це Three-point, PERT, Function points, Use case points, Delphi. Щоб застосувати їх, потрібно мати повне технічне завдання. Тому я краще зупинюся на ситуації, коли в нас є не всі вимоги або не всі погоджені, і на tricky moments, на які потрібно звернути увагу.
У випадках невизначеності застосовуються Rough техніки:
Естимація за аналогією. Кожну задачу нового проєкту зіставляємо із задачами аналогічного попереднього по пунктах. Порівнюємо схожість у відсотковому співвідношенні й можемо використовувати ту оцінку, яку дали аналогічному проєкту, з урахуванням відмінностей. Якщо у нас його немає, ця техніка не спрацює.
Наприклад, оскільки основний напрям Astound це e-commerce сайти, на проєктах часто трапляються схожі компоненти й через те, що вся historical data зберігається, ми можемо просто переглянути інформацію щодо аналогічної задачі, щоб якомога точніше та ефективніше оцінити нинішній проєкт.
Experience-Based техніка. Оцінюємо час на задачі, базуючись на нашому досвіді на попередніх проєктах.
Тут усе залежить від вашого досвіду, але не хвилюйтеся, якщо його не так багато. В компанії завжди знайдеться досвідчена людина, до якої можна звернутися з питаннями й за експертною оцінкою. Я постійно стикаюся з новими інтеграціями і, якщо наданої інформації з вимог мені бракує, знаходжу фахівця, який уже з цим працював. Він може допомогти з оцінюванням і розповісти ризики та tricky moments зі своєї практики.
В Agile виділяють дві техніки естимації:
Story points техніка оцінює не час на виконання задачі, а її complexity, наскільки вона складна. Ми беремо за взірець маленьку юзер-сторі, якій присвоюємо один сторі-поінт. Відповідно до цього за складністю естимуємо наступні задачі.
У проєктах, де використовується ця техніка, команда має своє velocity — це та кількість сторі-поінтів, які команда може виконати за один спринт. Це значення має базуватися на результаті кількох спринтів. Наприклад, ми заестимували чотири User Stories, і загальна кількість Story points для QA вийшла 24, але під час спринту ми змогли виконати тільки три User Stories. У такому разі на наступний спринт у Sprint Backlog мають плануватися User Stories у тій кількості, яку завершили в попередньому. За результатом кількох спринтів ми матимемо velocity: ту кількість Story points, яку команда може зробити під час спринту.
T-Shirt sizes використовують для оцінювання великих беклогів наперед. Ми отримуємо невелику юзер-сторі та визначаємо її «розмір» як size S. Що означає S? Це знов-таки складність. Ми присвоюємо S і відповідно до складності цієї юзер-сторі естимуємо всі наступні й теж присвоюємо їм «розміри» — наприклад XS або М. Після оцінювання маємо визначену складність задач, які надалі можемо планувати в спринт-беклог згідно з пріоритетами, виставленими Product Owner.
Є два підходи, як потім використовувати складність. Можна зробити співвідношення, скільком годинам дорівнюватиме S. Або вираховувати velocity на основі кількості stories різних розмірів, які було взято в спринт. Наприклад, 10 (S) + 12 (M) + 15 (L) = 37. Також можна вираховувати velocity у сторі-поінтах, присвоюючи кожному розміру свою кількість story points: S =
Work Breakdown Structure (WBS). Це підхід до естимації, суть якого полягає в декомпозиції. Складну задачу ділимо на підзадачі доти, доки не зможемо максимально ефективно і точно її оцінити. Саме на цьому підході я зупинюсь докладніше, адже він має такі переваги:
- можливість дати більш точну оцінку, адже ми бачимо весь скоуп робіт, і це допомагає при подальшому їх плануванні та виконанні;
- ми майже на 100% можемо бути впевнені, що не пропустили жодної функціональності.
Розглянемо приклад Work Breakdown Structure як ієрархію списку проєктних активностей на зображенні нижче. Ми бачимо top level, наприклад Global Storefront, Global Header, Global Footer, і розділення на підзадачі та проставлені години.
Далі звернемо увагу на вдалий і невдалий приклади WBS. На bad example ви бачите, що години проставлені на топлевелі, тобто ми оцінили Global Header (шапку сайту) як загальну компоненту, визначивши приблизний час для кожної підзадачі. На good example — оцінювання активностей у годинах навпроти кожної сабтаски.
Чому я вважаю верхній приклад невдалим? Скажімо, нас попросять прибрати зі скоупу підзадачу Logo. А точного естимейту часу на Logo немає. Тож тепер нам доведеться згадувати, скільки часу ми відвели на цю активність, і віднімати її від загального числа для Global Header. Як бачите, таке оцінювання не буде точним. Коли у нас є оцінювання щодо кожної підзадачі, нам легше додати або видалити якийсь елемент.
У мене був схожий випадок, коли деякий функціонал просто забрали зі скоупу. Всі задачі та підзадачі у вимогах пріоритезовані (must do, should do, can do, won’t do), але оцінка була дана для задачі в цілому, а не для всіх підзадач. Вже минуло кілька тижнів після того, як ми оцінювали проєкт, і коли прибрали деякий функціонал, звичайно, згадати конкретні цифри щодо підзадач було неможливо, потрібно було швидко переробити оцінку. І тут виникла проблема: я витратила багато часу, бо мені довелося переоцінювати скрізь, де відбулися зміни.
З чого почати, якщо надійшла задача на естимацію
Ставимо всі необхідні питання. Що більше в нас інформації, то точнішим буде оцінювання. Які питання ставити?
Наприклад, коли я беру задачу на тестування, в мене QA Lead щоразу запитує: скільки часу займе компонентне тестування Global Header (або іншого компонента)? Як оцінити це, якщо ми не володіємо інформацією?
По-перше, нам треба визначити весь скоуп браузерів та девайсів, на яких необхідно протестувати задачу. Якщо говоримо про застосунок, варто уточнити скоуп операційних систем і їхні версії.
Друге — треба дізнатися, чи всі ці девайси у нас є. Або якщо ми використовуємо емулятори, то які саме і що нам потрібно зробити, щоб емулювати заданий device. Маючи уже весь скоуп, можемо переходити до Test Execution.
Якось мене долучили до проєкту лише на два тижні в допомогу. Це була середина проєкту, і зрозуміло, що до мене вже щось виконували у цій задачі. Я запитала, чи є підготовлений тест-дизайн? Які вимоги для аналізу? Від цього вже залежала моя оцінка. Є функціональні, бізнес- та інтеграційні вимоги, є прототипи та дизайни. Що більше вимог, то більше часу має бути для аналізу, тому що все треба перевірити на консистентність.
Ще важливі питання: чи необхідні додаткові інсталяції, чи треба робити апгрейд девайсів? Тобто нам треба точно знати версію систем, на яких ми будемо тестувати, і чи є бекенд- або фронтенд-розробники, яких можна розпитати щодо задачі. У нас будуть виникати запитання, і це нормально.
Декомпозуємо всі активності, в яких тестувальник братиме участь. Водночас намагаємося не пропустити жодну, інакше оцінка буде неправильною.
Які активності закладати? Я розбила всі активності на компонентні, некомпонентні, ризики та припущення. Під час їх оцінювання ми маємо естимувати, орієнтуючись не на себе, а на усереднений стандарт — тестувальника рівня Middle. Варто пам’ятати, що ми не завжди будемо виконувати задачу, яку оцінюємо.
Види активностей
До компонентних активностей я зараховую Test Design, Test Execution та Bugs Verification.
Час, визначений на Test Design, треба планувати з урахуванням підходу до його написання. Це можуть бути чек-листи, високорівневі тест-кейси або тест-кейси зі степами. Час буде відрізнятися, тому підхід до написання тест-дизайну варто підібрати на цьому етапі.
У Test Execution ми закладаємо час не тільки на сам run тест-кейсів, але й на визначення багів і їх заведення у баг-трекінгову систему.
У Bugs Verification ми плануємо час на верифікацію виправлених помилок.
Некомпонентні активності. По-перше, час, який ми витрачаємо на оцінювання певної задачі, ми закладаємо і в естимацію.
Час на аналіз вимог залежить від того, скільки їх і які вони.
Звичайно, ми комунікуємо з командою. У нас можуть бути запитання до бекендів, ми можемо обговорювати tricky points, спілкуватися з бізнес-аналітиком тощо. На це важливо зважати.
Крім того, я виокремила два пункти — Smoke Testing та Regression Testing, але вони дуже специфічні. Наприклад, якщо ми на етапі, коли проєкт загалом уже оцінювали, найімовірніше ці активності вже були враховані. І нам не треба це робити знову. Але якщо клієнт хоче внести зміни щодо вже затверджених вимог і це нова компонента, тоді маємо закласти час на Smoke Testing і Regression Testing.
Як прописувати Assumptions, на базі яких прорахована естимація, і навіщо
Коли у нас немає усіх вимог, ми повинні базувати свою оцінку на певних припущеннях (assumptions).
Розглянемо припущення щодо десктопних браузерів та їхніх версій. Коли ми маємо оцінити певну задачу, у нас може не бути затвердженого скоупу браузерів, девайсів чи операційних систем (для застосунків). І якщо клієнт наразі не може надати цю інформацію, але оцінювання зусиль від нас очікують, ми прописуємо Assumptions. Беремо список браузерів. Можна подивитися best practices компанії aбо дати запит на аналітику, але треба зробити Assumption на основі чогось і зазначити це в оцінці. Наприклад, пишемо, що оцінювання задачі було зроблено з урахуванням такого Assumption, що тестування буде проводитися на Chrome desktop, tablet iPad Air 2 та iPhone 8. І прописуємо версії.
Інший приклад — формулювання припущення під час вибору підходу до тестування дизайнів. Я розглянула два підходи. Перший — це general look, коли ми тестуємо загальний вигляд: позиція елементів, їхній колір, чи нічого не зламано в UI відповідно до дизайнів. Другий — pixel perfect, коли ми інспектуємо кожен елемент і перевіряємо font-family, font-size, background colors, тобто попіксельно аналізуємо розміри всіх картинок, кнопок, шрифти тощо. Звичайно, час на ці підходи буде різний. Якщо від клієнта немає точного запиту на тестування дизайну як pixel perfect або дизайни цього не дозволяють, ми прописуємо Assumption, що тестуємо на основі general look.
Для чого потрібні Assumptions? По-перше, ми прикриваємо собі тил. Ми заповнюємо ті пробіли у вимогах, інформацію щодо яких нам не дав клієнт. Що більше роз’яснень ми дамо в оцінці, то легше буде працювати людині з цією задачею. Пам’ятаємо, що не завжди спеціаліст, який оцінює задачу, буде виконувати її. Тому максимально фіксуємо інформацію в Assumption, на основі чого ми робили оцінку. Якщо все це пропишемо й до нас звернеться тестувальник із питанням «Чому закладено такий час?», ми можемо просто показати Assumptions.
Як закладати час на ризики
Ризики — це фактори, які можуть у майбутньому негативно вплинути на проєкт, а саме на таймлайни, ресурси, на будь-що. Якщо ми можемо зараз передбачити, що є такий ризик, треба запланувати додатковий час, щоб мати запас і встигнути провести оцінювання.
Наприклад, content page — це сторінка, яка може містити блоки з картинками й текстом. Але у вимогах написано 1 template content page, і ми не знаємо, що буде там. Ми плануємо час на 1 template content page, але додаємо час у ризики на те, що контент може мати різну складність. Тобто враховуємо можливість тестування потенційно складного кастомного функціоналу.
Типовий Task Estimation Template (за технікою WBS)
Розгляньмо Task Estimation Template, який охоплює все, що я розказала. Таким темплейтом я користуюся майже щодня.
Перший блок — це компонентні активності. Тут маємо Work Breakdown Structure Description, який міститиме підзадачі, які є в основній задачі. Тобто ми робимо декомпозицію і прописуємо у кожному рядку окремий функціонал. Це дасть упевненість, що ми точно не упустили жодної функціональності й бачитимемо оверв’ю того, що потрібно протестувати.
Далі я розділила колонки за активностями. QA Test Design, QA Test Execution, QA Bug Verification і Assumptions.
Варто зазначити, що QA Test Execution я розбила на три колонки (desktop, tablet, mobile), але це можна підлаштувати під ваш проєкт і відповідно видалити зайве.
Щодо QA Bug Verification, то ми не можемо заздалегідь знати, скільки буде багів, тому тут оцінка буде відносною. Для простої задачі 20% від компонентного тестування більш-менш достатньо для покриття QA Bug Verification.
Другий блок — некомпонентні активності. Це час, який ми витратили безпосередньо на естимацію, Requirements Analysis (скільки часу необхідно для аналізу всіх вимог), і час на ризики.
Далі цей темплейт можна буде спокійно використовувати під час тестування, адже простіше буде орієнтуватися, які активності ще залишилися, а які вже виконані.
Додаткові поради
На що потрібно звернути увагу?
1. Стежте за тим, щоб не дублювалися підзадачі. Наприклад, є домашня сторінка сайту, на якому є каруселька. І цю карусельку ви виділили як окремий компонент. Її треба оцінити лише раз — чи в межах домашньої сторінки, чи як окремий елемент — але дивитися за тим, щоб ця активність не повторювалася.
2. Потрібно бути готовим пояснити кожну цифру в естимейтах, не оцінювати навмання і використовувати тільки перевірені техніки естимації.
3. Якщо у вас немає досвіду щодо задачі, яку необхідно оцінити, запитайте колег. Якщо досвіду ні в кого немає, не забувайте про Google. Ви не можете дати оцінку, не маючи жодної інформації для обґрунтування.
4. Використовуйте historical data — інформацію з попередніх проєктів. Які є lessons learned, які ризики справдилися, на що звернути більше уваги, на що треба більше часу.
5. Наполягайте на тому, щоб закладали достатньо часу. Якщо ми говоримо про маленьку задачу, пів години вистачить. Але якщо потрібно оцінити проєкт або хоча б якусь ітерацію, то варто виділити відповідну кількість годин.
Для прикладу, коли тімлід практикує жорсткий estimating і дає на завдання дві години, хоча очевидно, що потрібно щонайменше
6. І, звичайно, допомагає комунікація з розробниками та Solution Architect, щоб виявити всі моменти, які ми не зрозуміли з вимог.
Підсумок
У статті я намагалася розписати алгоритм робіт, які необхідно провести, щоб оцінити будь-яку задачу максимально точно та ефективно. Естимація — це непростий процес, від якого залежать терміни, бюджет і те, наскільки комфортно почуватимуться тестувальники під час виконання активностей, які ви оцінили. Важливо враховувати tricky moments і пам’ятати, що оцінюємо не для себе, а для тестувальника, тому завжди робимо це із дотриманням стандарту, наприклад, естимуємо для Middle QA.
Список додаткових ресурсів:
- Software Estimation Without Guessing by George Dinwiddie — гарно розкриває тему, як правильно вибрати метод оцінювання, враховуючи поточні потреби та наявну інформацію.
- Software Estimation: Demystifying the Black Art by Steve McConnell — автор розповідає про оцінювання як мистецтво, надаючи перевірений алгоритм дій, формул, які спеціалісти можуть застосовувати на реальних проєктах.
- Predicting the Unpredictable by Johanna Rothman — автор пояснює, як оцінювати, коли є невизначеності і як оновлювати естимейти, коли отримуємо більше інформації.
