Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Много — не всегда хорошо. В чем суть достаточного тестирования и как его использовать правильно

Много — это не всегда хорошо. В этой статье постараюсь убедить вас в том, что объедаться вредно и хорошо знать меру :) Каждый уважающий себя тестировщик в душе перфекционист и стремится сделать все как можно лучше. Благое стремление, которое может привести в самый настоящий ад. Чтобы этого не допустить, предлагаю подход достаточного тестирования. Статья поможет вам с выбором приоритетов и критериев для составления плана тестирования.

Иллюстрации Уляны Патоки

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

Поэтому частым советом, особенно для начинающих тестировщиков (хотя и заканчивающих тестировщиков я не встречал), становится: тестируйте всё и всеми известными способами. Что с точки зрения тестирования, возможно, и не такой плохой подход. Особенно если тестируете программы для атомной станции. Но в условиях коммерческого программирования на заказ, с ограниченным бюджетом это может оказаться разрушительным. Расширяя поле тестирования, увеличивая проверки до бесконечности, мы также в бесконечность увеличиваем время, необходимое на проверку. И вот перед нами чек-лист на несколько тысяч пунктов, и вроде бы все из них нужные. А времени на тестирование как было 8 часов, так и осталось, потому как задачи обычные. И это еще не учитывая ситуации, когда менеджмент требует постепенно уменьшать время, затрачиваемое на тестирование, поскольку бюджеты в условиях кризиса уменьшаются.

Количество проверок

Также к избыточности тестирования ведут рассуждения вроде: «Могу ли я провести тот или иной вид тестирования на моем проекте?» Практически всегда ответ будет: «Да, такая возможность существует». Но, прежде чем начинать расширять поле тестирования, добавлять новые инструменты и подходы, было бы разумно задуматься вот над чем.

Каждая, даже самая маленькая и простая проверка — это способ получить какую-то информацию о проекте или тестируемом объекте. Добавляя новые проверки, сможем ли мы узнать что-то новое о проекте или же это будет пустая информация? Приведу пример из своей практики.

На собеседовании я предложил кандидату совместно разработать подходы к тестированию простого проекта — сайта под управлением CMS WordPress. Это тот тип вопросов, у которого нет правильного ответа. Он хорошо показывает подходы к работе и образ мышления человека.

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

Неизвестность и вероятность

Также частые причины, из-за которых раздувается время тестирования, — неизвестность и вероятность. Что я подразумеваю под этими терминами? Неизвестность — это то, с чем сталкивается любой тестировщик хоть на новом проекте, хоть уже на существующем. Все ли я посмотрел? Не осталось ли мест, ситуаций, окружения, при которых появляются баги? Если ничего не делать с этой неизвестностью, то время тестирования будет постоянно расти. Потому что, положа руку на сердце, всегда можно еще немножко проверить или глянуть на проект чуть иначе: в другом окружении, разрешении и при других вводных данных. Вероятность — это вероятность возникновения бага. Баги есть всегда, но вот появляются они в момент обнаружения. Поэтому, пока баг не обнаружен и не исправлен, нельзя с уверенностью утверждать, что его там не существует.

Поэтому, добавляя ту или иную проверку, мы увеличиваем вероятность обнаружения бага. Грубо говоря, в тестировании как в рыбалке: чем больше сетей расставим, тем выше вероятность что-то поймать. Но и по аналогии с рыбалкой нужно сказать, что ставить сети на берегу, где рыбы нет по определению, так же неразумно, как добавлять бездумно проверки. Ведь так нарушается один из принципов тестирования, а именно скопление дефектов. То самое знаменитое правило 80/20 только в применении к тестированию: 80 процентов багов сосредоточены в 20 процентах модулей. И это значит, что проверять нужно там.

Время тестирования

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

