"Оцінка тестування": як оцінювати те, що всі розуміють по-своєму?

Одне з найтривіальніших завдань для будь-якого спеціаліста - це оцінка часу на виконання власної роботи. Звичайно, в кожній професії є завдання із "підводними граблями", але якщо взяти приблизну оцінку в двох спеціалістів, вона рідко буде відрізнятися більше ніж на порядок.
У тестуванні все інакше. Спробуймо розібратися, чому, і як було б більш правильно і зрозуміло бізнесу (бо саме він платить нам гроші, і саме йому ми маємо бути корисні).



По-перше, "тестування" на 70% (а може й на всі 90%...) складається зовсім не з тестування, як дослідження системи.
По-друге, тестувальники самі не вміють пояснити менеджерам, що ж саме вони робили 2 дні, якщо естімейт був 2 години? Може вони змогли по-справжньому тестувати лише 40 хвилин перед релізом. Або чому кастомер знайшов баг, а тестери - ні? Може таку задачу треба тестити з особливим даними, а щоб їх отримати, не було часу, тому тестили на чому було.

Для тестерів головне - самим усвідомлювати, на що витрачається час, і за необхідності - давати про це знати менеджерам або/й іншим зацікавленим (stakeholders).
Головне завдання тестувальників - робити все неявне явним. В тому числі й робити явними свої дії та глибину тестування.

Ось деякі види діяльності, на які я особисто іноді витрачаю значну частину часу, але зазвичай це не враховується в естімейтах:

• вивчення вимог - сюди включаються навіть не вимоги самої задачі, а пов’язані фічі проекту. Мета тут - перевірити, чи узгоджується дана задача із вже зробленими частинами. В ідеалі це мають робити до імплементації, але так дуже рідко трапляється. В ліпшому разі таке тестування вимог відбувається паралельно із програмуванням, коли задачу вже "взяли в спринт". У гіршому - вже коли код "замерджили в девелоп", або й взагалі коли через деякий час приїхали нові вимоги, що конфліктують із цими, з’ясовується що треба було робити інакше. І якби хтось (можливо й тестер) тримав би в голові об’єм задач трохи більший за 1 спринт, то зайвих змін вдалося б запобігти. Тестер має знати пр проект більше за всіх інших.
• підготовка тестових даних - іноді це просте "мавп’яче друкування", але іноді в нагоді стануть SQL-, HTML- та JS-ін’єкції. Навіть використовуючи такі інструменти, як BugMagnet, часом усвідомлення, що потрібні ті чи інші дані, приходить вже під час тестування. А тоді часу на тривалі експерименти може не бути, і цікаві тестові ідеї лишаться лише ідеями. Записуйте свої найдивакуватіші ідеї тестів, та повертайтеся до них, коли буде час. Гірше пізно знайденого багу є тільки незнайдений баг.
• підготовка та підтримка тестового середовища - майже завжди обов’язок тестерів, і від того, як воно буде налаштовано, прямо залежить якість тестування. Сформувати вимоги до тестового середовища, сконфігурувати його, дотримуватися чистоти та порядку, і крім того, вчасно вказати точки його невідповідності з продакшеном і які ризики це тягне за собою - на це все потрібен час тестувальника.
• "вивідування" деталей імплементації - так, саме "вивідування". У більшості випадків вистачає й тої інформації, що є, але в ситуаціях, коли володар знань або зайнятий, або відсутній, приходиться докладати чималих зусиль, довідуючись і збираючи по крихтах дані про специфічні граничні умови реалізації та найризикованіші конфігурації. Часом навіть відчуваєш себе шпигуном у ворожому штабі. Так сильно іноді розробники намагаються відкараскатися від чогось, що їм неприємно згадувати. Перекладаючи це на мову естімейтів, враховуйте, що під час тестування може забиратися час програмістів теж.
• підготовка тестових сценаріїв (тобто "писання тесткейсів"). Цей рядок найчастіше включають в естімейти, при цьому маючи на увазі усі вище-означені пункти. Насправді, це окрема діяльність з адміністрування бази сценаріїв, вкладання туди нових зв’язків функціоналу. Якщо база достатньо велика, я особисто можу проводити години за цим заняттям, не вилізаючи з TestRail'у. Також можна назвати це "test design".
• власне "тестування" - дослідження системи на наявність чогось неочікуваного. В естімейтах це називають "test execution" або просто "testing", друге я вважаю більш коректним. Тут головне - глибина (чи ширина?) покриття. Одну й ту ж фічу можна перевірити різними наборами даних, різною кількістю сценаріїв. Існує лише межа мінімальної перевірки - час на "smoke test". Максимальної, звісно, не існує, як не можливо прогнати усі негативні кейси. Для оцінки часу тестування ключовим є пріоритет/северіті (важливість) задачі. Велика задача із низьким пріоритетом може запросто зайняти стільки ж часу на тестування, що й дрібниця з високим пріоритетом.
• локалізація багів - у мене це займає більшість часу тестування. Виконуючи якийсь простий сценарій, боковим зором помічаєш щось дивне, 10 хвилин намагаєшся його повторити, безрезультатно. І потім рука не піднімається поставити йому "Passed OK", і виконуючи наступний кейс знову повертаюсь туди. Можна сказати, що час на локалізацію дефектів пропорційний до знання тестувальником системи.
• реєстрація дефектів - тут все ясно і так, однак хочу зауважити один момент. Часто треба не просто створити тікет, а знайти, чи він вже не зареєстрований. І тут все залежить від обставин вашого проекту. Тому я б радив (у першу чергу собі :-) ) якщо не знайшов такого тікета за одну хвилину, то просто створювати новий, і не паритися. Доля розставить все на місця. 
• ре-тестінг або пере-перевірка. Цей час взагалі не піддається хоч якійсь оцінці, окрім статистичної оскільки прямо залежить від кількості знайдених та виправлених багів. Очевидно, що час на ре-тестінг прямо залежить від імовірності знайти баг. Ця імовірність в свою чергу залежить від середньої якості коду програмістів, а також їхньої зацікавленості проектом/задачею. Але, оскільки ця дія - це теж тестування, то сюди також можна віднести усе, що перераховано для тестування вище.

Цей перелік очевидний і не повний. Тому якщо у вас є цікаві види діяльності тестерів - лишайте в коментах!