Цена ошибки в IT-проекте: как экономия на тестировании приводит к повышенным тратам

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

Любые некорректно работающие интеграции с внешними сервисами, ошибки сохранения и передачи данных или неправильный расчёт скидки по программе лояльности в интернет-магазине, всегда дешевле найти и исправить до запуска в продакшн. Иначе экономия на тестировании может вылиться запятнанной репутацией и финансовыми потерями. Из этой статьи вы узнаете, почему вам выгодно платить за QA при заказе веб-разработки, и чем рискуют те, кто сотрудничает с игнорирующими важность тестирования командами.

QA-инженер отвечает за качество на протяжении всего жизненного цикла программного продукта: сайта, сервиса, интернет-магазина. Его работа начинается с проверки технического задания и продолжается на протяжении всего цикла разработки и поддержки.

Метрики оценки качества и сценарии для тестирования тоже пишет QA. Причем то, что на ранних этапах работы отнимает много времени, в перспективе его экономит.

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

Отказ от тестирования на ранних этапах — классический пример экономии на тестировании, в перспективе приводящей к удорожанию разработки и обслуживания сайта.

Представьте, что вы заказали разработку интернет-магазина и утвердили техническое задание. Когда половину уже сделали, оказалось, что есть проблема: согласованный сервис для чата на сайте закрылся и интегрировать его не получится. Выбрали другой, подключили, продолжили, но снова уперлись в потолок — новый сервис не дает данных для формирования отчетов о работе службы поддержки. Снова нужно искать компромисс.

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

Тестирование готового продукта — само собой разумеющееся. Но и его надо проводить не только перед релизом. Контроль качества в грамотно выстроенном процессе разработки и поддержки сайта ведется параллельно работе программистов и дизайнеров: пока одни что-то делают, другие непрерывно проверяют результат.

Представьте, что компания сначала выпустила миллион смартфонов, и только потом наняла специалистов для тестирования устройств. Если найдут ошибку, придётся всё переделывать. Это риск ценой в миллиарды долларов.

В веб-разработке всё так же, как в производстве любого продукта: чем раньше начали тестировать, чем меньше нужно переделывать, что очевидно делает запуск дешевле.

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

Тестирование и разработка — не одно и то же. Если сильно упростить, тестировщик должен видеть продукт глазами пользователя, а разработчик — «глазами» компьютера. Поэтому специалист по QA с большей вероятностью обратит внимание на то, что невозможно заметить при реализации.

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

Тестирование дешевле разработки и если же заложить тестирование функциональности и кода в оплату труда программиста, расходы только вырастут.

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

Смысл регрессивного тестирования в том, чтобы убедиться, все ли продолжает работать после того, как в проекте что-то поменялось. Простой бытовой пример регрессивного тестирования — приготовление супа. Готовящийся суп пробуют после добавления каждого ингредиента: посолили — попробовали, добавили картошку — попробовали, добавили поджарку — попробовали, и т. д. Если не пробовать и не скорректировать курс — досолить, убавить огонь и пр., — результат получится не таким, как планировалось. В веб-разработке так же.

Зависимости между компонентами сайта могут быть неочевидными. Поэтому лучше перепроверять всё, что критично, после внесения любых изменений.

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

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

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

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

Описание тест-кейсов и чек-листы помогают увидеть закономерности, зависимости, которые можно автоматизировать или упразднить. Это особенно актуально, когда проект большой и над ним работает команда тестировщиков. Но даже когда QA-инженер справляется сам, документация помогает ему строить дорожную карту, расставлять приоритеты, действовать более гибко и тем самым экономить деньги владельцу проекта.

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

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

Еще больше полезной информации читайте на нашем сайте.