И тогда тестирование становится бессмысленным. Мы приходим к явному противоречию: с точки зрения тестирования нужно увеличивать количество проверок, с точки зрения бизнеса нужно их уменьшать, при этом нельзя допускать потери качества. Выходом из этого противоречия становится достаточное тестирование, которое опирается на один из основных принципов процесса: тестирование зависит от контекста. Большой бюджет, много времени — проверяем все; малый бюджет, мало времени — проверяем только основной функционал.

Что делать

Как в этих условиях выбрать, что тестировать обязательно, а что по остаточному принципу? Хорошо, когда есть возможность согласовать ваши подходы с менеджером проекта. Но на практике часто и менеджер проекта, и технический директор компании скажет, что проверять нужно все и чтобы багов там не было. Поэтому разработка критериев, по которым тестировщик будет составлять список тестовых активностей, будет полностью на менеджере. При выработке таких критериев опереться можно на требования к проекту, на логику (для чего он работает) и частоту обращений пользователей к определенному функционалу. Рассмотрим каждый пункт отдельно.

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

Логика проекта. Каждый проект делается для чего-то конкретного. У него есть цель, функция, которую он выполняет. Если понять ее, можно без труда выделить основные функциональности, которые требуют особого внимания, и вспомогательные и проверить их по остаточному принципу. Если позволяет время и бюджет. В качестве примера приведу сайт-визитку с формой обратной связи. Если не работает форма обратной связи — основной функционал проекта, то не так важно, сохраняется ли pixel perfect в IE11. Тут сразу видно, где основная функциональность и что тестировать в первую очередь.

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

Подведем итог

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному11
LinkedIn

Схожі статті




7 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

«Баги есть всегда, но вот появляются они в момент обнаружения.» -
Серьезно?) Вы уверенны в этом?

Из-за багов клиент теряет время, а значит, и деньги, ведь разработчики тратят время (читай деньги) на исправление багов.

Ой как некрасиво...
Из-за багов заказчик теряет:
1. Своих клиентов (клиент не смог ввести данные в форму из-за бага — плюнул и ушёл к конкуренту).
2. Репутацию (если у тебя система работает через раз, то как ты не рассказывай про её потенциал — никто им пользоваться не будет).
3. Деньги. Предположим аппликуху, которая из-за бага отослала деньги клиента не туда, куда надо. В самом лучшем случае заказчик будет вынужден возместить потерю из своего кармана. В худшем случае — суд, который добавит штрафные санкции. А если таких клиентов будет 10, 100, 1000?
4. И вот только тут в список попадают деньги, потраченные на фикс багов. Притом, если контракт по фиксед прайсу, то деньги будет терять галера, не заказчик.

Вообще, это 1 из моих любимых вопросов на собесе:
У тебя есть 1000 тест кейсов, пройти их занимает 5 дней. К тебе подходит манагер и говорит, что у тебя есть 2. Твои действия?
Идеально правильного ответа тут нет, это задачка на поразмышлять, но:
1. Первое, что нужно иметь — список приоретизированных тест кейсов для всей аппликухи.
2. Список изменений в текущем релизе.
3. Исходя из 2, 1 и ограничений по времени, составить список тест кейсов.
4. Согласовать с менеджментом / заказчиком риски не покрытия того, что в список не попало.

Вот пункта 1 в тексте я не увидел. Он плавно размазан, как масло по бутерброду. А без этого вся идея превращается в тыкву...

Дополнительно человека взять:) приоритетность хорошо, но когда это с клиентом согласовано; Важен каждый баг.

Нет. Приоритет — это ответственность тестировщика. Так же, как и написание тест кейсов. Согласовывать необходимо риски, не методику работы.
Дополнительно взять человека- он за 2 дня даже в AUT не разберётся, будет задавать тонны вопросов, отвлекая остальную команду от работы, в результате чего суммарный перформанс команды будет ниже, чем без него. Перформанс выйдет в 0 примерно через месяц-два, этого времени у Вас по условиям задачи нет.

Шикарный текст.

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

