Техніки оцінки тестів/оцінка трудовитрат на тестування (Test Estimation)
PreviousПроцес тестування (test process) (draft)NextЕкономіка тестування/вартість якості (Cost of quality)
Last updated
Last updated
Оцінка витрат на тестування: Розрахована апроксимація результатів, пов'язаних з різними аспектами тестування (наприклад, витрачені зусилля, дата завершення, пов'язані витрати, кількість тестових сценаріїв тощо), результати якої можуть використовуватися навіть коли неповні вхідні дані , невизначені чи неточні. (ISTQB)
Test Estimation – це управлінська діяльність, яка приблизно показує, скільки часу та грошей потрібно для виконання завдання. Оцінка зусиль для тесту (Estimating effort) є одним із основних та важливих завдань в управлінні тестуванням (Test Management).
Ми поговоримо про планування в прогнозуючих методологіях, тому що вони мають час попланувати до того, як проект розпочався. У гнучких методологіях все відбувається «тут і зараз»: не тільки регулярний planning, а й initial planning, як правило, їм займається менеджмент. Це окрема тема.
Якщо ми говоримо про прогнозуючі методології, то тут можуть бути цілі етапи, які ви можете спостерігати на слайді. Ось, наприклад, перший етап - Incention - він може займати до півроку. І це період, коли не програмують і до ладу не займаються вимогами. Хто може погодитися на те, коли нам платять, а ми до ладу нічого не робимо? Це може бути військова, медична промисловість. Це можуть бути світові проекти, від яких залежить життя людей, і період розробки приблизно становить від двох до 5-7 років. Зазвичай на планування йде близько двох тижнів, але часто це просто «завтра».
Що таке тестування? Для тест-ліда це не тільки час, але і що, як і де тестувати.
Планування тестування:
визначення вимог до тестів;
Оцінка ризиків;
Розробка стратегії тестування;
Визначення ресурсів;
Розробка Тест Плану;
Створення графіка робіт.
Кожне це питання гідне розгляду. Але ми поговоримо про маленький пункт "Створення графіка робіт". Звичайно, про тестування можна просто сказати, але краще показати і якось формалізувати свою аргументацію. Нині поговоримо саме про це. Звичайно, планування неможливе без оцінки результатів – це і є наша основна проблема.
"Ми не вміємо оцінювати!" - команда може заявити таке, що джуніор, що досвідчений фахівець. Причину вбачають у відсутності певних методів. Це дуже велика помилка. Методи є:
Вимагають детального математичного опрацювання:
;
;
;
;
;
.
Це математичні методи, але я не бачила жодної компанії, яка використала б їх. Їхні основні мінуси:
Вони займають багато часу
Вони трудомісткі
Вони не дають результату.
Чому?
Тому що планування має бути гнучким. Тому що складний план може порушитися тільки через те, що хтось не прийшов або захворів. Перераховувати? Навряд чи! Тому ми поговоримо про методи, якими ви користуєтеся, але не завжди усвідомлюєте!
Найбільш прості у використанні:
ПВН (пальцем у небо), або метод спроб і помилок;
Аналогії та рекомендації експертів;
Відсоткове ставлення до розробки;
Наше улюблене – метод проб та помилок. Усі ми ним часто користуємось. Потрібно розуміти, чим він відрізняється від методу експертних оцінок. Якщо ви вже працювали з проектом, він вам знайомий і щось тестували, ви вже робите як експерт. Якщо ви не робили це для тестування, не працювали з проектом і ніколи не стикалися з цією областю чи замовником, то ви повністю оцінюєте пальцем у небо. У цьому велика різниця.
Мій улюблений метод – структура декомпозиції робіт. Це найменш трудомісткий, але формалізований спосіб оцінки. Що мається на увазі? Вам потрібно просто дробити вашу роботу до тієї мінімальної, яку дуже легко оцінити і навіть вчитися не потрібно.
Наприклад, протестувати авторизацію. Літера «о» не проходить - можна відразу сказати 5 хв собі. Це мінімальна одиниця. Таке може визначити навіть людина, яка працює лише кілька місяців. Плюс у такому методі – вам складніше щось забути.
Береш свої вимоги, і велике завдання, ділиш їх на 3 частини, наприклад: тестування полів, тестування кнопочок, тестування локалізації, тестування перфомансу та тестування за видами, методами, областями. Дробіть далі: за введенням чисел, літер, символів тощо.
Зверніть увагу на діаграму, тут наведено статистику для сайтів від півроку - року. Програмування займає від 20% до 40% розробки, це не те що 20-40% від проекту, це в середньому 15% від проекту. Тестування ніколи не займає 15% продукту. Якщо у вас не закладають стільки часу для тестування, то закладайте хоч скільки-небудь. Бажано з'ясувати статистично, який відсоток від проекту займає тестування і це застосовно, якщо у вас стабільні версії релізів, постійний обсяг продуктів один і той же.
Рішення проблеми:
Навчаємо новачків:
Хронометраж;
Аналіз.
Створюємо універсальний Estimation Check List для портфеля проектів;
НЕ лаємо за помилки в оцінках.
Для цього не потрібно ходити на тренінги, якось оцінюєте, запишіть свої оцінки і подивіться, скільки це зайняло часу реально. Допомагають різні трейлери/програми, які допомагають записувати час. Або приблизно днями запам'ятовуйте. Коли ви зрозумієте, зможете навчити свою команду. Дуже важливо, коли ви намагаєтесь умовити команду оцінювати, дуже важливо не лаяти її за ці оцінки. Найчастіше люди не хочуть оцінювати, бо бояться, що ви можете до них причепитися. Поки не зафіксовано все, вони вам нічого не винні.
Поясніть своїм співробітникам, що будь-яка неправильна оцінка краща за її відсутність. Інакше ви як тест-лід не знаєте нічого, не можете співвідносити ресурси тощо. Хваліть, якщо вони навіть помилилися. Скажіть: Ти помилився в 2 рази. а я помилився о 3!». Але помилки не пропускайте, сядьте і порівняйте, скільки заплановано було, скільки часу знадобилося в реальності, де був big fail, і на що знадобилося більше часу. Найважливіше - цей аналіз, коли людина сама усвідомлює, що вона не врахувала. Тут потрібна декомпозиція робіт, щоб нічого не забути.
Тут нам може допомогти – «незабудка для тестувальника».
Ознайомлення/дослідження;
Ревізія специфікації;
Написання тестової документації (чек-лист, тест кейси);
Підготовка данних;
Виконання тестів + Рекомендації від програмістів;
Буфер/Ризики.
Перше, що ми зробили, повісили це кожному на робоче місце. Вона підходить для оцінки баги та оцінки завдань. Вона є верхньорівневою і підходить для глобальних завдань.
І ось це вже для тест-лідів та експертів, які оцінюють дуже великі завдання, особливо коли до завтра потрібно оцінити проект із великих 20 завдань.
Ви не підете до всіх тестувальників, ви підете до першого досвідченого та запитаєте: «Давайте оцінимо – скільки це займе». Такий Estimation чек-лист (чек-лист за оцінкою), щоб нічого не забути. Для кожного проекту він свій. Накидайте список всіх видів і типів тестування, якими ви користуєтеся, тому врахуйте, на що ви витрачаєте час - час на аналіз вимог, спілкування з клієнтами, програмістами, документування, створення тест-кейсів, тест-планів. А потім проставляйте в чек аркуші, що вам потрібне і не потрібно.
Наступна проблема – ми не хочемо оцінювати. Що робити із цими людьми, а вам дуже потрібно?
Зробіть усі оцінки самі та використовуйте їх для планування. Підвищуйте свої скіли + це цікаво знати, наскільки добре ви можете прогнозувати. Дивіться на завдання та оцінюйте, чим краще ви оцінюєте, тим важливіше ви для вашого тест-ліда. Здивуйте свою команду та покажіть, що ви можете передбачити те, що команда не знає!
Давайте приймемо собі, що планування - це оптимальний розподіл ресурсів, крім оцінки. Без оцінки – планування не має сенсу.
Планування - оптимальний розподіл ресурсів задля досягнення поставленої мети, сукупність процесів, що з постановкою завдань та дій у майбутньому. (С) Вікіпедія.
Важливо, хто виконує оцінки. На вас і вашого тест-ліда, менеджера та продакт менеджера дуже сильно впливає невизначеність, ось ці всі фактори впливають на час завершення проекту.
Ви скажете, як я, як тест-лід, відповідаю за фінанси? Все дуже просто. Якщо ви включите 4 тестувальники до проекту, то зарплату треба платити чотирьом, якщо трьом, то відповідно менше. Це банальний рівень, але якщо ваша компанія укладає договори про штрафи за прострочений проект, то там фінансові показники дуже великі. Тому кожен із цих показників впливає на час закінчення проекту.
Тому кожен із цих показників впливає на час закінчення проекту. І за таких умов хотілося б мати щось, що допомагало б відповідати на таке складне запитання.
Тут нам допоможе мережевий графік робіт та Діаграма Ганта.
Ось на слайді зараз графік робіт, що складається з періоду та завдань. Це діаграма для візуалізації ваших робіт, щоби не потрібно було вдивлятися в табличку. Зручніше подивитися на гарну діаграму, з якою простіше працювати. Все це разом допоможе створити метод критичного шляху.
Є теорія графів – це метод проходження шляху з найважчими вагами. У разі «ваги» - це оцінки. Шлях складається із робіт.
Якщо аксимувати це як управління проектами, це буде набір завдань від початку проекту до кінця проекту, які немає запасу за часом. Червоненьке – це критичний шлях. Якщо ви порушите термін виконання цих робіт хоч на годину, то реліз затримається на годину, якщо на 2 дні, то значить на 2 дні затримається реліз. Навіщо це потрібно? Вам важливо розуміти які завдання лежать цьому шляху, тому що приходить до вас на середині шляху тестувальник просить вихідний, але виявляється він виконує роботу на критичному шляху і від того, що його не було, реліз зрушив на 1 день. Метод Критичного шляху дає можливість передбачити наступ таких критичних робіт, усвідомлювати, що відбувається у проекті.
Давайте опишемо основні кроки, які ми робимо для складання плану.
Вирішити, що тестуватимемо;
Зробити оцінки;
Заповнити мережевий графік робіт, збудувати Діаграму Ганта;
Проставити логічні зв'язки між роботами;
Призначити ресурси;
Визначити Критичний шлях;
Проставити ресурсні зв'язки;
Оптимізувати ресурси (кількість виконавців).
Це дуже важливо зрозуміти. Найчастіше саме такий графік дозволяє зрозуміти взаємозв'язок ресурсів та неможливість виконання 400 годинного плану сотнею тестувальників за 4 години. Час витрачається підготовку даних, вивчення проекту, аналіз вимог, спілкування з програмістами.
Чи всі ми врахували? Якщо ні, то що лишилося і де це враховувати? Не забуваємо:
Відпустки, свята;
Баги
Час на заклад;
Час на регресію;
Статистичне наближення;
Буфер
На завдання чи проект?
%?
Ризики;
Виконавці;
Поділ;
Досвід;
Якщо версія не перша;
Менеджер це враховує у своєму буфері. Туди може увійти і те, що немає тестового оточення, програміст використав іншу технологію, час на заклад багів.
Часто трапляється проблема, коли проект для тестування вже віддається без буфера, тому розраховуйте буфер для програмістів та тестувальників окремо, тоді буде зрозуміло, хто його використав.
Ті, хто вже планує, зверніть увагу, що не можна застосовувати діаграму Ганта для групи проектів, якщо у вас спільні ресурси.
Якщо у вас загальний архітектор, і він потрібен на всі проекти, то це може не спрацювати.
Його переваги, коли у вас ресурси не перетинаються одразу у всіх проектах. Їх багато, так що ви можете керувати своїми ресурсами, розуміти, де вони знаходяться. Але вам важливо, чи це має сенс для вашої компанії.
Переваги:
Дозволяє розрахувати вартість та терміни проекту, ґрунтуючись на чисельних оцінках;
Дає уявлення про зайнятість ресурсів;
Дозволяє ефективніше розподіляти ресурси між проектами;
Інструмент оптимізації термінів проекту;
Є наочними документами для керівництва та замовника;
Якщо замовник зацікавлений у використанні наочних графіків, то ви можете говорити про те, що так вам легше дотримуватись зобов'язань перед ним, у вас буде чіткий аргумент.
Якщо замовник зацікавлений:
Дотримуємося зобов'язань;
Чи не приносимо збитки;
Розширюємо повноваження;
Чи не економимо на якості;
Це буде повноцінний час для якісного тестингу і ви віддасте такий продукт, за який не буде соромно.
Якщо замовник не зацікавлений:
Зберігаємо нерви Ліда;
Розвиваємо свою команду;
Впроваджуємо фішечки;
Розробляємо свої ініціативи;
Отримуємо задоволення від якості;
Ви можете підвищувати якість, витрачати час на вдосконалення вашої команди, запросити когось із тест-клубу, внутрішній проект навчання, нарешті, зайнятися документацією.
Потрібно чітко це контролювати. Скільки часу займає модифікація цього плану? Це гнучкий план, тому зміни мають проводитися раз на тиждень. Якщо це автоматизовано, то ваш час йтиме лише на оптимізацію. У компаніях, де цей процес не автоматизовано, з'ясовують одне запитання: «Скільки часу лишилося завдання?». Їм не цікаво, що завадило, важливо скільки часу залишилося і як змінити план. Отже, якщо у вас 20 тестувальників, то доведеться міняти 20 рядків.
Та й висновки:
Планування - сукупність процесів з:
створення стратегії тестування;
Оцінки трудовитрат;
прогнозування строків;
Призначення та оптимізації ресурсів;
контролю виконання завдань;
Оцінка трудовитрат і оцінка термінів - не те саме;
Більшість етапів можна автоматизувати.
Планування це чудово, тому що все можна автоматизувати, пам'ятайте, що планування термінів та оцінка трудовитрат не одне й те саме.
Джерела:
Дод. матеріал:
Стів Макконнелл - "Скільки коштує програмний проект"
;
-,Percentage%20Distribution,-In%20this%20technique);
.