Повторяй за мной: как обучить команду автоматизированному тестированию на 1С

Консультант-эксперт 1С ALP Group Александр Коробицын делится опытом создания образовательного курса для сотрудников компании и объясняет, почему без наставничества и код-ревью фича-файлов здесь не обойтись.

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

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

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

В связи с этим сразу возникает вопрос: если аналитик не проходил специального обучения по тестированию, насколько качественно он его выполнит? Конечно, в каждом из нас в том или ином виде присутствует тестировщик. Мы каждый день тестируем огромное количество предметов и продуктов, но только всё это происходит на интуитивном уровне. Например, чтобы приготовить чашку кофе, нам сперва нужно проверить, есть ли зерна в кофемашине, достаточно ли в ней воды, включена ли она в розетку, стоит ли чашка по центру — и только пробежавшись по этому списку потенциальных «багов», мы можем спокойно нажать на кнопку.

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

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

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

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

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

Курс состоит из следующих модулей:

1. Знакомство с Vanessa-Automation (фреймворк автоматизированного тестирования 1С, который используется в нашей компании).

2. Знакомство с языком Gherkin и TurboGherkin:

3. Процесс автоматизированного тестирования в командной разработке (знакомство с Git, GitLab и Visual Studio Code).

4. Разбор практических кейсов автоматизированного тестирования от простого к сложному.

5. Анализ результатов выполнения тестов (знакомство с отчетом Allure).

6. Разработка видеоинструкций с помощью Vanessa-Automation.

Курс рассчитан на полтора месяца (по неделе на каждый из модулей) и проводится для команд по 10–12 человек. При большем количестве слушателей было бы невозможно качественно проверять домашние задания и давать персональную обратную связь. А без этого никакое обучение автоматизированному тестированию, на мой взгляд, не имеет смысла — уж больно много здесь подводных камней, которые можно освоить только на практике и только под присмотром опытного наставника, который подскажет, что ты делаешь не так, почему лучше сделать иначе, достаточно ли твоих проверок и всё ли в принципе ты предусмотрел.

Приведу пример. Предположим, нам необходимо автоматизировать тестирование создания документа «Поступление денег». Решение — запустить обработку Vanessa-Automation и с помощью инструмента «Начать запись действий пользователя» накликать сценарии создания документа в базе. И сразу первая проблема: шаги проверки наличия документа в базе не создаются автоматически при записи действий пользователя. При ручном тестировании специалист бы лично убедился, что документ успешно создался в базе. А как быть при автоматизированном тестировании?

Видимо, так же, как и при ручном тестировании, тестировщик-автоматизатор должен вручную добавить в сценарии шаги проверки наличия документа в базе. Для этого тестировщик определяет, по каким ключевым полям он будет искать документ в базе. Обычно в качестве таких полей выбирают «Номер» и «Дата» документа. «Вот и готов сценарий проверки создания документа “Поступление денег”!», — думает начинающий автоматизатор. Опытный же тестировщик знает, что такой сценарий имеет зависимость и не стабилен.

У платформы 1С есть специфическая особенность. При создании документа в период с 0:00:00 до 9:59:59 представление значения поля «Дата» отображается строковым значением с двумя пробелами между датой и временем:

При этом в списке документов представление значения поля «Дата» отображается с одним пробелом между датой и временем:

Учитывая эту особенность поведения документа, нам нужно разработать сценарий таким образом, чтобы он был независим от времени выполнения. Для этого нужно сохранить значение поля «Дата» в переменную «ДатаДокументаИсходная» (см. строку 31 на скриншоте ниже), а далее значение переменной «ДатаДокументаИсходная» преобразовать в нужный нам вид и сохранить в переменную «ДатаДокумента». Для преобразования значения можно использовать методы работы с датой, либо методы работы со строкой на языке 1С (см. строку 32).

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

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