Когда Джефф Безос только запустил Amazon, он выкатывал обновленные релизы так часто, что не успевал их тестировать. На маркетплейсе тогда можно было даже заработать — при вводе в поле заказа отрицательного количества товаров деньги не списывались, а наоборот, зачислялись на карту.
Сейчас компании выпускают сайты, ПО, CRM и приложения. В каждом из этих цифровых продуктов могут быть дефекты — как незначительные, так и те, на которых вы можете потерять деньги. Игорь Ниточкин, руководитель агентства тестирования Qualitica (входит в ГК Digital Hub), объясняет, как одна ошибка может стоить сотни тысяч рублей, зачем проверять каждую кнопку и что делать, чтобы ничего не ломалось.
Как тестировать все разработки и что делать для предотвращения ошибок
Виктория Сафронова
Дефекты: какие бывают, откуда берутся и почему из-за них можно потерять деньги
Можно выделить два вида дефектов — frontend-дефект и backend-дефект. Первый дефект обычно видно — это ошибки визуальной части программного продукта вроде съехавшего текста или криво расположенных кнопок. Он же может возникнуть из-за неверной логики работы. Второй дефект нельзя увидеть, но можно обнаружить на этапе взаимодействия с продуктом. Например, вы нажимаете на кнопку «купить», переходите в корзину, а она пустая — товар туда не добавился.
Почему ошибки вообще возникают? И те, и другие появляются из-за невнимательности разработчиков и тестировщиков, сломанной логики работы, сжатых сроков для тестирования или непроработанных требований заказчика. Разработчики могут пропустить ошибку и не проверить, как продукт работает на разных браузерах, а тестировщики — уделить проверке недостаточно времени.
Несколько ситуаций, при которых возникают ошибки
1. Разработчик выкатывает релиз в спешке
Он физически не успевает отдать релиз тестировщику на проверку, потому что должен был выкатить его еще вчера. В итоге он делает «костыль» — временное, слабое решение, которое выкатывает и не переделывает. Потом на такое решение нагружают дополнительные функции, с которыми оно не справляется. Тогда ломается все и разом.
2. Сотрудники работают без структуры и логики
Разработчики и тестировщики должны работать по заранее выстроенным процессам. Тестировщики, например, должны знать, когда им начинать тестировать, когда закончить, как проверять функции. Если логика нарушена, а в работе нет последовательности действий, релиз выйдет с ошибками.
3. У команды замылился глаз
Сотрудники, которые работают над одними и теми же задачами, теряют интерес и сталкиваются с эмоциональным выгоранием. Это распространено в IT-сфере и сказывается на качестве конечного продукта. Этим чаще страдают команды in-house — они делают одно и то же уже в тысячный раз, работая над похожими проектами внутри одной компании. Такие команды часто пропускают мелочи, на которых можно прогореть.
4. Разработчик проверяет продукт только по позитивному сценарию
Позитивный сценарий — это логичное поведение пользователя на сайте. К примеру, вы зашли на сайт магазина одежды, задали в фильтре категорию «куртки и пальто» с ценой «от 5000 до 15 000 рублей», выбрали товар, добавили в корзину и оплатили. Но что будет, если вы введете в поле с ценой отрицательное значение? Или набьете цифру буквами? Это негативный сценарий — нестандартные действия пользователя — который редко отрабатывают. В идеале, функция не должна сработать и система предупреждает пользователя об этом. Но на практике все либо ломается, либо, как в случае с Amazon, вы еще и деньги теряете.
5. Продукт написан junior-разработчиком
Исполнители тоже бывают разные. Например, senior-разработчик — это профессионал с опытом, который уже набил шишек. Такой проверит код, исправит дефекты, посмотрит frontend- и backend-составляющие, определит, справляется ли продукт с нагрузкой и рассчитает, на какой трафик рассчитаны серверные мощности. А за junior-разработчиком код нужно проверить.
Многие компании и сами это понимают. Недавно к нам обратился клиент, у которого в штате есть и разработчики, и тестировщики. Команда очень старалась, но не дотягивала по компетенциям. Разработчики сделали продукт с дефектами, а тестировщики проверили только позитивный сценарий. Как и предполагал клиент, мы нашли множество ошибок, которые мешали пользователю.
Почему вы вообще должны вникать в это? Процесс автоматизации бизнеса становится все масштабнее. Если вы продаете товары в интернете, рассчитываете заработать на своем приложении или гоните трафик на сайт, то рискуете:
потерять пользователей
Тестирование нужно, чтобы вы не могли выкатить на пользователей сырой продукт. Если вы сделали сайт для Mac OS, но забыли о пользователях на Windows, то уже потеряли клиентов. И потеряли многих – на Windows пользователей больше, чем на Mac OS. Они тоже хотят пользоваться вашими продуктами и покупать товары. Клиенты, которых «отбрили» при первом же касании, не дают второго шанса.
потерять продажи
Цифровые продукты постоянно обновляются. Например, вы запустили интернет-магазин, а затем решили добавить в корзину функцию множественной покупки. Если сделать это через «левое» решение и не проверить его, корзина сломается. Человек не сможет купить товар, конверсия упадет, а вы потеряете деньги.
Это распространенный пример. Однажды к нам обратился известный интернет-магазин мебели – в команде поняли, что резко стали терять конверсию в продажи. Пользователи добавляли товары в корзину, но до оплаты дело не доходило. Причина? Ошибка в оплате – пользователь технически не мог оплатить заказ с карты.
потерять результаты продвижения
Стартапы с бюджетом делают PR под запуск продукта. Это бессмысленные траты, если пользователь зашел к вам и не смог воспользоваться основными функциями. Можно мощно запуститься, пропиариться, а пользователи напишут, что у вас ничего не работает. Лучше сразу делать хорошо, чем отмываться и обещать исправить ошибки.
Куда бежать, если все сломалось
Если вы регулярно выпускаете цифровые продукты, нужно отлаживать процесс тестирования. Но чтобы свести потери к минимуму «в моменте», нужно сразу проверять ошибки. Для этого:
1. Обратитесь к тестировщикам
Например, к агентству на подряде или сотрудникам in-house. Если в вашем отделе разработки и тестирования происходят регулярные кадровые ротации хотя бы раз в 1,5 года, у сотрудников не замыливается глаз, а значит, можно обратиться к своим. Если же ваша команда проваливает каждый релиз, подыщите агентство.
2. Закажите исследовательское тестирование
Это моя личная рекомендация – с такого исследования наши тестировщики начинают погружение в продукт, чтобы потом полноценно влиться в работу команды. Если тестировщики не знают проект, это исследование даст им полную картину. Хорошо, если у продукта есть проектная документация – тестировщикам будет проще. Если нет, они будут тестировать продукт и описывать пользовательские сценарии – как позитивные, так и негативные. По сути, они заново создадут тестовую документацию или актуализируют существующую.
3. Получите отчет об ошибках
Это bug-report – документ, в котором тестировщики пропишут все ошибки и их возможные причины. Если вы ни слова в нем не понимаете, его расшифруют и расскажут, что не так и почему.
4. Подключите тестировщиков к команде
Именно они выявляют, что у вас не работает и почему, и смогут подсказать разработчикам нужное решение. Если тестировщики будут в курсе дела, то быстрее проверят исправленное. Создание цифрового продукта – это цикл, который состоит из разработки и тестирования. Не ломайте логику и привлекайте тестировщиков сразу, чтобы они отрабатывали каждую задачу по ходу всего процесса.
5. Проведите smoke-testing
Это проверка основного функционала продукта сразу после того, как релиз «пошел» в бой. В ходе smoke-тестирования команда отрабатывает позитивный и негативный сценарий и проверяет работу ключевых действий пользователя – «купить, настроить фильтр, оплатить».
Как сделать продукт, который не сломается
Идеальный цифровой продукт без ошибок сделать сложно. Мелкие и незначительные, они будут даже у профессиональных разработчиков. Это не критично — текст, который наехал на картинку во второстепенном разделе, заметят 2% посетителей и тут же об этом забудут.
Чтобы вы спокойно выкладывали релиз с работающим функционалом, не ждали сюрпризов и не чинили что-то в огне, нужно:
Выстроить рабочий процесс тестирования
Такой, при котором выпуск продукта будет невозможен без его утверждения со стороны тестировщиков. Ни одна задача, которую выполнили разработчики, не должна оставаться без тестирования. Поймите — если вы выкатываете релиз «не глядя», то соглашаетесь на кота в мешке. Это огромный риск, потому что вы не знаете, как все будет работать. Настройте пошаговый процесс разработки и тестирования, чтобы такого никогда не было. Даже если и team lead, и разработчик в один голос убеждают вас, что «можно выкатывать».
Составить стратегию тестирования
Она нужна, чтобы команда понимала — если не проверить каждую задачу, релиза не будет. Эти проверки должны заканчиваться регрессионным тестированием, в ходе которого все выполненные задачи собирают вместе и тестируют продукт целиком. По сути, команда проверяет собранный релиз. На этом этапе тестировщики почти всегда выявляют ошибки, ведь проверяют не отдельные задачи, а всю систему с объединенным функционалом.
Дефекты на этапе регрессионного тестирования — это ошибка тестировщика. Он должен был найти их раньше, а не прямо перед релизом. Главное — у тестировщика должно быть право перенести релиз, если в нем есть дефекты. Да, это проблема, и да, вы отстанете от плана. Но хуже, если он не сможет остановить выпуск. Тогда ваша команда выкатит продукт, который публично сломается в обозримом будущем.
Проводить smoke-тестирование
И делать это хотя бы раз в месяц. Это оперативная и несложная проверка, которую можно и нужно автоматизировать. Дело в том, что иногда все ломается и без нашего участия.
Представьте, что вы сделали продукт под Internet Explorer 11 — последнюю версию браузера от Microsoft. А завтра выйдет Internet Explorer 12, и в нем будут совсем другие алгоритмы. Если обновление произошло в фоновом режиме, все сломается и вы даже не узнаете об этом.
Именно для этого и нужно smoke-тестирование — проверять основу, даже если все работает и ты давно ничего не менял.
Если вы разрабатываете цифровые продукты:
Проводите ротацию внутри отдела. У рядовых сотрудников тоже замыливается глаз — старайтесь менять их или агентство каждые 1,5 года, оставляя только ключевых игроков.
Подключайте тестировщика к команде. Если разработчики работают с ним в паре, то он будет в курсе всего процесса, а вы сэкономите время и деньги на дополнительные исследования.
Помните — выкатывать релиз можно только после тестирования всех функций продукта. Оставьте за тестировщиками право остановить релиз, если необходимо. И не спешите — лучше перенести, чем потом отмываться.
Следите, чтобы релиз протестировали и по позитивному, и по негативному сценарию. Именно на последнем все чаще всего ломается и слетает.
Тестируйте продукт каждый месяц. Это быстро и просто! Если что-то сломалось по причинам, которые от вас не зависят, вы быстро обнаружите ошибку и минимизируете потери.
Источник: