Обучение

Новости
О центре
Центр карьеры
Сообщение об ошибке

Обучение

Ближайшие старты

Тренинги EPAM

IT Bootcamp

Новости

О центре

Центр карьеры

Отзывы

Истории успеха

Сообщение об ошибке
Введите поисковый запрос

Планирование тестирования и те случаи, когда может начаться «пожар»

21 марта 2019

Сегодня мы начинаем цикл публикаций для тестировщиков, которые уже получили опыт работы в IT, но хотят повысить профессиональный уровень и развиваться дальше. В первом материале QA директор iTechArt, автор курса «Оценка трудозатрат и планирование тестирования» Оксана Скиндер рассказывает, почему важно грамотно подходить к процессу планирования тестирования и какие типичные ошибки совершают QA Engineer/Tester при оценке сроков выполнения работы.


Виды планирования и оценка работы на старте

Любой специалист, который задействован в проекте, так или иначе планирует работу. Когда утром открывает систему, где написаны тикеты и задачи, а их всегда много, то в первую очередь их приоритезирует. Продумывает, что нужно сделать быстрее, а что может подождать. Уже на этом этапе распределения работы происходит планирование. Этот процесс может быть ограничен рамками, например, текущего дня и исключительно своих задач.

Но бывают и другие ситуации. Допустим, работа организована по Scrum. В таком случае тестировщику нужно определить, что он успеет сделать за итерацию. Причём в самом её начале. Например, разработчики запланировали сделать десять User stories. Что обычно делают тестировщики? Говорят: всё хорошо, ждём. По факту получается, что за два дня до окончания итерации тестировщик получает огромное количество работы. Начинается настоящий пожар: за что хвататься?

Чтобы такого не было, на старте тестировщику нужно посмотреть, что это за User stories – уточнить у разработчиков, в какие сроки они будут выполнены, оценить объём работы. Если видит, что времени будет не хватать, и он не сможет протестировать все User stories, то нужно оговорить эти моменты. Никто не запрещает предложить разработчикам сделать меньше, а в остальное время пофиксить баги. Так работа будет выполнена в оптимальные сроки, а тестировщик не столкнется с лавиной задач. Это уже совместное планирование работы с командой.

Ещё один пример: приходит заказчик и говорит, что 18 числа будет демо для инвесторов – необходимо показать некоторые фичи. Тестировщику нужно продумать, успеет ли он к этому сроку их протестировать. Нередко бывает такое, что 18-ое – это уже завтра. Что делать в таком случае? Здесь важно правильно расставить приоритеты: идти вширь и протестировать как можно больше или углубиться в тестирование отдельных фич. Писать при этом тест-кейсы или обойтись чек-листом. Есть разные ситуации, с которыми в процессе работы сталкивается тестировщик, и когда возникает необходимость в планировании. И чем больше техник и методик знает тестировщик, тем эффективнее сможет это делать.

Подходы в тестировании и уместность их применения

О каких подходах идёт речь? Тестирование может проходить по написанным сценариям  (Scripted testing), когда мы сначала пишем тест-кейсы или тест-скрипты, если речь идёт про автоматизацию, и потом действуем по ним. Но не всегда такой подход применим. Сейчас всё чаще говорят про Agile-разработку, для которой лучше применять Agile-тестирование. Оно заключается в том, что мы получаем фичу и сразу тестируем её,  изучаем отклик, который она даёт, и придумываем новые проверки. Получается такое постоянное тестирование – анализ полученных результатов, баг-репортинг, продумывание новых проверок и опять тестирование. Тестовая документация при этом описывается в виде test session reports – коротких отчётов о проделанной работе и тех проблемах, которые были выявлены в процессе.  

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

На курсе «Оценка трудозатрат и планирование тестирования» мы будем разбирать, по каким признакам понять, какая методика подходит лучше, какой вид тестирования может быть применён в зависимости от фичей и целей, как может варьироваться тестовая документация, как понять, что важно для заказчика, и так далее.

Ошибки при планировании и риски в тестировании


При планировании многие тестировщики действуют по наитию, поэтому не исключены ошибки. Я бы хотела остановиться на трёх самых распространённых.

Неумение обосновывать свою позицию. Когда тестировщик оценил фронт работы и установил срок, за который протестирует фичи, заказчик может поинтересоваться: почему потребуется так много времени? Первая реакция тестировщика, особенно того, у кого опыт работы ещё небольшой: попробуем ужаться! Но ведь никто не просил этого делать – нужно уметь обосновывать свою позицию. Тестировщики пугаются, что заложили слишком много времени. Или попросту боятся сказать заказчику, что на выполнение работы понадобится, например, месяц.

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

Компенсировать риски дополнительным временем. Часто в оценку времени на выполнение задачи добавляют дополнительные часы или дни, так сказать, «на всякий случай». Мало ли что может случиться. Но бывают такие моменты, которые невозможно предусмотреть на старте. Случай из моей практики: нужно было протестировать фичу, на что мы отвели два дня. При этом доступ в систему ждали целый месяц! Это предусмотреть было просто невозможно. И если бы мы действовали с помощью добавления времени, его всё равно оказалось бы мало. Поэтому такой подход не работает. Другой пример: на проект добавили нового разработчика, который ещё не знаком с системой. Вероятность того, что в его фиче будет много багов, очень высокая. Этот риск можно учесть в самом начале. И если риск оправдается, надо сразу пересмотреть оценку и спланировать тестирование заново.

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


Полная, частичная перепечатка или любое иное использование материалов с сайта IT-Academy разрешается только с указанием активной гиперссылки, ведущей на первоисточник (точный адрес страницы на www.it-academy.by).