Что делать когда нет времени на тестирование: лайф-хаки и практики

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

Что же делать, когда времени нет?

1. Приоритизация

Пожалуй, это первое, что нужно сделать в том случае, когда времени на тестирование совсем или почти не осталось. Для начала следует определить, какие функциональности являются наиболее важными с точки зрения бизнеса, а также что именно ни в коем случае нельзя предоставить пользователям в «сыром виде». Эти части приложения и станут основой для составления тестов с высоким приоритетом. Если же тесты уже составлены, то достаточно будет посмотреть на них и отобрать только те, которые покрывают наиболее критичные пользовательские сценарии. Таким образом, у вас появится возможность проверить функциональности, действительно важные для целевой аудитории, – собственно, то, ради чего и будут покупать продукт.

2. Смоук-тестирование

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

3. Тестирование затронутых функциональностей + регрессия

Существует еще один способ быстрой проверки готовности новой версии продукта к релизу – тестирование только измененных и «свежих» функциональностей («старые» при этом поверхностно проверяются регрессионными тестами, например, смоуком). В этом случае не стоит забывать, что подробные проверки лучше оставить на тот момент, когда времени будет достаточно; по самому же главному в новых и затронутых «фичах» пробежаться все-таки стоит.

4. Исследовательское тестирование

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

5. Каждая функциональность – привыкшему к ней тестировщику

Допустим, каждую из функциональностей всегда проверяет какой-то определенный тестировщик. Он отлично знаком с ней, знает каждый уголок и может с ходу рассказать о существующих проблемах. Прекрасно! Оставьте ему проверку привычной «фичи», не отдавайте ее кому-то другому. Таким образом вы не только сократите время тестирования, но и сможете быть уверенными в действительно качественной проверке функциональности. Эксперименты и ротации оставьте на тот момент, когда у вас будет возможность разнообразить устоявшийся процесс.

6. Требования вместо тестов

Требования на проекте всегда поддерживаются в актуальном состоянии? Это настоящее везение в тех случаях, когда времени на тестирование не осталось! Благодаря качественному ТЗ можно существенно уменьшить срок проведения тестирования – достаточно лишь проверить функциональности по требованиям, не составляя никаких проверок. Конечно, этим способом не стоит злоупотреблять (поскольку тесты все-таки позволяют протестировать приложение более качественно), но для сжатых сроков такая проверка вполне подходит. В дополнение к требованиям можно также исследовательски пройтись по «фичам» для закрепления результата.

7. Только позитивные тесты

Да-да, именно так! Не имеет смысла углубляться в тестирование и ломать продукт в том случае, если времени в обрез. Это грозит ситуацией, когда вы вроде бы все протестировали, но в то же время не проверили ничего. Если времени слишком мало, негативные тесты только усугубят ситуацию. Даже если они приведут к дефектам, исправлять такие баги никто не будет до тех пор, пока самое важное не заработает так, как нужно. Именно поэтому в условиях сжатых сроков лучше тестировать только позитивные сценарии. В конце концов, пользователи хотят, чтобы продукт выполнял их задачи; они редко ставят себе цель сломать его (если, конечно, речь идет не о банковском ПО, где ситуация несколько иная).

8. Планирование

Очень часто времени не хватает именно потому, что изначально неправильно определены трудовые затраты, а также не учтены все задачи, которые потребуется выполнить. Я сама оказывалась в такой ситуации, когда из-за ошибки в подсчете времени на тестирование приходилось спешить, стараясь уложиться в срок. Не говорю уже о том, что частым спутником плохого планирования является сверхурочная работа. Каждый раз при планировании своего времени старайтесь брать его с запасом. Прибавьте 30-50% – лучше ошибиться в большую сторону и оставить зазор на более тщательную проверку (или другие задачи), чем тестировать с постоянной оглядкой на часы. Придерживаясь этого правила, вы всегда уложитесь в срок или вообще завершите работу раньше, что само по себе неплохо.

Вывод

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

Об авторе

В «Лаборатории Качества» с 2013 года. Начинала с тестировщика, выросла в полноценного тест-менеджера. Приняла участие в тестирование ряда мобильных и web-проектов. С 2016 года совмещает основную деятельность с преподаванием на курсе «Школа успешных тестировщиков» Натальи Руколь.

Поиск
Облако меток
8 марта (1)api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)ПОИНТ (2)Приёмочное тестирование (1)Юмор (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)банковские приложения (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (4)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (3)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (3)
Получите совет