Много — не всегда хорошо. В чем суть достаточного тестирования и как его использовать правильно
Много — это не всегда хорошо. В этой статье постараюсь убедить вас в том, что объедаться вредно и хорошо знать меру :) Каждый уважающий себя тестировщик в душе перфекционист и стремится сделать все как можно лучше. Благое стремление, которое может привести в самый настоящий ад. Чтобы этого не допустить, предлагаю подход достаточного тестирования. Статья поможет вам с выбором приоритетов и критериев для составления плана тестирования.
Иллюстрации Уляны Патоки
Читая материалы по тестированию, часто можно наткнуться на примеры со списками проверок для того или иного функционала. В большинстве из них авторы осознанно или просто стараясь показать побольше видов и подходов к тестированию добавляют огромное число проверок. Как-то я увидел чек-лист на 50 проверок для одного поля ввода. Человек, составивший его, считается уважаемым специалистом, на чей авторитет ссылаются авторы других статей. Но все это увеличение количества проверок стремится ровно к одному — к исчерпывающему тестированию, которое на практике почти невозможно достичь.
Поэтому частым советом, особенно для начинающих тестировщиков (хотя и заканчивающих тестировщиков я не встречал), становится: тестируйте всё и всеми известными способами. Что с точки зрения тестирования, возможно, и не такой плохой подход. Особенно если тестируете программы для атомной станции. Но в условиях коммерческого программирования на заказ, с ограниченным бюджетом это может оказаться разрушительным. Расширяя поле тестирования, увеличивая проверки до бесконечности, мы также в бесконечность увеличиваем время, необходимое на проверку. И вот перед нами чек-лист на несколько тысяч пунктов, и вроде бы все из них нужные. А времени на тестирование как было 8 часов, так и осталось, потому как задачи обычные. И это еще не учитывая ситуации, когда менеджмент требует постепенно уменьшать время, затрачиваемое на тестирование, поскольку бюджеты в условиях кризиса уменьшаются.
Количество проверок
Также к избыточности тестирования ведут рассуждения вроде: «Могу ли я провести тот или иной вид тестирования на моем проекте?» Практически всегда ответ будет: «Да, такая возможность существует». Но, прежде чем начинать расширять поле тестирования, добавлять новые инструменты и подходы, было бы разумно задуматься вот над чем.
Каждая, даже самая маленькая и простая проверка — это способ получить какую-то информацию о проекте или тестируемом объекте. Добавляя новые проверки, сможем ли мы узнать что-то новое о проекте или же это будет пустая информация? Приведу пример из своей практики.
На собеседовании я предложил кандидату совместно разработать подходы к тестированию простого проекта — сайта под управлением CMS WordPress. Это тот тип вопросов, у которого нет правильного ответа. Он хорошо показывает подходы к работе и образ мышления человека.
Кандидат, как и многие из нас на собеседованиях, постарался показать, что знает о существовании большого ряда проверок, техник и подходов, и начал добавлять к нашему плану избыточные проверки. Например, нагрузочное тестирование сайта. Как излишнее, спросите вы? Ведь это важная информация о проекте: какое количество пользователей он одновременно выдержит, от этого зависит и безопасность, и бизнес. И я с вами согласен! Безусловно, это важно, но не в случае, если проект развернут на тестовом сервере. Технически провести такую проверку возможно. Но вот информация, которую мы получим, будет бесполезна, поскольку мы узнаем предел посещаемости тестового сервера и это нам ничего не сообщит о поведении сайта уже на лайве. Это не говоря о том, что, положив тестовый сервер, где хостится не только наш текущий проект, а и проекты всего отдела, добрых слов от коллег мы не услышим. Что же будет, если после такой проверки сервер не поднимется, лучше и не думать.
Неизвестность и вероятность
Также частые причины, из-за которых раздувается время тестирования, — неизвестность и вероятность. Что я подразумеваю под этими терминами? Неизвестность — это то, с чем сталкивается любой тестировщик хоть на новом проекте, хоть уже на существующем. Все ли я посмотрел? Не осталось ли мест, ситуаций, окружения, при которых появляются баги? Если ничего не делать с этой неизвестностью, то время тестирования будет постоянно расти. Потому что, положа руку на сердце, всегда можно еще немножко проверить или глянуть на проект чуть иначе: в другом окружении, разрешении и при других вводных данных. Вероятность — это вероятность возникновения бага. Баги есть всегда, но вот появляются они в момент обнаружения. Поэтому, пока баг не обнаружен и не исправлен, нельзя с уверенностью утверждать, что его там не существует.
Поэтому, добавляя ту или иную проверку, мы увеличиваем вероятность обнаружения бага. Грубо говоря, в тестировании как в рыбалке: чем больше сетей расставим, тем выше вероятность что-то поймать. Но и по аналогии с рыбалкой нужно сказать, что ставить сети на берегу, где рыбы нет по определению, так же неразумно, как добавлять бездумно проверки. Ведь так нарушается один из принципов тестирования, а именно скопление дефектов. То самое знаменитое правило 80/20 только в применении к тестированию: 80 процентов багов сосредоточены в 20 процентах модулей. И это значит, что проверять нужно там.
Время тестирования
Допускаю, что описанное выше определение далеко от ортодоксального толкования тестирования. Но тестирование — это среди прочего деятельность, направленная на уменьшение потерь времени и, как следствие, денег. Из-за багов клиент теряет время, а значит, и деньги, ведь разработчики тратят время (читай деньги) на исправление багов. Потратив немного времени на тестирование сейчас, мы стараемся застраховаться от больших потерь в будущем. Вместе с тем, увеличивая время тестирования (а оно будет увеличиваться, потому что растет количество проверок), мы повышаем его стоимость. И в крайних случаях стоимость проверки станет больше, чем стоимость времени разработчика, потраченного на исправление багов, если их найдет клиент.
И тогда тестирование становится бессмысленным. Мы приходим к явному противоречию: с точки зрения тестирования нужно увеличивать количество проверок, с точки зрения бизнеса нужно их уменьшать, при этом нельзя допускать потери качества. Выходом из этого противоречия становится достаточное тестирование, которое опирается на один из основных принципов процесса: тестирование зависит от контекста. Большой бюджет, много времени — проверяем все; малый бюджет, мало времени — проверяем только основной функционал.
Что делать
Как в этих условиях выбрать, что тестировать обязательно, а что по остаточному принципу? Хорошо, когда есть возможность согласовать ваши подходы с менеджером проекта. Но на практике часто и менеджер проекта, и технический директор компании скажет, что проверять нужно все и чтобы багов там не было. Поэтому разработка критериев, по которым тестировщик будет составлять список тестовых активностей, будет полностью на менеджере. При выработке таких критериев опереться можно на требования к проекту, на логику (для чего он работает) и частоту обращений пользователей к определенному функционалу. Рассмотрим каждый пункт отдельно.
Требования. Тут на первый взгляд все понятно: все требования к проекту должны быть выполнены. Но, думаю, каждый сталкивался с ситуацией, когда проект большой, а требований к нему или нет, или их мало, или они изложены в духе «чтобы все работало и было красиво». В этом случае необходимо составить свои требования. Их иногда называют «неявные требования», то есть требования, которые не прописаны в документации, но подразумеваются или следуют из общей практики и здравого смысла. Если это сделать, то расплывчатое требование «чтобы было красиво» превратится в четкое «чтобы соответствовало дизайну» и так далее.
Логика проекта. Каждый проект делается для чего-то конкретного. У него есть цель, функция, которую он выполняет. Если понять ее, можно без труда выделить основные функциональности, которые требуют особого внимания, и вспомогательные и проверить их по остаточному принципу. Если позволяет время и бюджет. В качестве примера приведу сайт-визитку с формой обратной связи. Если не работает форма обратной связи — основной функционал проекта, то не так важно, сохраняется ли pixel perfect в IE11. Тут сразу видно, где основная функциональность и что тестировать в первую очередь.
Частота обращений пользователей к функциональности. Как часто люди пользуются справкой на проекте? Вот так же часто нужно эту справку тестировать. Если пользователи сосредоточены на определенной конфигурации операционной системы, браузере или платформе, то на ней и нужно тестировать в первую очередь. Если проект долгий, то у вас, скорее всего, будет определенная статистика. А если новый, следует исходить из общих представлений о популярности устройств, браузеров и так далее. Но также подумать над тем, какие части проекта будут использоваться чаще, и на основе этой гипотезы расставить приоритеты.
Подведем итог
Вооружившись этими критериями, вы сможете составить план тестирования для любого проекта с расчетом на любое доступное время. Подход достаточного тестирования не даст гарантии отсутствия багов. Как и любой другой подход. Но даст уверенность в том, что требования выполнены, а основной функционал и самые востребованные части проекта работоспособны. Этот подход ни в коем случае нельзя рассматривать как способ выполнять меньше проверок, а наоборот — как способ максимально эффективно использовать имеющееся время на тестирование. Потому как всем известно, что время — это деньги.
