Колонки

Как тестировать все разработки и что делать для предотвращения ошибок

Колонки
Игорь Ниточкин
Игорь Ниточкин

Руководитель агентства тестирования Qualitica (ГК Digital Hub)

Виктория Сафронова

Когда Джефф Безос только запустил 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. Проводите ротацию внутри отдела. У рядовых сотрудников тоже замыливается глаз — старайтесь менять их или агентство каждые 1,5 года, оставляя только ключевых игроков.
  2. Подключайте тестировщика к команде. Если разработчики работают с ним в паре, то он будет в курсе всего процесса, а вы сэкономите время и деньги на дополнительные исследования.
  3. Помните — выкатывать релиз можно только после тестирования всех функций продукта. Оставьте за тестировщиками право остановить релиз, если необходимо. И не спешите — лучше перенести, чем потом отмываться.
  4. Следите, чтобы релиз протестировали и по позитивному, и по негативному сценарию. Именно на последнем все чаще всего ломается и слетает.
  5. Тестируйте продукт каждый месяц. Это быстро и просто! Если что-то сломалось по причинам, которые от вас не зависят, вы быстро обнаружите ошибку и минимизируете потери.

Фото: Roman Samborskyi / Shutterstock

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 MVP для стартапов: почему нельзя пренебрегать и с чего начать разработку
  2. 2 Карьера в тестировании. С чего начать?
  3. 3 B2B-диалог в IT-сфере: 3 причины протестировать продукт вашего клиента
EdTech: карта российского рынка
Все компании и инвесторы в области образовательных технологий
Перейти