Оно, вроде бы, логично, и позволяет уложиться в ограниченное время, и даже, кагбэ, решает проблему «надо удовлетворить заказчика». Но это грозит большой проблемой в будущем — вы когда-нибудь забудете «затянуть чёртовы гайки» на каком-нибудь колесе автомобиля, который готовите к дальней поездке, бо сосредоточились на проверке удобства переключения режимов фар и настройках подголовника. Здравый смысл же нам говорит о том, что никто и никогда не забывает затянуть гайки на колёсах, а в пути водителю должно быть удобно сидеть (и тестирование полностью ушло в салон).

А гайки на колёсах таки надо проверять всегда, бо без колёс всё остальное не имеет смысла.

И ещё ваше предложение подразумевает, что нет особой нужды общаться с манагерами и бизнесом (а всё равно они в тестировании нифига не понимают же!), и принимаем решения самостоятельно. А это чревато, и выгоранием, кстати, тоже.

Давайте упростим до тезисов?

Если нет ориентиров (или же — цель поставлена излишне абстрактно), то определить scope* и объёмы тестирования становится логически невозможно. Исчерпывающее оно будет или зачерпывающее — неважно, нет ориентиров, у нас поле бесконечных возможностей.

* не знаю адекватного перевода scope термина на русский, поэтому нехай остаётся без перевода.

А если поле бесконечное, то кажется, что придётся заниматься исчерпывающим тестированием.

Нет, не придётся. Просто нужно определить ориентиры и границы.

«Исчерпывающее тестирование» — шняжка из древней истории компьютерных гениев, которая обязательно должна быть принята во внимание при обдумывании scope и объёмов тестирования. Но это — теория. И оно изначально было теоретическим рассуждением, бо учтём очевидные ограничения старых счётных машин по времени и ресурсам. А ближе к нашему времени оно редуцировалось до пугалки в стиле «Невозможно протестировать всё, а кто считает иначе, тот дурак!». Но зачем стараться достичь недостигаемое? :)

Не надо всё тестировать. Надо всё учесть, а затем принимать решение о том, что будем тестировать.

ПО надо лепить с учётом задач и ограничений, это сразу отметает множество проверок, которые в принципе можно было бы сделать, но уже зачем? Для примера: ввод букв в калькулятор. Откройте калькулятор на смартфоне — где там вводить буквы, э? Ну и сразу отпадает целое семейство вероятных проверок. А если думать про калькулятор абстрактно, то ооооо, дададада, давайте учтём ввод букв, и в разных сочетаниях, и в разных кодировках...

Когда перед нами чек-лист на несколько тысяч пунктов, и вроде бы все из них нужные, а времени на тестирование как было 8 часов, так и осталось — это не «неразрешимое противоречие», это просто результат первичного анализа. Надо продолжать копать.

Шаг 1.

Вот анализ показал, что полный список проверок — 7 000 пунктов. А на тестирование 8 часов. Не сдаёмся, продолжаем рассуждать.

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

Разделите это всё на два списка:
* Critical
* Not so critical

Вы также можете сообразить, какие из этих 7 000 пунктов можно по каким-то критериям объединить в единые сущности (и шагая от классов эквивалентности вы вступаете в высокую сферу доменного тестирования), а какие можно и выбросить, даже если поначалу казалось, что все они важны и нужны. Анализ может это всё показать и доказать, что вряд ли ВСЕ эти 7 000 проверок реально нужно выполнять.

Шаг 2.

Не предполагаем, что всё знаем. Роман Савин об этом честно рассказывал — он как-то решал, которые заказчики для сайта по продаже запчастей важнее, американские или японские, и круто ошибся. Но, судя по телеграм-каналам современных джунов, читать Савина уже считается позорным зашкваром. Не надо так.

Вы вполне можете сперва самостоятельно разбросать 7 000 пунктов в эти два раздела, а затем затребовать у менеджера/бизнеса согласования — бо это дело таки надо согласовывать. Мы же бизнес обслуживаем? Вот и надо с ним работу согласовать, а не кидаться выполнять на основе самостоятельного суждения.

