Как два QA-специалиста снизили текучесть в отделе бухгалтерии

В компанию SimbirSoft обратилась крупная организация с запросом на квалифицированных QA-специалистов. Проблема была обширная: этап тестирования закрывали непрофильные специалисты, из-за этого возникали сложности не только в разработке, но и на уровне процессов бухгалтерии. Некорректно сформированные документы приводили к недостоверной отчетности, в обработке данных возникали задержки. Страдали сотрудники — неудобство работы с программой влияло на текучесть кадров и коммуникацию внутри и между отделами. За полгода сменилось два главных бухгалтера. 
С точки зрения тестирования обнаружили следующие проблемы:

• Многочисленные ошибки в работе с платформой «1С:Предприятие» даже после исправлений;
• Отсутствие документации по тестированию и работе с системой;
• Отсутствие технического задания по задачам;
• Отсутствие системного подхода к тестированию.

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

Поэтому команде клиента требовался QA-специалист с опытом в 1С Бухгалтерии, который помог бы:

• Наладить процесс разработки ПО от идеи до эксплуатации и сопровождения;
• Уменьшить количество ошибок, связанных с процессом тестирования.

Наше решение

Мы рекомендовали клиенту нанять 2-х QA-специалистов. Вместе они смогли бы за 6 месяцев закрыть несколько процессов: сократить количество ошибок через тестирование, улучшить пользовательский опыт использования программы.

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

На момент старта ситуация была следующая:

• Избыток нерешенных задач: 50 на доске тестирования, 3 задачи к релизу, 115 задач в бэклоге;
• Формально спринт длился 2 недели, но периодически возникали переносы релиза, что создавало большую очередь задач; 
• Нет четкой приоритезации — задачи зависали, возвращались на доработку, изменения в задачах терялись.
• Не было QA-ревью: после тестирования задачи сразу закрывали, не анализировали влияние исправлений на другие компоненты. Из-за этого возникали повторные баги.
• Команда старалась придерживаться Agile-методологии, но в процессах не хватало важных этапов для организованной работы: планирования, ретроспектив, регресса.

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

Клиент оценил прогресс в работе и принял решение нанять второго QA-специалиста с опытом на платформе «1С:Предприятие». С расширением команды удалось улучшить процесс тестирования с этапа анализа требований до выпуска готового продукта. Рассмотрим конкретные шаги, которые к этому привели.

Описание технической документации

QA-специалисты начали с объяснения команде, зачем нужна техническая документация: чтобы все понимали систему, сокращали время на вопросы и ускоряли разработку.
Поскольку изначально документацией занимался продакт-менеджер (хотя это не его функция), было принято решение нанять бизнес-аналитика. Это привело к четкому разделению обязанностей — аналитик стал писать подробные требования с пользовательскими сценариями, разработчики получили ясные ТЗ, а QA-специалисты начали тестировать требования еще на этапе формирования. Так как требования были однозначны и понятны всем одинаково, то это ускорило разработку и финальное тестирование системы.

Анализ задач в story points и приоритизация

QA-специалисты подсветили проблему «завала» задач, которая возникала из-за отсутствия оценки. Опытным путем определили, что 5 story point=1 день работы над задачей. В один двухнедельный спринт закладывали определенное количество story point для всей команды. Задачи начали делиться на срочные и на те, которые можно перенести на следующий спринт.

Назначение Тимлида

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

• Настроил автоматизацию через CI/CD, чтобы уменьшить ошибки в GitLab;
• Упростил создание и отслеживание задач;
• Вместе с QA-специалистом изменил воркфлоу задач: например, в зависимости от статуса задачи разработчик либо уточняет детали, либо проводит правки кода, ревью, и отправляет на тестирование.

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

Внедрение процессов тестирования

Благодаря найму QA-специалистов удалось провести следующие виды тестирования.

Функциональное тестирование

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

• Основных операций: корректность ввода данных, формирование документов, автоматическое создание проводок, генерацию отчетов;
• Взаимодействие компонентов системы: проверку связей между справочниками, документами, регистрами, формирование бухгалтерских правил, контроль временных ограничений.

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

Интеграционное тестирование

Цель — убедиться, что разные части системы корректно обмениваются информацией между собой, как это предусмотрено в требованиях, и что этот процесс работает стабильно без сбоев и задержек. Мы имитировали реальную работу системы:

• С помощью XML-схем (как показано на скриншоте) отправляли тестовые документы между модулями;
• Проверяли, правильно ли документы принимаются и отображаются в каждом модуле;
• Сверяли результаты с технической документацией.

Особое внимание уделяли двум ключевым моментам:

• Документы должны бесперебойно проходить через всю цепочку обработки (очередь не должна зависать);
• Все данные должны соответствовать заранее определенной схеме выгрузки.

Регрессионное тестирование

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

Нагрузочное тестирование

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

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

Каких результатов достигли

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

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