Инструменты и процессы разработки 1С:Бухгалтерии

Меня зовут Никита Арипов. Я работаю в фирме «1С» 10 лет, и все это время я разрабатываю «1С:Бухгалтерию предприятия». А сейчас еще дополнительно отвечаю за развитие отдельного направления – за разработку продукта «1С:Бухгалтерия некоммерческой организации».

Я увлекаюсь различными инструментами и процессами разработки – с их помощью мы стараемся улучшить работу в нашей компании.

 

 

Перед тем, как начать, хочу немного рассказать про «1С:Бухгалтерию предприятия».

Эта программа выпускается с 1994 года – тогда вышла первая версия «Бухгалтерии 6.0» под Windows.

До нее были «Мини-бухгалтерия» и несколько версий «Бухгалтерии под DOS». Но история развития «1С:Бухгалтерии предприятия» в том виде, как мы ее знаем, берет свое начало именно с 1994 года.

Я тогда только пошел в первый класс, принес первую двойку, как на картинке. А «Бухгалтерия» уже приносила радость и удовольствие пользователям!

 

 

Причем это не пустые слова. Фирма «1С» ежегодно проводит партнерские семинары, на которых опрашивает партнеров, как пользователи оценивают нашу программу. И, как видно на графике, качество стабильно растет. Мы тратим на это большие усилия и радуемся, что нам это удается.

 

 

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

• Например, «1С:БизнесСтарт» – это программа для небольших организаций или индивидуальных предпринимателей.

• «1С:Бухгалтерия некоммерческой организации», за которую я отвечаю.

• «1С:Садовод», «1С:Гаражи» и другие конфигурации.

А еще на базе «1С:Бухгалтерии» выпускается множество отраслевых конфигураций, поэтому важно, чтобы программа была качественная, понятная и простая.

 

 

Для всех конфигураций, которые выпускаются в нашем отделе, мы применяем общие унифицированные процессы разработки. Тем не менее у подразделения, которое выпускает УТ и ERP – свои процессы, для ЗУП - еще другие процессы.

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

 

Как выглядит доска задач для разработки 1С:Бухгалтерии 8

 

 

Наши процессы разработки строятся на принципах Agile. Раньше мы пробовали управлять процессами разработки по Scrum, а сейчас применяем Kanban.

 

 

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

 

 

Мы решили выбрать методику Kanban, потому что нам важна непрерывность потока.

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

В отличие от проектной работы, где есть начало и конец, в разработке 1С:Бухгалтерии нет конца – мы продолжаем ее разрабатывать и сейчас. Бэклог растет и нам важно отслеживать непрерывность потока задач.

 

 

Помогает нам в этом Kanban-доска – с ее помощью мы можем визуализировать:

• наши основные задачи,

• где застопорилось,

• что и почему пошло не так.

 

 

В Kanban можно разделять задачи на так называемые классы обслуживания. Суть в том, что у разных задач – разный уровень рисков.

 

 

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

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

 

 

Еще есть задачи ускоренные или срочные – у них риски растут со временем: чем дольше делается задача, тем больше мы несем рисков.

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

 

 

И есть обычные задачи, которые идут по стандартному workflow – останавливаются на всех остановках. Таких задач большинство.

 

 

Вот так выглядит наша доска.

В Скраме есть понятие Scrum of Scrums – когда каждая команда проводит дейли по Scrum, а потом проводится общее Scrum-дейли по всем командам.

Так и у нас. И хотя в Kanban, наверное, Kanban of Kanbans нет, но мы что-то такое придумали. У нас сначала тимлиды отдельно обсуждают в своих командах с разработчиками: что они сделали вчера, какие были проблемы, что планируют делать сегодня.

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

 

 

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

 

 

Релизы у нас не привязаны к каким-то конкретным задачам. Мы стараемся делать их ритмично – выпускать релиз примерно раз в две недели.

Те задачи, которые успели попасть в этот релиз – выпускаются. А те, которые не успели – ждут следующего поезда.

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

 

 

