Правила тестирования

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

Первое правило: никогда не «прогибайтесь» под временные рамки проекта. Оценка трудоемкости цикла тестирования должна быть полной. Руководитель проекта и Заказчик должны понимать, что тестировать приложение полностью – «дорого», поэтому важно доносить до них информацию о том, сколько и как можно протестировать за выделенное время. Хороший план – это залог успеха. А хороший план можно составить только на основании реальных оценок.

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

Третье правило: покрывайте требования тестами в зависимости от приоритетов. Написание тестовых сценариев вещь полезная, однако, весьма трудоемкая. Покрывайте тестами только то, что будете тестировать.

Четвертое правило: внимательно читайте требования. Если есть хотя бы малейшая неоднозначность, не стесняйтесь лишний раз спросить. Цена неточности возникшей в начале цикла разработки, с каждым шагом, этапом, раундом - повышается. Лучше задать глупый вопрос и быть уверенным в ожидаемом результате, чем на последних раундах жизненного цикла проекта/релиза судорожно выяснять, как же должна работать программа. Следите, чтобы требования и test case’ы были в актуальном состоянии.

Пятое правило: проводите раунды тестирования «в свободном полете». Другое название – exploratory testing. Штука весьма и весьма полезная. Протестировать все по test case’ам конечно хорошо. Но пользователи не роботы, а живые люди и они могут сделать что-то не так, не по сценарию. Отсюда следует, что иногда полезно пройтись по приложению в отрыве от test case’ов и «копать» в наиболее часто используемых пользователями местах.

Шестое правило: ведите тест-логи (test logs) аккуратно. Тест-лог – это официальный документ. Он подтвердит результаты проверки, и как следствие – общее качество разработанного продукта. Лог должен вестись добросовестно. Самая неприятная ситуация, когда тест помечен как успешно пройденный, а на деле получается, что этот кусок функциональности не работает совсем, и работать ранее не мог. Прививайте культуру ведения тест-логов в вашей команде.

Седьмое правило: все ошибки должны быть зарегистрированы (записаны, занесены в систему управления дефектами). Прививайте культуру фиксации дефекта сразу после его обнаружения. Ошибки должны исправляться, но откладывание занесения ошибки, а, следовательно, её «обнародования» сдвинет момент исправления. В результате риск сорвать сроки увеличивается.

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