В традиционных тест-техниках и методологиях тестирование — очень редко встречающийся ресурс. Из-за постоянных бюджетных и временных ограничений нужно учитывать риски, чтобы не было финансовых трудностей перед датой финального релиза проверяемого программного обеспечения.
Но когда есть инструментарий и проверенные временем подходы, которые увеличивают доходность от процесса тестирования за счет большей суммы проверок и их частого обновления, все-таки можно постараться окупить процесс тестирования.
Протестировать абсолютно все практически невозможно, а если даже и появляется такая уверенность, скорее всего, вы что-то упустили.
Это значит, что в контексте традиционных тест-техник и видов тестирования всегда нужно приоритизировать и комбинировать проверки, чтобы получить максимум из процесса тестирования программного обеспечения.Для этого можно воспользоваться такими методиками и рекомендациями:
- Применение пресловутого приоритета MoScoW при использовании каждого тест-кейса (Must Should Could Would — нужно протестировать, желательно проверить, точно протестируем, проверим в будущем). Но порой бывает так, что менеджмент компании считает, что только 20-30% процентов созданных тест-кейсов обязательны к проверке, а бизнес, банально, нуждается в большем количестве проверок, пока не будет достигнут необходимый уровень покрытия. Возникает дисбаланс;
- Попарная комбинаторика и применение классов эквивалентности.позволяют снизить число тестов и акцентируют внимание на низкоуровневых и информационных полях, форматах, а не на обширных бизнес-задачах;
- Переговоры, включат ли данный тест в общий регресс, в набор интеграций, или во что-то другое. Порой, регресс-проверки являются для тестировщика более значительными, чем проверки нового (недавно добавленного) функционала. Зачастую, интеграционные и приемочные проверки могут показаться идентичными, тогда возникает вопрос, зачем вообще проверять все дважды? Бизнесу нужны не красивые фразы, а итоги, под каким-то определенным именем.
Суммирование проверок — это…
Качественная аналогия для проверки всего существующего — это простой подсчет всех возможных десятичных дробей. За каждой из них может скрываться еще одна, и для рандомного числа можно подбирать n-количество чисел рядом.
Что-то подобное происходит и с тестами ПО. Вы можете выбирать любое количество оригинальных вариаций проверки (веб-окружение, повадки пользователя, время, заранее заготовленные условия и прочее). Очень трудно подсчитать то, что может перетекать друг в друга, так как две проверки могут покрыть в целом что-то общее, но в сумме получатся совсем разными.
Традиционные техники, указанные выше — это всего лишь техники процесса фильтрации, когда для начала сводится бесконечная сумма потенциальных тестов к чему-то определенному, при котором каждая проверка отделена друг от друга. Как гласит аналогия Аарона, это такой себе «камень». Потом они фильтруются, после чего их приводят к определенной итоговой сумме, которую можно выполнить и дать ответ на вопрос: когда процесс тестирования можно считать завершенным.
Древние издержки тестирования
Вся вышеупомянутая фильтрация исходит от посыла, что каждый отдельно высчитанный тест стоит определенных денег, и, по аналогии, что подготовительный процесс и прогон каждого теста имеет свою цену.
Аналитиками давно было подсчитано, что средняя цена создания классического тест-кейса осуществима за три часа, один час потребуется на прогон (может быть, с 45-50% вероятностью повторного прогона или работе по нахождению бага).
В сумме, при потенциальных 100 тест-кейсах, классическая модель временных и финансовых издержек будет следующей: не меньше 450 часов, по три часа на один тест, с обязательным повторным прогоном в половине случаев.
Вообще ничуть не странно, что область менеджмента желает уменьшить подобные траты и привести все издержки к минимальному значению.
Стоит также помнить, что при идеальном сценарии это сможет покрыть прогон тестов только один раз, и их 50% — два раза. Есть ли это полной гарантией безопасности, дабы продолжить движение?
Свежий взгляд на доходность
Больше половины современных инструментов и методов тестирования ПО ставят данный подход с ног на голову и акцентируют внимание на том, дабы сделать процедуру тестирования максимально быстрой, иногда, очень дешевой и непрактичной при последующем использовании.
При измерении окупаемости проект, так или иначе, будет содержать процентное соотношение автоматизированных проверок, но для доступности понимания давайте предположим, что только 75% процентов тестов могут быть автоматизированными или могут поддерживаться инструментарием так, что при прогоне они не «остановятся».
Например, тест прогоняется как неотъемлемая часть непрерывного тестирования CI/CD, и для этого вам не понадобятся ни руки, ни глаза.
Ее подготовительные работы занимают некоторое время — например, те же 3 часа. Итак, на 25 проверок без автоматизации понадобится 112,5 часов, но процесс автоматизации, где прогон бесплатный, требует не более 225 часов подготовительных работ. Даже в подобной схеме издержек они уже меньше на 25-30%, включая повторные прогоны на оставшиеся 50% тестов.
Новый подход направлен на создание максимально изобильных и наиболее распространенных тестов, а не таких, которые были бы редким явлением. Если постоянно применять пользу от CI/CD и полнокомандный подход к качеству, то на проектах будет наблюдаться положительная динамика с максимальной пользой для бизнес-задач.
Выводы
Итак, чтобы завершить все вышеизложенное касательно процесса окупаемости процесса проверки ПО, стоит усвоить вот такие постулаты:
- Частый прогон тестов — хорошая практика, дающая максимальную выгоду не только для QA отдела, но и для всех бизнес-процессов;
- Производительность организации зависит от качества выполняемых тестов — чем проверка скрупулезнее составлена, тем она выгоднее бизнесу;
- Все тест-кейсы должны стать чем-то быстрым, что постоянно повторяется при выборке значений из возможных величин.
Оставить комментарий