Организация процесса тестирования с нуля в 1С и почему часто проекты 1С обходятся без него

Всем привет!

Мы много лет занимается проектами 1С. В нашей команде специалисты с большой экспертизой, которые, кроме досконального знания своего дела, могут рассказать немало поучительных историй из своего профессионального опыта. Вот одна из них. Речь пойдет о выстраивании тестирования в вокрфлоу продукта 1С, в котором отдела тестирования никогда не существовало.

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

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

Итак, начнем...

Почему обходятся без отдела тестирования? Есть несколько вариантов:

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

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

Наверное, это главный ответ, почему на проекте, просуществовавшем более 3 лет, не было тестирования. До, так сказать, «пришествия» коллеги в проект, релизы в команде выходили 2 раза в неделю с пулом задач более 10 штук. Что было супер быстро, как ему казалось, исходя из предыдущего опыта работы на проектах с двухнедельными спринтами. Но опять же это Agile, и, как водится, все везде у всех по-разному «гибко».

И вот коллега разгребает накопившийся бэклог из новых фич, параллельно пытаясь наполнять TMS-ку кейсами для регресса тестов. Успевает полностью протестить на предпродном стенде N-е количество задач, как прибегает ПМ с просьбой «взять задачу в приоритет №1, ибо она очень критичная и заказчик хочет ее прямо сейчас».

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

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

В итоге, после совещания с лидом, было принято решение взять еще одного тестера. Изначально на проекте работал один тестер на 4 разработчика. Идеальное соотношение – 1 тестировщик на 2 разработчика, ну или хотя бы 1 к 3. Так как планировалось взять еще одного разработчика, то очевидно, что требовался дополнительный тестер.

Взяли нового тестера, заонбордили в команду и дело начало потихоньку спориться. Два тестера на 5 разработчиков – это уже более-менее приемлемо по скорости разгребания бэклога. Но одновременно появились трудности с инфраструктурой — было всего 2 тестовые базы и 1 предпродная. Деплоили поштучно веточку с фичей на тестовую базу, однако процесс все равно изрядно затягивался.

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

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

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

Разумеется, человек привыкает ко всему. Прошло время и тестеры окончательно интегрировались в проект. В течение года командой тестирования было найдено более 300 багов/саб-багов. Средняя стоимость ошибки, найденной на этапе тестирования, колеблется от 100 до 1 000 долларов в зависимости от сложности исправления и контекста проекта. Получается, что работа тестеров позволила сэкономить/заработать солидную сумму даже с учетом усреднений.

Вот такой получился опыт: долго, непросто, местами даже слишком «Agile» — но зато теперь мы точно знаем, что даже если проект 1С изначально обходится без тестирования, грамотно построенный процесс в итоге спасает кучу денег, нервов и времени. А если заодно ещё показать заказчику, как именно это тестирование работает на его пользу — получается двойная выгода.

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

Да, в Agile всё зависит от конкретного проекта, но есть несколько общих шаблонов, которые помогают стартовать. И для нас лично этот проект стал поводом сформулировать следующие пункты:

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

Да, у каждого проекта свои особенности, и «идеальной» схемы нет. Но стоит отталкиваться от проверенных шаблонов и адаптировать их под себя. Мы, к примеру, поняли, что грамотное масштабирование тест-команды (1 тестировщик на 2–3 разработчика) и адекватное планирование релизов спасают от «снежных комов».

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

Мы можем настроить релизный цикл и поддержать непрерывное тестирование, особенно если речь идёт о критичных бизнес-процессах.Мы часто беремся за сложные и «нестандартные» проекты на 1С, где готовые методики могут не подходить на 100%. Поэтому умеем подгонять процесс тестирования под реальную жизнь заказчика, а не под «идеальный учебник».

Да, мы не просто разрабатываем и сдаём проект «как есть», но и подстраховываем его качеством:

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

Приходите, спрашивайте, задавайте вопросы. Мы в BSS уже готовы и к вашим «очень срочным» хотелкам, и к настройке классического тестового воркфлоу под вашу команду.

До встречи!