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

Денис Гордиенко, руководитель 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": false, "is_ugc": true, "date": "Sun, 28 Jul 2019 19:42:55 +0300" }
{"average":26592,"one":95,"ten":75}
Сколько денег вы откладываете в месяц?
Ответьте и узнаете, сколько копят другие.
0 ₽
70 000+ ₽
0 ₽
{ "id": 77173, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/77173\/get","add":"\/comments\/77173\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/77173"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 235819, "last_count_and_date": null }
4 комментария

Популярные

По порядку

3

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

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

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

Ответить
1

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

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

Ответить
1

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

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

Ответить
1

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

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления
{ "page_type": "default" }