На работе (вне собственных пет-проектов) тестировщик никогда не существует в вакууме - он решает некоторые задачи бизнеса, а значит все решения должны приниматься с оглядкой на финансовую целесообразность. Иногда это противоречит внутреннему перфекционизму. Сегодня расскажу о некоторых неочевидных принципах автоматизированного тестирования, которые сводятся к тому, что иногда необходимо искать компромисс, а не следовать за тем самым перфекционизмом.
Подумай, прежде чем сделать. Думай больше о переиспользовании сущностей.
Любой джун знает, что перед тем, как приступать к выполнению любой задачи, надо подумать. Это относится не только к тестированию как таковому, но и в целом к разработке. Чем раньше найдена проблема, тем дешевле ее исправить, поэтому так распространены так называемые shift left практики. Вспомним хотя бы метод “три амиго”, когда собираются вместе аналитик, разработчик и тестировщик и разбирают задачу каждый со своей точки зрения. Не менее важно тестирование требований, которое выявляет разночтения и двусмысленность задачи. На всем этом я здесь подробно останавливаться не буду - это есть в любимой мной “библии” istqb.
Здесь я хочу акцентировать внимание на следующем шаге - когда тестировщик, грубо говоря, проектирует тесты. На этапе раздумий прикидывайте, есть ли в задаче общие блоки, которые можно переиспользовать в других тестах с похожей функциональностью (или взять из уже написанных тестов). Это здорово ускорит работу.
Ищи баланс точности и простоты. Автоматический тест, проверяющий кейс в деталях, сложен. Его поддержка требует больше усилий.
В высокоуровневом автоматическом тесте очень много деталей. Но чем он более сложный, тем у него короче жизненный цикл. Тестируемые нами сервисы меняются постоянно. Допустим, еще вчера мы в базу вводили значение без форматирования - десять тысяч писалось без пробела. А сегодня мы ввели форматирование - между десяткой и тремя нулями появился пробел. Тест, проверяющий точное совпадение со значением в базе, начнет падать. Так происходит всегда: более точные проверки обладают максимальной хрупкостью.
Проверять совпадение в деталях - хорошо. Мы сразу видим, если есть ошибка и какого она рода (в идеале). Но скорее всего в такие тесты усилий будет вложено много, но довольно быстро они станут бесполезными. Проверять более высокоуровневые вещи проще - в большинстве случаев такие тесты проживут дольше, хотя и находить будут только совсем существенные баги.
Вот наглядный пример: допустим, в базу у нас попадает значение - “10000 руб.” - и нужно его проверить. В некоторых задачах достаточно проверить только тип этого значения, но не точное совпадение. С точки зрения такого теста и “10000 руб.”, и “10 000 руб.” - один и тот же результат (строка). Это своего рода компромисс. Если такой тест упадет, мы увидим, что что-то глобально поломалось. Однако можем не заметить мелкую ошибку (например, что вместо “10000 руб.” в базу попало “11 000 руб.”. И здесь важно понимать бизнес-задачу. В том проекте, где я сталкивался с подобным примером, стоимость небольшой допущенной ошибки для бизнеса была меньше, чем цена задержки выхода обновления. Так что ради ускорения доставки продукта действительно стоило идти на такие упрощения.
Для проверки совпадения значения тест пришлось бы усложнить, чтобы брать откуда-то ожидаемый результат. Плюс это усложнило бы поддержку теста - как только разработчики что-то изменят в сервисе, придется переделывать эту логику и в тесте. При этом исправить ожидаемый тип (если он вдруг изменился) гораздо проще, чем заново искать источник ожидаемого результата. Так мы получаем экономию на поддержке теста.
Откажитесь от перфекционизма. Проект готов тогда, когда он выполнен на 80%. Помните о бизнес-value. Соотносите с затратами ресурсов.
И снова я о балансе между тем, как хочется сделать (перфекционизмом), и тем, в каком виде нужно отдать.
Есть люди, которые до последнего пытаются выполнить задачу. Это не всегда идет на пользу команде. Как известно, 20% усилий дают 80% результата. Дальше уйма усилий может уходить на решение каких-либо не очень-то значимых вопросов - не принципиальных вещей, не имеющих значение для бизнеса.
Не надо писать тесты в соответствии с некой “идеальной идеологией” и тратить усилия на то, чтобы вся команда была с этим согласна. 100% покрытия - это недостижимая штука. Снова повторю: следует понимать, что нужно бизнесу… Сколько стоит исполнение их требований, а также в какое количество ресурсов (времени созвонов на 5 человек и т.п.) обойдется перевыполнение этих требований. Стоит ли оно того?
Метрики тестирования - это далеко не всё. В конечном итоге решения принимает бизнес (деньгами).
Некоторые тестировщики пытаются зарыться в цифры. Особенно этим страдают неопытные - добиваются максимального покрытия, закрывают численно больше кейсов и т.п. Но одновременно с этим страдают другие параметры - сроки доставки продукта, ресурсы, необходимые на поддержку тестов и прочее (о чем уже говорили выше). Старайтесь увидеть полную картину, причем, именно со стороны бизнеса. Метрики - это, безусловно, хорошо, но система метрик не идеальна, она может не соответствовать бизнес-задаче.
Вместо заключения
Все, что я здесь рассказал, касается в первую очередь того, как построена коммерческая разработка. Для развития на пути тестирования рекомендую погрузиться немного в бизнес - в понимание продукта и его жизненного цикла.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.