Чтобы успеть сделать больше задач, мы применяем методику «вытягивания». Эта методика пришла к нам из бережливого производства – там она связана с заказами, когда более поздние этапы «вытягивают» выпуск изделия на себя.

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

 

 

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

 

Контролируем ограничения и считаем метрики

 

 

Еще одно важное свойство Kanban – это ограничения.

Обычно используются work-in-progress-ограничения – когда в каждой колонке может быть не больше определенного количества задач. Как только мы достигли этого количества, задачи в колонку больше не помещаются.

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

 

 

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

Как на слайде, где задача ждет тестирования 5 рабочих дней. В этом случае ответственному за тестирование и ответственному за продукт приходит письмо. Возможно, стоит разработчиков подключить или что-то еще сделать, чтобы не “стопорилась“ задача.

Мы так контролируем этот момент.

Конечно, не факт, что все сразу кинутся эти задачи передвигать дальше. Например ради какой-то более срочной задачи можно и подождать.

 

 

То же самое касается и проверки кода. Причем, и в тестировании, и в проверке кода у нас используются две колонки: левая и правая.

• В левой колонке задача ожидает проверки кода или ожидает тестирование.

• В правой колонке – задача в процессе тестирования или в процессе проверки кода.

 

 

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

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

 

 

Видно, что сейчас тренд идет на снижение – задачи задерживаются меньше. И это не может не радовать.

Но если простой станет расти, то это повод проверить, что пошло не так и попытаться найти где и что нужно поменять.

 

 

Как я уже сказал, в тестировании и в проверке кода есть разделение колонок, которое показывает, что некоторые задачи пока находятся в ожидании.

 

 

Что же касается анализа и разработки, то здесь такого разделения нет. У нас задача не может ждать анализа или разработки. То есть разработчик ее берет и сразу занимается.

 

 

Но на этом этапе мы тоже контролируем, чтобы не было простоев.

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

Это не значит, что все плохо и с задачей нужно что-то срочно делать. Это скорее показатель, что возможно, задача буксует. Например разработчик куда-то закопался или не может с чем-то разобраться. Тимлиду стоит на это обратить внимание.

А возможно задача реально большая. Как, например, ЕНС – его быстро и не сделаешь. Вряд ли получится так, что мы его раз и выпустили очень быстро.

 

 

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

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

Мы посчитали, что простые задачи чаще всего делаются за 7 дней, а обычные задачи – за 16 дней. Причем решение о том, какую задачу считать простой, а какую – сложной, принимается субъективно. Разработчики сами отвечают на этот вопрос, а мы потом собираем такую информацию.

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

 

 

Еще раз - вот так выглядит наша доска. Каждое утро тимлиды приходят к доске и начинают перевешивать задачи.

 

 

Процесс идет справа налево – сначала убирают с колонки Выпуск то, что уже вышло, какие-то задачи перевешивают из тестирования и проверки кода, передвигают задачи, находящиеся в разработке или в анализе.

Когда такой дейли-митинг заканчивается, то доска соответствует началу текущего дня. То есть мы можем оценить, что изменилось со вчерашнего дня.

 

Что нужно, чтобы взять задачу в работу

 

 

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

Причем помимо плана у нас есть еще и бэклог – он очень большой. Мы там недавно насчитали порядка 2500 задач. Это не значит, что все они будут сделаны. Скорее всего, что-то уже не актуально, а что-то уже должно отвалиться само собой. И это нормально, потому что записаны они могли быть давно.

Итак, какие задачи у нас могут попадать в план или в бэклог?

 

 

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

Безусловно, разработчики у нас вешают задачи. Обычно это задачи по рефакторингу или каким-то механизмам, которые можно улучшить.

 

 

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

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

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

 

 

Еще у нас есть такой механизм, как Центр идей.

Это инструмент, в котором сами пользователи вешают какую-то задачу: «Хочу, чтобы было сделано вот так». А остальные пользователи смотрят на эту задачу и голосуют – ставят плюсики или минусы, тем самым модерируя самих себя. А мы исходя из этого рейтинга понимаем полезная это задача или нет. А затем из топа центра идей берем задачи в работу.

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

 

 

