С чего начать автоматизацию тестирования

Самым очевидным решением является автоматизация тестирования после обновления доработанной конфигурации типовым решением. Из типовой приходит много изменений, а доработки равномерно распределены по конфигурации. Ручное тестирование такого большого объема изменений трудоёмко и неэффективно. Если такие обновления происходят регулярно, тогда важной становится задача регресс-тестирования.
В первую очередь тестируются измененные типовые объекты, которые подвергаются встречным изменениям вендора и команды разработки. Определять такие объекты нужно регулярно при разработке. Подобные объекты можно включить в отдельную подсистему. Делать это может разработчик, выполняя кодирование, так и на этапе код-ревью или при подготовке релиза, ответственным за релиз.

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

1. Новая форма типового объекта, созданная на основе типовой формы
2. Новые реквизиты типовой формы
3. Новые макеты типового объекта
4. Измененные типовые макеты
5. Измененные алгоритмы проведения

Ещё одним приоритетом является частота использования функционала. Чем чаще объект используется пользователями, тем быстрее нужен авто тест для его проверки после обновления. Частота появления ошибок в объекте тоже является критерием высокого приоритета. Статистику ошибок можно собирать в баг-трекере.

Рассмотрим подробнее каждую группу изменений конфигурации.

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

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

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

5. Измененные алгоритмы проведения
В данном случае также можно разделить проверку на быструю и полную. Быстрая проверка позволит удостовериться, что при проведении не возникает ошибок и документ сделал движения в нужных регистрах или заполнил реквизиты. А полная функциональная проверка сравнит результат проведения с эталоном. Для "дымового" теста можно использовать один документ, который наверняка сделает движения. Для функционального теста может потребоваться несколько документов с различными комбинациями значений реквизитов, как в предыдущем пункте.

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

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