Вступление¶

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

Имея на входе информацию по задаче, мы мысленно разбиваем весь процесс кодирования на небольшие транзакции, рывки. Это является для нас неким краткосрочным планом работ (даже если на входе BDD-сценарий). Затем, мы начинаем методично работать по схеме “написание кода – запуск приложения – проверка ожидаемого поведения – возврат к доработке кода”. Количество таких транзакций и степень их завершенности - очень хрупкие сущности, потому что опираются на способность и возможность программиста быть в сосредоточении.

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

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

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

BDD и TDD¶

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

Во многом, эти вопросы решаются внедрением специальных методик, например, TDD, BDD, организацией дополнительных процессов по тестированию. Однако, везде есть свои нюансы.

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

BDD, за счет человеческого языка сценариев Gherkin, идеологически сшивает в одном месте специалистов прикладной и технической областей, а используемая конструкция описания сценариев Given-When-Then универсальна. Однако, BDD больше о процессе создания продукта, а не только о его тестировании. BDD основывается на ролевом взаимодействии сотрудников компании, что делает её требовательной (и в какой-то мере хрупкой) ко всем звеньям цепи разработки. Другой важной проблемой является не высокая эффективность языка Gherkin при разработке сложных (с точки зрения BDD) сценариев. К автоматическому документированию, как бонусу BDD, также, немало вопросов. Руководства пользователя к продуктам известных вендоров, не строятся по принципу Given – When – Then, а с техническим документированием, многие выбирают подход “Лучше устаревшая, но понятная, чем актуальная, но непонятная (или понятная только автору сценариев) документация.

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

В тоже время, на крупных проектах, эти переговоры необходимы. В идеале там будет аналитик, тестировщик и разработчик (BA+QA+Developer), но там не будет всего отдела программистов. А им, в конечном итоге, писать код, проводить тестирование, зачастую, намного более глубокое, с пограничными значениями, отклонениями, и другими особенностями реализации, возникновение которых рождается в коде и не может быть описано в приемочном тесте или постановке задачи. И это будет не TDD, а реальные сценарные тесты, которые программисты как правило не автоматизируют, а выполняют вручную в рамках процесса кодирования.

Другой пример из жизни программиста 1С: считается вполне типовым сценарий (пример описан не для российского законодательства): Расчет отпуска сотруднику, где нужно учесть предыдущие начисления за прошлые три месяца, включая количество праздников за период расчета, праздников, выпавших на выходные дни, если они предусмотрены графиком его работы, квартальные, годовые и фиксированной суммой премии, которые могут быть начислены не в периоде их расчетов, смена должности и/или графика работы, учет системы прямого табелирования или методом отклонений, а также, период самого отпуска должен быть очищен от праздников. В случае, если сотрудник часть отпуска проболел – следующее продление должно учитывать предыдущие начисления, кроме этого, нужно предусмотреть пересечение периодов начислений (неделя/две недели/месяц/вахта) с периодом отпуска и другие характеристики. В качестве сценария в данном случае, обычно выступает законодательный акт или статья из бухгалтерской периодики, что в большинстве случаев считается для программиста 1С включенной в область его ответственности задачей. Попытка организовать (а не только написать) сценарное тестирование на языке Gherkin для данного, вполне стандартного сценария, может стать настоящим испытанием.

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

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

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

Базовые определения¶

Процесс тестирования приложений при помощи Тестера основывается на взаимодействии Тестера с запущенной конфигурацией 1С в режиме 1С:Предприятие.

При этом считается, что Тестер выступает в роли Менеджера тестирования, а тестируемая конфигурация – в роли Клиент тестирования.

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

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

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

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

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

Тестер предназначен для тестирования конфигураций, разработанных на управляемых формах версии 1С:Предприятие 8.3.x. Обычные формы не поддерживаются.

Предполагаемые пользователи Тестера, это:

Пользователи	Задачи
Программисты	Использование системы в процессе разработки. Эволюция процесса ручного тестирования
Тестировщики с базовыми знаниями программирования на языке 1С	Написание сценариев, максимально приближенных к сценариям работы пользователей. Эти сценарии, обычно не такие глубокие, как у программистов, но более выраженные с точки зрения бизнес-процесса
Бизнес аналитики. Консультанты	Запуск тестов, анализ результатов. Через чтение тестов, понимание работы функционала системы