Конечно же, у нас еще и огромное количество законодательных задач. Причем законодательство бывает самое разное.

Бывают задачи огромные – например, когда ФСС с ПФР объединились. Всем понятно, что для этого в программе нужно сделать много. Для пользователей это тоже шок, и наша задача все сложные моменты нивелировать.

Но бывают еще и задачи, о которых пользователи даже и не знают – например, изменился срок подачи регламентированного отчета. Пользователи за этим могут даже не следить. А мы следим за всеми задачами! У нас методист смотрит, какие проекты сейчас в разработке у регулятора, а какие проекты уже приняты.

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

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

 

 

Давайте теперь для примера возьмем “Суперважную задачу”, которую нужно обязательно сделать.

 

 

Мы ее повесили на доску и поместили в колонку «План». Встают вопросы:
- Когда она перейдет в анализ?
- Что должно произойти, чтобы она перешла с одного этапа на другой?

Первое – мы должны считать, что эта задача достаточно важная.

В нашем примере из названия видно, что она важная. Поэтому считаем, что это условие выполнено.

 

 

Второе - задача описана и понятна.
Когда мы перевешиваем задачу из «Плана» в «Анализ», мы проговариваем идею, чтобы проверить насколько она понятна.

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

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

 

 

«Анализ» – это порой самый большой этап, который может занимать времени даже больше, чем все остальные этапы. Здесь делается очень многое, например:

• Происходит перевод постановки задачи на язык, понятный пользователям и партнерам.

• Общаемся с партнерам и пользователями, чтобы выяснить потребности.

• Учитываются различные системы налогообложения.

• Прорабатываются множество дополнительных условий и т.д.

И здесь один из самых интересных моментов, который хочется отметить – это то, как мы описываем ключевую пользовательскую историю.

 

 

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

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

 

 

Чтобы описать такой ключевой сценарий, мы используем метод пользовательских историй (User Story), который работает по типу:

• Я как ТипПользователя

• Хочу СделатьЧтоТо

• Чтобы ВсеПолучилось

Например, сейчас у нас делается задача по реестру платежей – для нее User Story может выглядеть следующим образом:

• Я как директор

• Хочу просмотреть и согласовать реестр платежек

• Чтобы бухгалтер оплатил только их и ничего больше

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

 

 

Также на этапе анализа, когда мы еще не написали ни одной строчки кода, мы уже проектируем интерфейс. Для этого можно использовать специальные инструменты, которых сейчас на рынке очень много – начиная от Figma и заканчивая сервисом Maker.

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

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

 

 

Я уже говорил, что «Анализ» включает себя кучу этапов по описанию задачи – причем еще ни одной строчки не написано, но:

• мы уже понимаем, что должно получиться в конце;

• имеем интерфейс, как это примерно будет выглядеть на конечном этапе;

• смотрим, чтобы это было в едином стиле;

• смотрим, как это сделано у других коллег.

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

И только после этого мы переходим уже в разработку.

 

В чем разрабатывать – в конфигураторе или в EDT

 

 

В разработке у нас, как и у вас, примерно те же самые инструменты:

• конфигуратор;

• EDT;

• и сейчас еще 1С:Предприятие Элемент.

Мы используем все эти инструменты. Причем в разработке 1С:Бухгалтерии у нас нет жесткого ограничения, что нужно использовать только EDT. У нас происходит мягкий переход – каждая команда сама для себя решает, будет она разрабатывать в EDT или в конфигураторе.

В апреле 2023 года на конференции DevCon, я рассказывал о том какие инструменты для каких конфигураций используются.

 

 

Поэтому не важно, в чем вы разрабатываете – важно, чтобы пользователь был доволен. Даже если вы написали что-то в «Блокноте», а потом каким-то образом скомпилировали – если пользователь доволен, этого уже будет достаточно, чтобы выпустить продукт.

 

Что делаем для повышения качества и понятности кода

 

 

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

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

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

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

 

 

