Наверняка многие тестировщики хотя бы раз сталкивались с ситуацией, когда времени на тестирование совершенно нет. Даже если им чуточку повезло, и хоть какое-то время осталось, то его все равно не хватит на проверку всего продукта. И не столь важно, почему так получилось (неправильно спланирована работа, заказчик захотел «прикрутить вон ту фичу» в самый последний момент, тестировщиков поздно подключили к проекту), – главное в том, что выходить из положения как-то нужно.
Итак, что же делать, когда времени вовсе не осталось, а тестировать хочешь не хочешь, но надо? Можно искать виноватых, кивать друг на друга, бегать в панике, но, как мне кажется, каждый понимает, что это неконструктивный подход. В этой статье я расскажу о своем опыте, позволяющем справиться с тесными временными рамками. Ниже я составила список подходов, которые можно применить в условиях сжатых сроков.
Что же делать, когда времени нет?
1. Приоритизация
Пожалуй, это первое, что нужно сделать в том случае, когда времени на тестирование совсем или почти не осталось. Для начала следует определить, какие функциональности являются наиболее важными с точки зрения бизнеса, а также что именно ни в коем случае нельзя предоставить пользователям в «сыром виде». Эти части приложения и станут основой для составления тестов с высоким приоритетом. Если же тесты уже составлены, то достаточно будет посмотреть на них и отобрать только те, которые покрывают наиболее критичные пользовательские сценарии. Таким образом, у вас появится возможность проверить функциональности, действительно важные для целевой аудитории, – собственно, то, ради чего и будут покупать продукт.
2. Смоук-тестирование
Этот пункт тесно связан с предыдущим, поскольку для смоук-тестов всегда выбираются наиболее важные бизнес-сценарии. Каждая команда тестирования должна всегда иметь наготове такие проверки. В ситуации, когда времени для выполнения тестов совсем не выделили, вам будет достаточно просто прогнать смоук для того, чтобы убедиться в корректности поведения критичных функциональностей или выявить проблемы неудачного релиза, способные привести проект к финансовым потерям.
3. Тестирование затронутых функциональностей + регрессия
Существует еще один способ быстрой проверки готовности новой версии продукта к релизу – тестирование только измененных и «свежих» функциональностей («старые» при этом поверхностно проверяются регрессионными тестами, например, смоуком). В этом случае не стоит забывать, что подробные проверки лучше оставить на тот момент, когда времени будет достаточно; по самому же главному в новых и затронутых «фичах» пробежаться все-таки стоит.
4. Исследовательское тестирование
Казалось бы, нет ничего хорошего в том, чтобы вообще не использовать никаких тестов: как же тогда документировать результаты проверок? Выход есть! Определите ключевые сценарии в тестируемом приложении и в ходе проверки составляйте тесты, попутно записывая каждый из них. Так вы будете знать, что проверили, и что получилось в результате. Исследовательский подход не только позволит вам сэкономить время на составлении тестов, но и даст возможность быстро проверить то, что действительно важно для текущего релиза.
5. Каждая функциональность – привыкшему к ней тестировщику
Допустим, каждую из функциональностей всегда проверяет какой-то определенный тестировщик. Он отлично знаком с ней, знает каждый уголок и может с ходу рассказать о существующих проблемах. Прекрасно! Оставьте ему проверку привычной «фичи», не отдавайте ее кому-то другому. Таким образом вы не только сократите время тестирования, но и сможете быть уверенными в действительно качественной проверке функциональности. Эксперименты и ротации оставьте на тот момент, когда у вас будет возможность разнообразить устоявшийся процесс.
6. Требования вместо тестов
Требования на проекте всегда поддерживаются в актуальном состоянии? Это настоящее везение в тех случаях, когда времени на тестирование не осталось! Благодаря качественному ТЗ можно существенно уменьшить срок проведения тестирования – достаточно лишь проверить функциональности по требованиям, не составляя никаких проверок. Конечно, этим способом не стоит злоупотреблять (поскольку тесты все-таки позволяют протестировать приложение более качественно), но для сжатых сроков такая проверка вполне подходит. В дополнение к требованиям можно также исследовательски пройтись по «фичам» для закрепления результата.
7. Только позитивные тесты
Да-да, именно так! Не имеет смысла углубляться в тестирование и ломать продукт в том случае, если времени в обрез. Это грозит ситуацией, когда вы вроде бы все протестировали, но в то же время не проверили ничего. Если времени слишком мало, негативные тесты только усугубят ситуацию. Даже если они приведут к дефектам, исправлять такие баги никто не будет до тех пор, пока самое важное не заработает так, как нужно. Именно поэтому в условиях сжатых сроков лучше тестировать только позитивные сценарии. В конце концов, пользователи хотят, чтобы продукт выполнял их задачи; они редко ставят себе цель сломать его (если, конечно, речь идет не о банковском ПО, где ситуация несколько иная).
8. Планирование
Очень часто времени не хватает именно потому, что изначально неправильно определены трудовые затраты, а также не учтены все задачи, которые потребуется выполнить. Я сама оказывалась в такой ситуации, когда из-за ошибки в подсчете времени на тестирование приходилось спешить, стараясь уложиться в срок. Не говорю уже о том, что частым спутником плохого планирования является сверхурочная работа. Каждый раз при планировании своего времени старайтесь брать его с запасом. Прибавьте 30-50% – лучше ошибиться в большую сторону и оставить зазор на более тщательную проверку (или другие задачи), чем тестировать с постоянной оглядкой на часы. Придерживаясь этого правила, вы всегда уложитесь в срок или вообще завершите работу раньше, что само по себе неплохо.
Вывод
Отсутствие времени на тестирование – это всегда неприятно, ведь тестировщикам так хочется как можно качественнее проверить продукт, выполнить как можно больше проверок и в итоге порадовать конечных пользователей прекрасным результатом. Но недостаток времени вовсе не означает, что продукт обязательно получится плохим. Как видите, всегда есть выход – достаточно просто собраться с мыслями и правильно спланировать работу в такой нелегкой ситуации.
Проверьте самое главное, подключите исследовательское тестирование, сверьте продукт с требованиями, отбросьте второстепенное – и тогда вы сможете спать спокойно, зная, что сделали все возможное. Главное – не бояться и идти в бой, смело бросая вызов страшному зверю по имени «Нет времени».
