5 способов оценки времени на тестирование

По моим наблюдениям, сроки тестирования определяются по следующим критериям:

знание продукта;
количество сессий тестирования;
тип тестирования;
компетентность;
исправление багов.

Давайте погрузимся в каждый из них.

Знание продукта

К примеру, оценка времени тестирования будет отличаться между тестировщиком, который знаком с продуктом месяц и тестировщиком, который знаком с продуктом год, просто потому, что последнему известно больше деталей и подводных камней. Второй тестировщик нырнул глубже, чем первый. Конечно, бывает и так, что второй тестировщик страдает батофобией и продолжает плавать на поверхности в надувных нарукавниках. Но, предположим, что перед нами всё-таки храбрый тестировщик.

Количество сессий тестирования

Некомпетентный ответ: это займёт день/два дня/неделю. Подозрительно точно, не так ли? Вы же не перемещались в будущее, если, конечно, у вас нет машины времени. Вам ведь может понадобиться куда больше времени из-за непредсказуемых обстоятельств или внешних причин, от которых будет зависеть время тестирования.

Прежде, чем приступить к фактическому тестированию, тестировщику предстоит выполнить массу действий:

Прочесть документацию (если таковая присутствует).
Пообщаться с командой, чтобы узнать больше о продукте.
Подготовить всё для тестирования (тестовые данные, инструменты, тестовые сценарии, настройка тестовой среды, получить доступ к нужным сервисам и т.д.).
Провести первый этап тестирования и создать заметки по багам.
Дождаться исправления багов, выполнить второй этап тестирования, убрать заметки с исправленными багами и создать новые.
Повторить шаг 4 и 5, пока продукт не будет выглядеть без сучка и без задоринки. Что называется, «с иголочки».

Допустим, менеджер хочет услышать прозрачную оценку времени на тестирование (шаги 4, 5, 6). Даже здесь рамки процесса всё ещё размыты. Представим, что у нас есть функционал, который можно протестировать за пару дней. Это не значит, что тестировщик будет трудиться все пару дней над продуктом, не вставая из-за стола. Любому человеку понадобятся перерывы, чтобы проводить тестирование более эффективно.

Во время каждого этапа тестирования, у вас может быть несколько сессий тестирования (30 минут, час, 90 минут и т.д.). Между сессиями, у вас есть другие дела (общение в чатах, с коллегами, совещания, обед, кофе-брейки, отдых и тому прочее). В итоге, два дня тестирования могут растянуться на целую неделю. Нереально достичь такого же эффекта, проводя тестирование два дня подряд. Тестировщику нужны эти перерывы.

Какую же оценку передать менеджеру? Два дня или пять? Чисто тестирование займёт пару дней, но чтобы выполнять его более эффективно и продуктивно, нужно растянуть процесс поэтапно. Что бы вы не сказали, ваш менеджер должен быть в курсе вашего подхода к тестированию, так вы сможете отстоять свою позицию.

Мудрый ответ: в случае отсутствия багов, мне понадобится столько-то времени, чтобы протестировать такую-то часть функционала. Время на тестирования, отчеты о багах и последующее тестирование будет варьироваться в зависимости от того, насколько сырой продукт. Все мы знаем, что не бывает продукта без багов. Даже если вы думаете, что выявили все баги, это не так. В любом случае, список багов, обнаруженных на первом этапе (или при любом другом) тестирования отсрочивает день презентации готового продукта. Поэтому, называйте нужный вам интервал времени, а не точное количество часов.

Тип тестирования

Применяемый тип тестирования напрямую влияет на время тестирования. Диапазон времени варьируется в зависимости от типа тестирования и его глубины. Будь то тестирование UI или API, дымовое, приемочное, или регрессионное.

К примеру, если ваше тестирование сравни исследованию поверхности воды (просто, чтобы узнать температуру воды), оно займет совсем немного времени. Но если вы собираетесь погрузиться на глубину в купальнике и с баллоном на спине, вам потребуется больше времени, чтобы тщательно исследовать конкретный участок.

Нужно больше подготовки, чтобы более медленно и тщательно анализировать пространство, двигаясь со скоростью воздушных пузырей под водой. Может быть, для исследования вам понадобится несколько раз сменить водолазный баллон или понадобится больше людей.

Компетентность

Если вы профессионал в API-тестировании, времени на выполнение уйдёт меньше, чем у тестировщика, у которого меньше знаний в этом типе тестирования. Тоже самое с тестированием безопасности, производительности и т.д. Всё более популярными становятся T-shaped специалисты. Но не ждите, что работа будет выполнена столь же быстро, как это может сделать профессионал. Убедитесь, что задачу будет выполнять тот же человек, который оценивал время её выполнения. Если же оценку давал кто-то другой (например, ваш QA-руководитель), он/она должен учитывать уровень профессионализма каждого QA-инженера в команде.

Как бы не оценивались сроки, кое-что нужно иметь в виду:

всегда прикидывайте запас времени (20%-30%);
будьте готовы к тому, что тестирование завершится быстрее ожидаемого (менеджеры будут в восторге);
будьте готовы к тому, что тестирование может выйти за рамки сроков (но это уже отдельная тема).

Исправление багов

Хочу отдельно раскрыть шаг 6 среди подходов к сессиям тестирования (итеративный подход). Работа тестировщика, проводящего тестирование вместе со сборкой, выглядит следующим образом:

есть 1-ая сборка для тестирования;
после первой сессии тестирования вы готовите отчёт о багах;
затем, у вас есть 2-ая сборка;
вы проверяете исправление багов и продолжаете вторую сессию тестирования (возможно, снова готовите отчёт о багах)

Тестирование будет проводиться в несколько этапов, до тех пор, пока продукт не будет выглядеть без сучка и без задоринки, что называется, «с иголочки».

Как видите, у нас остаются временные промежутки для исправления багов. Вы не можете оценить и предугадать сколько понадобится времени на каждое исправление бага. Следовательно, невозможно предугадать, когда получится новая сборка после первой сессии тестирования. Даже если вы профи в оценке тестирования и знаете наверняка сколько понадобится времени на тестирование, вы всё равно не предвидите насколько, возможно, придется отсрочить тестирование для исправления багов. Вы, конечно, можете заместить время ожидания сборки другими делами, но, в конце концов, все хотят видеть прогресс и видимые результаты. Но когда это наступит?

Вы не можете предсказать, на сколько, возможно, придется отсрочить тестирование для исправления багов.

Нам нужно различать время тестирования и время стабилизации сборки. Время стабилизации сборки может варьироваться, за это отвечает вся команда. На практике, запас времени, который каждый из команды вкладывает в свою оценку, должен частично включать время стабилизации сборки. Главный вопрос заключается в том, сколько времени команда может себе вообще позволить, учитывая сумасшедший график релизов в Agile-мире.

Безусловно, существуют и другие способы выполнить точную оценку. Но я включил те, которые наиболее заслуживают внимания, с моей точки зрения.

Оригинал статьи: https://medium.com/geekculture/5-ways-for-testing-time-estimation-ed113f5d1998