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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но все равно получить 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