... Або, іншими словами, як порахувати час на тестування так, щоб всі повірили? Адже насправді у нас зазвичай - дві мети. Перша - порахувати час так, щоб не помилитися і правильно розподілити ресурси - швидше за все, спочатку зробити це добре все одно не вийде. Друга мета більш реальна: порахувати час на тестування так, щоб довести комусь, що вам потрібні ще люди в команді, пояснити, чому ви не встигаєте і т. Д. Як не дивно, після того, як раз 50 зробите друге, то і перше буде виходити!
Давайте тепер подивимося, як рахувати час на тестування, на конкретних прикладах.
Випадок 1: «Ось ТЗ, скільки часу піде на написання тестових випадків?»
Припустимо, приходить нам приходить об'ємна папка з добре прописаним технічним завданням (ТЗ). Нас запитують, скільки часу піде, щоб написати тестові сценарії (ТС) до всього цього.
Перш ніж ми зможемо відповісти на це питання, нам добре б знати:
- Хто буде писати ТЗ?
- Який уровеньчеловека. який буде писати ТЗ: у нього менше або більше досвіду, ніж у вас? Якщо у нього менше досвіду, ясна річ, йому знадобиться більше часу. Якщо у нього стільки ж досвіду, скільки у вас, тоді ваші оцінки сходяться. Якщо людина крутіше вас, тоді взагалі незрозуміло, чому вас попросили розраховувати час.
- Який рівень знання технологій. Чи зможе людина провести низькорівневе тестування, добре в усьому розібратися, чи буде він розуміти, що відбувається з базою, наприклад?
- Який рівень знання предметної області. Це ще важливіше, ніж рівень знання технології, тому що, якщо нам, наприклад, потрібно тестувати якесь неймовірне фінансове додаток, а ми не розуміємо взагалі, що таке бонди і опціони, - багато часу піде на розуміння предметної області. Зрозуміти без цього, наскільки складно ТЗ, наскільки складний продукт і, в підсумку, наскільки об'ємними і якими взагалі повинні бути ТС, досить важко.
- Навіщо і для кого пишуться ТЗ?
- Для себе - якщо ми тестуємо нашу внутрішню розробку. У нас свій продукт, своя команда, і ми пишемо ТС саме для свого продукту.
- Для клієнта. Іноді клієнт замовляє тільки тестування, а іноді - тільки ТС. Іноді він просить протестувати один раз, а потім залишити йому артефакт, за яким він зможе протестувати сам. ТС для клієнта можуть бути і менш деталізованими, і деталізовані, але інакше, ніж якби ми писали ТЗ для себе. Так, самі ми добре розуміємо всі терміни тестування, але нам, може бути, потрібно буде детально прописувати в ТС всякі складні речі з предметної області. Клієнт може відмінно розуміти предметну область, але він може не знати, що таке валідація форми, і йому потрібно буде це пояснювати.
- Для приймального тестування - в цьому випадку ТЗ писати ще складніше, ніж для клієнта, тому що це тестування, результати якого клієнт може і не прийняти, якщо не захоче. Тому ТЗ для приймального тестування ми пишемо сильно більш формальними - не повинно бути ніяких формулювань типу «все працює нормально», тому що за таким ТЗ клієнт може не прийняти у вас нічого і ніколи.
- Для автоматизації. Тут ми повинні думати про тестування, кероване даннмі, про те, як це автоматизувати і т. Д.
- Для душі. У цей випадку ми просто хочемо розібратися і немає запиту від команди на тестування.
- Де пишуться, в якій системі управління тестуванням?
- Знайоме середовище.
- Незнайоме середовище. У незнайомому середовищі, звичайно, нам потрібно буде більше часу.
Від відповідей на всі ці питання залежить, скільки часу піде на написання одного позитивного тестового випадку - T1. Також варто враховувати час на написання одного негативного ТЗ (він буде позначатися як T-1). Мій досвід говорить, що негативні ТЗ зазвичай пишуться довше - також їх зазвичай потрібно більше. Звичайно, тут буває по-різному, але мені здається, що, чим краще ми знаємо предметну область, чим краще розбираємося в додатку, чим краще розуміємо, де і як воно може впасти, тим більше у нас буде негативних ТС. Якщо у вас, наприклад, на три позитивних МС доводиться один негативний, можливо, ви не зовсім розуміють додаток. Якщо на один позитивний ви можете придумати 500 негативних ТЗ, це - хороша робота. У мене співвідношення позитивних і негативних ТС - зазвичай від ½ до 1/5.
Т. ч. Нам потрібно порахувати час на написання позитивного ТЗ, прикинути співвідношення позитивних і негативних, і порахувати час цілком.
Варіанти оцінки:
- Груба експертна. Наприклад, ми знаємо, що зазвичай на одну сторінку ТЗ ми пишемо 5 ТС. Зазвичай один ТЗ ми пишемо 20 хв. В технічному завданні 300 сторінок. 5 x 20 x 300 = 30000 - ось скільки хвилин навскидку ми будемо писати ТЗ.
- Тестування займає X часу від часу проекту.
- Написання тестових випадків Y часу від часу на тестування
- Розбиваємо ТЗ на однорідні частини (наприклад, за функціоналом) і пробуємо писати ТЗ для кожної частини
- Дивимося, скільки часу пішло на написання ТЗ для такого-то кількості сторінок кожної частини, виходячи з цього обчислюємо, скільки всього часу має піти на написання ТЗ для кожної частини
- Складаємо пораховані для кожної частини час
Тепер спробуємо порахувати, скільки годин у нас приблизно піде на написання ТЗ (але, зверніть увагу, чи не на тестування взагалі):
Оцінки у нас не сходяться, але це нормально - принаймні, ми зуміли порахувати приблизно. А якщо у нас достатньо часу на оцінювання, можемо зробити оцінку декількома способами.
Вважаємо час при використанні Agile
Тепер поговоримо про гнучких методологіях розробки, коли немає технічного завдання. Тут не дуже зрозуміло, як оцінювати, але все ж можна виділити деякі підходи. Наприклад, можна:
- просто пройтися по беклогу;
- написати високорівневі ТЗ;
- виписати всі дії всередині спринту і спробувати оцінити, скільки вони будуть займати часу - цей підхід розберемо нижче.
Тепер невелике відступу для QA-менеджерів, менеджерів проектів. Всі дії по створенню і по запуску тестових випадків ми можемо розділити на наступні компоненти:
Випадок 2: «Ось шматок функціоналу, скільки часу піде на тестування?»
Скільки часу піде на тестування тій чи іншій частині функціоналу? Щоб це прикинути, є різні способи:
Можна дивитися, скільки часу зазвичай у нас йде на тестування схожого функціоналу. - Можна дивитися на той же функціонал. якщо ми вже раніше тестували такий. Це дуже зручно! Якщо ви, звичайно, записали в минулий раз, скільки це часу зайняло.
- Дедуктивна оцінка - якщо ми знаємо, скільки цей функціонал займає місця в загальному функціонал (якщо ми, наприклад, вже знаємо, скільки часу займає повна регресія), ми просто бачимо, що тестування цієї функціоналу займе, наприклад, п'яту частину від всього часу.
- Індуктивна оцінка - ми пам'ятаємо, скільки часу ми витрачаємо на кожен ТЗ. Ми дивимося на цей функціонал і розуміємо, що нам для його тестування потрібно 10 - 15 ТС.
Що в даному випадку важливо пам'ятати? Що новий функціонал може знову зажадати час на підготовку середовища. Важливо пам'ятати про існування коефіцієнта на знайомство з системою: більше часу на тести йде, якщо проганяєш їх в перший раз, ніж якщо ти їх проганяєш другий або третій раз. Але якщо другий раз наступає через місяць, то ти його все одно проганяєш, як ніби в перший раз - втім, це у кожного по-своєму.
Випадок 3: «Чому ви нічого не встигаєте ?!»
Наступний, дуже поширений питання, яке задають тестувальникам: «а що це ви взагалі робите, чому ви нічого не встигаєте, чому вам потрібно допомагати з автоматизацією, чому ви не хочете, щоб ми кожен день випускали нові версії - адже багів-то нових нету . »
Щоб показати, чим ми займаємося, можемо для кожного проекту виписати все-все завдання, які виконуються за один спринт, і розписати їх по днях: порахувати, скільки часу йде на кожну задачу в той чи інший день. Так можна побачити середню, максимальну і мінімальну завантаження.
Приклад такої таблиці:
Коли я її зробив, я побачив, що не завжди навантаження може бути оптимально розподілена - іноді завантаження велика, а іноді пів дня взагалі нічого робити. Це дозволяє зробити певні висновки і якось оптимізувати процес, розподілити навантаження - наприклад, якісь речі робити заздалегідь, навіть якщо це не зовсім узгоджується з логікою процесу. Наприклад, якщо на початку спринту у нас багато вільного часу, ми можемо вже почати писати розповідь користувача до наступного спринту. Хоч ми і не знаємо структуру наступного спринту, все ж ми, швидше за все, можемо передбачити, що ось ці ось дві-три історії в нього точно увійдуть - зазвичай вони самі критичні, зазвичай їх все одно доводиться переписувати, тому це хороша вправа.
Отримали завантаження в годинах по днях. І якщо виходить, що кожен день потрібно 24 години тестування, а у нас лише дві особи ... Значить, однозначно потрібен третій тестувальник!
Випадок 4.1: «Випускаємо збірку в п'ятницю, а то й раніше - так скільки вам потрібно часу на тестування»?
У такому випадку процес тестування будується так:
- Димової тест + тест на повну регресію x на кількість найважливіших платформ + тест на базову функціональність на всі платформи + тести на повну регресію по платформах (див. Матрицю).
- Повторне тестування: димової тест + валідація xвсе платформи.
Тести на повну регресію по платформах проводяться в цьому випадку наступним чином (Cr, FF і т. Д. Тут - різні платформи, в даному випадку - браузери):
З цієї матриці ми бачимо, що для кожної платформи тестуємо будь-яку частину функціоналу: в результаті виходить, що ми і всю функціональність перевірили, і випробували роботу на кожній платформі. Ми також можемо зрушувати цю матрицю - в результаті вийде, що за певну кількість прогонів ми кожну функцію на кожній платформі все одно перевіримо. Це ще проста схема - але ж може бути і 20 конфігурацій без можливості автоматизувати їх тестування - звичайно, в такому випадку ми все не встигнемо перевірити, і будемо тестувати по такій матриці.
В результаті отримуємо наступну формулу:
ΣT = (Tprec + Treg) x (Qmain + 1) + (Tprec + Tbase + Tsmoke) x Qconf + (Tsmoke + Tvalidation) x Qconf x Qreturns
Qmain - кількість головних конфігурацій, на яких тестуємо все.
Qreturns - кількість повернень.За цією формулою зрозуміло, скільки всього часу у нас піде. По ній же можна спробувати стежити за часом, дивитися, на яке тестування йде найбільше часу. Також буде зрозуміло, де і що краще автоматизувати - ми зрозуміємо, де автоматизація заощадить нам найбільше часу.
Випадок 4.2: «Занадто багато тестів! Давайте швидше".
Якщо від нас вимагають виконати тестування швидше, ми можемо урізати кількість тестів за такими принципами:
- Дивимося на пріоритети:
- тестових випадків - якщо ми розписуємо пріоритети ТС. Тоді ми будемо працювати лише з самими високопріоритетними ТЗ;
- призначених для користувача історій або багів. якщо наші ТЗ до них прив'язані.
- Дивимося на замітки до випуску (release notes), куди входить:
- критично важливий функціонал. без якого програма не буде працювати і нікому не потрібно;
- заявлений новий функціонал - так як його публічно оголошують, користувачі його обов'язково перевірять;
- виправлення критичних помилок (швидше за все, помилки будуть вже перевірені);
- заявлені виправлення помилок - ми заявили, що ми щось виправили, і ми це перевіряємо;
- відомі проблеми (known issues) - як не парадоксально, але ми обов'язково повинні перетестіровать ті помилки, які ми заявили як помилки, з якими ми випустили продукт. Навіщо це робити? По-перше, потрібно перевірити, що їх вплив рівно таке ж, яке ми описали. По-друге, ми перевіряємо, чи працює той обхід цієї помилки, який ми пропонуємо.
- Замість зменшення обсягу тестування можна збільшувати команду.
- Додати програмістів - найкраще зі свого ж проекту. Наприклад, вони можуть писати генератори даних та інше - все для автоматизації або полуавтоматізаціі. Вони роблять це добре, а відповідальність за тестування все одно не на них - тому вони не страждають від того, що їх код погано працює. З тієї ж причини, можна просити одних програмістів перевірити код інших програмістів.
- Покликати тестувальників з інших проектів, або з цього проекту, але займаються чимось іншим.
Взагалі реальний процес тестування можна представити у вигляді трикутника. Кути цього трикутника - це:
- Обсяг тестування.
- Кількість осіб в команді.
- Термін. за який необхідно виконати тестування.
Швидкість і якість тестування залежать від цих трьох аспектів - саме над ними потрібно думати, щоб успішно спланувати роботу. Так, наприклад, якщо нам пропонують протестувати продукт за нереально короткий термін, і ми точно не вкладемося, або відмовляємося від такої роботи (якщо не хочемо випустити неякісний продукт, звичайно), або працюємо з вищепереліченими аспектами. Тоді ми можемо:
- Скоротити обсяг тестування.
- Збільшити кількість осіб в команді.
- Попросити збільшити термін на тестування.
Останній спосіб - мабуть, самий надійний: адже людей в команду можуть дати невмілих, а скорочення обсягу тестування може призвести до випуску сирого продукту.
Також тут працює спосіб - запитати, чому такі терміни. Може бути, потрібна всього одна функція для одного клієнта - тоді зробимо йому приватний реліз, а пізніше протестуємо все інше.
І ще випадок наостанок: доробка вже вийшов проекту
Якщо проект вже вийшов, але надійшла вимога доопрацювати його, як тоді розрахувати час на тестування, на розробку і т. Д. Час в такому випадку розраховуємо як зазвичай, але при цьому множимо його на два, бо всі люди вже все забули, вже в інших проектах - потрібен час на знайомство з системою. Крім того, додавання може бути поза стандартного циклу, тому, крім тестування цього додавання, може знадобитися повна регресія - тоді додаємо час на повну регресію.
Схожі статті