И нормальный, и ненормальный менеджер будет всё сувать в раздел VERY-VERY CRITICAL, бо он обязан так относиться к своему проекту. Но если у вас будут вопросы и аргументы — всё наладится, особенно если вы все ваши проверки привяжете к обобщающим категориям вроде Product Page, User Profile, Cart, Help Pages и ты ды.

Шаг 3.

Надо знать точно, сколько времени нужно на проход каждого раздела. Можете выяснять это поминутно, можете часами на каждую категорию, но важно это как-то выяснить, и именно для этого нужна категоризация и приоритизация. Менеджер это оценит, бо наконец-то ему становится понятно, сколько конкретно времени нужно на тестирование и даже — на что именно.

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

«Менеджмент [всегда] требует постепенно уменьшать время, затрачиваемое на тестирование, поскольку [неважно, почему]» — это да, но физиология тестирования такая, что чем меньше что-то проверяешь, тем выше вероятность что-то пропустить. Это риск, на который бизнес вполне может пойти, особенно если начать разговаривать с теми, кто принимают решения, если заранее обдумывать и стыковать хотелки и возможности.

Опять же подобный список помогает тестировщику начинать с самого важного и не пропускать ничего. Опыт «пропускания» есть у каждого, и иногда это опыт болезненный. Лечение — спискота и важнота.

Бизнес требует максимума за свои деньги, но всегда ориентируется на «good enough». Это надо учесть и это надо обсуждать.

ПИСИ Программы для атомной станции, к слову, как раз тестируют не исчерпывающе, а строго попунктно, практически так же, как мы тестируем чёртов ГУИ — кнопка есть? Есть. Делает логин? Делает. Браузер пусть будет Хром, то сегодня никто в MS Edge не сидит. Всё, бегим далее, у нас 8 часов на прогон 600 тестов, цигель ай лю-лю. Но это ограничение обосновано задачами и условиями, для которых проектировали ПО для ядрёной станции. Если мы начнём в их компьютеры передавать неадекватные параметры потомушо why not?, первыми пострадают наши уши, которые будут рвать зубами проектировщики ПО, а программисты будут молча смотреть и одобрять, и жаловаться будет некому. Кнопки на пульте, как клавиши на пианино, нужно нажимать вовремя в каждый отдельный момент, а не как попало. Бомбанёт же!

ПИПИСИ Ещё про согласование. Я, например, постоянно хочу, чтобы механик мою машину обслуживал ещё дешевле возможного, и всегда эстимейты мы очень рьяно обсуждаем, но когда он уже принимает во внимание мои хотелки и затем ещё принимает разные промежуточные технические решения (тут заменяем полностью, тут не трогаем, тут обойдёмся щепками с изолентой, но ты будешь сам её периодически перетягивать, а тут, вероятно, придётся дополнительно делать то и это) и называет итоговую сумму, я её уже не оспариваю, бо я ознакомлен с рисками, и я их принял, и даже совместные компромиссные решения были приняты нами вместе, а не «Тадааам, начальнике, давай ишшо шешнаддцать тыщ, тут вот тебе задний мост заменили полностью, хотя ты не просил» или «Нет, гайки на колёсах я не затягивал, ведь времени не было, и согласно идеям эквивалентности, мне было достаточно проверить только одну гайку из 20-ти, ведь они все одинаковы, а исчерпывающее тестирование невозможно... Поэтому тормоза тоже не проверял».

Если вам нужен будет ещё тестировщик мануальное тестирование @grettassik в телеграм:)

Баги есть всегда, но вот появляются они в момент обнаружения. Поэтому, пока баг не обнаружен и не исправлен, нельзя с уверенностью утверждать, что его там не существует

Баг Шрёдингера)) Возьму на вооружение!
Спасибо, что озвучили то, что беспокоит, пожалуй, каждого тестировщика)

Підписатись на коментарі