Для статического анализа у нас используются инструменты SonarQube и АПК – они позволяют проверять, соответствует ли код стандартам.

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

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

 

 

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

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

У нас для этого используется Crucible – мы в нем проверяем код.

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

Т.е. код-ревью у нас используется не для галочки.

 

 

Если вдруг что-то пошло не так – есть какие-то критичные ошибки или какой-то сценарий не учтен – задача возвращается на доработку.

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

Важно, чтобы код, который получат пользователи, был проверен.

Только после того, как код проверен, и разработчик сказал, что все хорошо, задача переходит в тестирование.

 

Как и что тестируем

 

 

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

На этапе разработки тестировщик уже подключается к задаче:

• Смотрит на проектные решения;

• Составляет план тестирования;

• Отмечает тонкие моменты и делает для себя пометки;

• Намечает тест-кейсы, которые он будет проводить.

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

 

 

Помимо ручного тестирования, важно запускать еще регрессионное и автоматизированное сценарное тестирование.

Для этой цели у нас используется продукт «Сценарное тестирование». Я знаю, что в Инфостарте часто используют другую программу, но мы в своем отделе разрабатываем именно «Сценарное тестирование». Оно нам нравится, мы им восхищаемся и используем.

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

Рекомендую вам тоже попробовать 1С:Сценарное тестирование для запуска автоматизированных сценарных тестов.

 

 

Для запуска регрессионных тестов мы используем Jenkins. Такие тесты важны, потому что:

• Часто бывает, что разработчик написал 3 строчки кода и сделал миллиону пользователей хорошо – все счастливы, все замечательно.

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

К сожалению, второй вариант случается чаще.

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

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

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

 

Выпуск релиза

 

 

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

На слайде видно, что релизов собирается много. Но это не означает, что все они будут выпущены – будет выпущен самый лучший, по которому все проверки пройдены.

Причем здесь есть как предыдущий релиз – например, 3.0.131, так и версия 3.0.132, потому что помимо планового релиза иногда нужно выпустить и внеплановый.

В этой таблице колонки – это релизы, которые у нас выпускаются. А по строчкам – проверки, которые выполняются по каждому из релизов. Причем количество этих проверок постоянно растет.

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

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

 

 

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

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

• Первая цель – это поделиться с другими командами, что было сделано, чтобы коллеги понимали, что делается в соседних командах.

• Вторая польза от ретроспективы – она позволяет решать проблемы с холодной головой.

 

Вопросы

 

Какой софт вы используете для ведения Kanban? Там есть какие-то дополнительные настройки для отслеживания сроков?

Мы у себя используем продукты фирмы Atlassian – Jira, Confluence. Для Kanban используется отдельный плагин, который отрисовывает эту доску – мы в ней работаем.

Раньше, когда мы работали в офисе, то вели физическую доску. А сейчас из-за того, что у нас распределенная команда – часть команды работает в офисе, а часть удаленно – мы созваниваемся и смотрим задачи на доске в Jira.

Вы сказали, что у вас есть «Центр идей», которые закидывают пользователи и как-то за них голосуют. А где эти идеи вообще посмотреть? Я как пользователь, например, хочу какую-то идею внести. Как мне это сделать?

Есть «Центр идей» на 1С:Фреш – можно там добавить какую-то идею. И уже остальные пользователи будут голосовать за нее. Такая возможность пока есть только на 1С:Фреш

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

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

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

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

Но какой-то конкретной методики, наверное, нет. Нужно делать или не нужно – это решают уже сами тимлиды. Ну и плюс этот вопрос прорабатывается с начальником отдела.

Есть ли какие-то планы по поводу выкладывания сценарных тестов в open source?

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

Сколько по времени у вас занимает прохождение полного круга тестов?

Тесты для Бухгалтерии прогоняются примерно за 8 часов. Но при этом настроена большая параллелизация – под новые пачки тестов постоянно добавляются новые машины, которые выполняют тестирование.

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

Кто у вас пишет автотесты?

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.