«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?

Представьте мир, где все сайты работают неправильно: формы не заполняются, оплата не проходит, а товары не добавляются в корзину. Именно таким бы был интернет, если бы на страже качества не стояли тестировщики. Рассказываем о том, откуда берутся баги, на каком этапе их начинают фиксить и почему получить 100% чистый продукт все равно не получится.

Откуда берутся баги

На 31 декабря 2022 года в Интернете было более 1.97 миллиарда различных сайтов. У многих из них сложная структура и интеграция с другими сервисами, что в разы увеличивает количество проверок, которые нужно провести перед тем, как запустить проект. Чем сложнее структура сайта, тем выше вероятность появления ошибок при взаимодействии элементов между собой.

Снизить их количество можно, выделяя больше ресурсов на тестирование. Но бесконечно вылавливать ошибки и полировать код не выход. Иначе на момент запуска проект может оказаться невостребованным.

С другой стороны, если количество допустимых ошибок превышает критический уровень, это указывает на то, что:

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

Ситуация 1. У клиента мало денег → приходится жертвовать качеством, чтобы выпустить хотя бы что-то → заработать на этом денег → выпустить обновления с исправленными ошибками.

Ситуация 2. У клиента много денег, но мало времени (особенно характерно для игровой индустрии и высококонкурентных рынков). И здесь важно успеть выпустить свой продукт до того, как это сделают конкуренты.

Поэтому когда стоит выбор — запустить продукт с ошибками и занять рынок, либо полировать код и в итоге запустить продукт, когда потребность в нем исчезнет, лучше выбрать первое.

Особенности тестирования продукта в экспертной студии

Время тестирования зависит от сложности и «критичности» продукта. Это может быть и 5% от времени разработки, и 300-400%. Если брать проект средней сложности, то выйдет примерно 20% от верстки и 30% — от этапа программирования. Об этом мы рассказывали, когда подсчитывали стоимость этапа на примере сервиса Яндекс.Такси. Рассмотрим, что входит в этот этап и почему он занимает столько времени.

Когда начинаются тесты?

Тестировщики начинают работать тогда, проект поступает в работу. Мысль о том, что они подключаются только на этапе программирования, в корне неверная. Чем раньше QA-специалисты начнут работать, тем меньше времени уйдет на исправления.

В идеале тестирование сайтов и приложений должно проводиться на каждом этапе разработки, даже когда проект существует только на бумаге (в нашем случае в ТЗ). О том, что проверяется, расскажем ниже.

Тестирование на этапе аналитики

Работать с проектом мы начинаем уже на этапе аналитики. Проводим «‎тестирование»‎ технического задания и бэклога: проверяем их на логические ошибки, смотрим, насколько корректно описаны функции

Юрий Витовтов, тестировщик Pyrobyte

На этом этапе тестируется ТЗ. Делать это нужно по нескольким причинам:

  • Оно помогает выявить функции, описание которых может оказаться недостаточным или непонятным для программиста;
  • Сокращает количество ошибок в тексте ТЗ;
  • Еще на этапе написания ТЗ появляется возможность увидеть потенциально проблемные места и заранее продумать их реализацию.

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

<p>Чтобы требования заказчика соответствовали видению разработчика, тестировщики вычитывают ТЗ</p>

Чтобы требования заказчика соответствовали видению разработчика, тестировщики вычитывают ТЗ

Тестирование прототипа и дизайна

Следующим этапом становится тестирование прототипа и дизайна. На данном этапе оцениваем UI/UX интерфейса и пользовательский путь. И, что немаловажно, проверяем, чтобы на всех экранах совпадало расположение блоков.

Юрий Витовтов, тестировщик Pyrobyte

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

Итогом этого этапа становится дизайн, который одинаково красиво смотрится и в разных браузерах, и на разных устройствах.

Тестирование кода и верстки

Для проверки соответствия верстки дизайну используется плагин PerfectPixel. Если не проконтролировать этот момент, могут возникнуть несоответствия в:

  • Шрифтах. В разных браузерах они могут отображаться по-разному. Где-то тоньше, где-то жирнее. В итоге при верстке в браузере шрифт может отличаться от того, который был согласован в макете;
  • Макете. Например, съехавшие изображения или иконки, разная толщина границ или форматирование текста и т.д.
«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?

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

Есть поговорка — «это не баг, а фича». Если найденный баг не был задуман разработчиком, то фичей он вряд ли станет.

Юрий Витовтов, тестировщик Pyrobyte

Методы ручного тестирования

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

Так выглядит баглист
Так выглядит баглист

Существует множество различных методов и приемов, с помощью которых можно проводить ручное тестирование. Ниже приведены самые распространенные.

1. Тестирование белого ящика

Тестировщик работает с кодом, написанным для конкретной функции. Здесь важно понимать, как пишется код и что он делает. Главная цель этого метода — проверить все ответвления решений, операторы и циклы в коде.

«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?

Если для примера взять функцию «создать учетную запись», то при проверке «белым ящиком» тестировщик обязательно проверит, какие «ответы» системы прописаны на введение правильных и неправильных символов, пустые поля в форме. Оценит то, как написан и структурирован сам код, нет ли в нем незавершенных циклов, незакрытых функций и прочих несостыковок

‍2. Тестирование черного ящика

Используется, когда нет сведений о внутренней работе системы, и специалист проверяет вывод на основе ввода. Если результат соответствует ожидаемому, то тест пройден.

На примере той же опции:

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

3. Тестирование серого ящика

