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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#баги