Разработка
Денис Гордиенко
2449

Как мы поменяли этап тестирования в разработке приложений

Денис Гордиенко, руководитель Bright Mobile, о том, какие изменения внесли в тестирование мобильных приложений.

В закладки

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

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

Чем больше итераций в формате «нашли ошибки — исправили — отправили снова проверять», тем больше накаляются эмоции. Со стороны заказчика это выглядит так: криворукие программисты не могут исправить свои же косяки, а со стороны программиста: заказчик не может сесть и сразу всё проверить, прислав единый баг-лист по проекту.

Можно зайти на Fl.ru и увидеть, как много объявлений в формате «проект сделан на 90%, надо допилить». Эти объявления — следствие того, что в какой-то момент разработчик и заказчик не смогли договорится и расстались с неприятным осадком.

По подписке не договорились

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

Как проходит тестирование в большинстве команд

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

Обычно разработка приложения выглядит так:

  1. Выполнение — непосредственно создание приложения.
  2. Самопроверка — программист проверяет за собой и исправляет баги, которые увидел, в студиях ему помогает менеджер проекта.
  3. Проверка клиентом — клиент при приёмке сам проверяет приложение и, если нашёл пропущенные баги или отклонения, сообщает об этом.

Клиент ставит себе приложение, находит еще ошибки, программист исправляет, и так в несколько итераций приложение доводится до итогового варианта. Задача менеджера проекта — максимально сократить количество этих итераций, в идеале сведя к приёмке без багов.

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

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

ДМБ

Как решают проблему крупные проекты

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

Большие проекты вроде Авито, YouDo используют автотесты и внедряют стандарты качества.

Автотесты — это штука хорошая и правильная. Если дилетантски объяснять — создаётся подпрограмма, которая проверяет типичные и нетипичные варианты использования основного приложения.

Применима, когда один проект разрабатывается годами в agile-формате, то есть идёт постоянный поток задач и релизы выпускаются по календарному плану.

Однако большинство заказчиков видят работу над своим приложением проектно, то есть «начали, сделали, сдали, а нужно будет что-то дорабатывать или нет, это ещё вопрос». Позиция спорная, но аргументы в её защиту есть, поэтому принимать нужно как данность.

Автотесты при таком подходе слабо применимы. Смысл писать дополнительную программу для проверки, если непонятно, будут ли вноситься изменения?

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

Соответственно, для тестировщиков пишутся регламенты — что проверять, как и что делать в той или иной ситуации.

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

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

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

К чему пришли мы

Мы нашли интересное решение довольно случайно. Как всегда, оно пришло из суровой практики, а не из теории ведения проектов. Наш ведущий разработчик наткнулся на задние на Fl.ru, где нужно было сделать ревью приложения на Ionic.

Он посмотрел приложение, написал список багов (тот самый список, который я обещал в начале статьи):

  1. Необходимо исключить папку plugins из репозитория

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

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

  4. Проект невозможно поднять из исходников: не хватает части библиотек
  5. Вынести обработку данных в компонентах или страницах в сервисы и провайдеры, чтобы при изменениях код корректировался в одном месте, а не в разных частях приложения.

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

Выделять в студии ведущего программиста на то, чтобы он проверял правильность кода, дорого. Мы нашли альтернативное решение.

Найденные ошибки можно логически описать и внедрить в IDE (среда разработки, в которой пишется приложение), чтобы сама система ещё на момент написания кода запрещала программисту поступать неправильно.

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

{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": ["\u0431\u0430\u0433\u0438"], "comments": 4, "likes": 12, "favorites": 23, "is_advertisement": false, "subsite_label": "dev", "id": 77173, "is_wide": true, "is_ugc": true, "date": "Sun, 28 Jul 2019 19:42:55 +0300", "is_special": false }
Объявление на vc.ru Отключить рекламу
0
4 комментария Накачай стартап
Популярные
По порядку
3

Автотесты увеличивают стоимость проекта на 30% - серьезно?
Мне просто интересно, как вы это посчитали.

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

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

Ответить
1

Не хочу вступать в полемику. Напишите сколько на Ваш взгляд добавляет автотест к бюджету? Мы считали пропорционально времени на написание автотеста.

И какой видите объективный подход к тестированию приложения с бюджетом до 500 т.р.?

Ответить
1

С бюджетом в 500 тысяч рублей за все приложение - тестить самому или нанять асессора на удаленку/фриланс, написав ему чек-лист. Автотесты это все же энтерпрайзное решение для больших проектов, в такой бюджет никак не вписать. Не думаю что они в таком случае экономически оправданы

Если брать классический случай, когда автотестами занимается 1-2 QA в команде из нескольких десятков человек + время от времени 1 девопс, выходит довольно небольшая сумма

Ответить
1

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

Ответить

Комментарии

null