Это микс «белого» и «черного ящика». При тестировании серого ящика специалисту не обязательно иметь доступ к исходному коду. Вместо этого используются знания об архитектуре, алгоритмах и внутренних состояниях программы. ‍

Виды тестирования

1. Дымовое тестирование (Smoke testing или проверочное тестирование)

То есть тестирование оборудования при первом включении. Тест должен подтвердить или опровергнуть правильность выполнения ПО своих основных функций перед его передачей на более глубокое тестирование. Если ничего не загорелось и дым не идет — тест считается пройденным.

«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?

2. Приемочное тестирование

Последний этап. Проводится на этапе передачи продукта клиенту. Задача — убедиться, что функционал продукта соответствует потребностям и требованиям заказчика.

Какие еще виды тестирования может проводить студия?

Для снижения количества ошибок студии могут прибегать к дополнительным методам. Это может быть тестирование проекта контрольной группой (бета-тестирование) и проведение код-ревью внутри команды.

1. Тестирование контрольной группой (бета-тестирование)

Выполняется «реальными пользователями» сервиса в «реальной среде». Бета-версия предоставляется ограниченному числу пользователей для получения отзывов о качестве продукта. Это снижает риски сбоев и обеспечивает повышение качества за счет сбора обратной связи.

Обычно бета-тестирование сайта строится по 3-м направлениям:

  • Проверка по сценариям, предусмотренным разработчиками;
  • Проверка «наивным» пользователем без погружения в описание продукта;
  • Проверка по нестандартным сценариям.

2. Код-ревью (Code Review)

Это процесс проверки и анализа кода. Тест проводит программист, который не работал над задачей. Результатом является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу.

«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?

Плюсы код-ревью:

  • В случае, если один из разработчиков покинет проект, его задачи смогут подхватить другие программисты, так как они были знакомы с кодом. Это обеспечит бесперебойную разработку проекта со стороны студии;
  • Помогает выявить баги. Так как задача сразу проверяется как минимум двумя разработчиками, это повышает вероятность нахождения упущенных ошибок;
  • Повышается читаемость и качество кода. Он будет понятен не одному человеку, а нескольким участниками команды. Это упростит и ускорит разработку в будущем.

Сколько ресурсов требуется на тестирование

Для того, чтобы протестировать одну форму, нужно несколько вариантов проверки на нескольких платформах, в результате это выливается во время.

Сколько ресурсов требуется для тестирования формы заполнения платежных реквизитов?

Считаем:

— 3 основных платежных системы (Visa, MasterCard и Мир);

— 3 вида ОС (Windows, macOS, Android);

— 3 варианта платформ (Декстоп, планшет, смартфон);

— 4 основных браузеров (Google Chrome, Internet Explorer, Opera, Safari).

Как итог, чтобы протестировать одну форму, только по этим критериям получим как минимум 108 различных сценариев. А если таких форм больше, а платежных систем не 3, а 23, как было, например, в нашем кейсе по созданию обменника, то количество вариантов сценария стремится к бесконечности.

Именно поэтому как все скороговорки не перескороговорить, так и все баги не выловить.

Заканчивается ли тестирование после того, как продукт запущен?

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

Вспомните компьютерные игры последних лет, например, Cyberpunk 2077. Большинство пользователей критикуют не сюжет или персонажей, а именно баги. Пользователи, совершая неявные действия, находят ошибки, которые не были выявлены опытным путем.

Насколько бы хорошо продукт не был отшлифован, пользователи найдут баги в любом случае.

«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?

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

Но все равно получить 100% чистый продукт не получится. Чем крупнее проект, тем больше вероятность пропустить мелкие, неочевидные ошибки. Нужно принять это как данность, поскольку некоторые баги могут возникать не со стороны разработчика, а, например, со стороны сервисов, с которыми настраивается интеграция ¯\_(ツ)_/¯

Если кому-то интересно, как выглядят наши чек-листы по тестированию в Пиробайт, кликайте сюда :)

Если статья была для вас полезна, не забывайте ставить лайки и оставлять комментарии.

Чтобы не пропустить интересное, следите за нами:

На нашем сайте

Вконтакте

Телеграм-канале

Если у вас есть задача разработать сайт или мобильное приложение, то напишите в Телеграм, мы это обсудим: https://t.me/sashadzen

Заказать разработку сайта, веб-сервиса или мобильного приложения на нашем сайте: https://vk.cc/cuglQZ

Партнерская программа, где мы платим от 10 000 до 200 000 рублей за контакты тех, кому нужен дизайн или разработка: https://vk.cc/cuglXT

Телеграм-канал Саши Комбарова про управление агентством, проектами, людьми: https://t.me/sasha_kombarov

Телеграм-бот, который бесплатно выдает чек-листы, памятки и регламенты по управлению, маркетингу, аналитике, дизайну и разработке: https://t.me/regulations_pyro_bot

4545
75 комментариев

Комментарий недоступен

12
Ответить

Я сюда захожу не для того, чтоб грустить

2
Ответить

точно

Ответить

Решили на больное надавить)

Ответить

это последствие аджайла и скрама.

2
Ответить

В скраме ничего нет про «делай плохо by design», там про «делаем маленькими шажками». Пример: делаем ресторан в перспективе, но сначала открываем палатку с едой. Ее можно сделать плохо и хорошо. Шансов «сделать хорошо» при таком подходе больше. После прокачки опыта переходить к следующей форме торговли едой. Идея: выбирать промежуточные цели соизмеримые с опытом. Делать плохо на каждом этапе развития никто не заставляет.

5
Ответить

Скорее наоборот, аджайл и скрам помогают уменьшить их количество

1
Ответить