В двух словах конечно не получится, но кратко. Обучение - простые тесты, тесты с параметрами, выделание общих "тестов". Например, создание номенклатуры, можно выделить в общую библиотеку с параметрами. А потом в основном сценарии вызывать такую библиотеку. На сколько частей разбить (создание общих библиотек) зависит от того, что хотите заполнять. Пока у нас 2 параметра (у номенклатуры), возможно потом будет больше. (Желательно не больше 5-7 параметров, потом сложно поддерживать).  И ещё плюс общих библиотек, что если какой-то реквизит в Номенклатуре добавился, не надо менять все сценарии где номенклатура используется, а лишь изменить общую библиотеку. Итого - обучение: простые тесты, тест с параметром, выделение общих библиотек и на основе этих библиотек создать простенький cross-тест, то есть от ввода данных до построения отчёта. После обучения - уже, пощупав инструмент, можно сесть и составить план тестирования. Что хотите проверять, зачем, почему. И пока цель должна быть не "заипать" тестами - а чтобы они помогали. А то мотивация быстро закончится :) Как было указано выше, не надо покрывать тестами часто меняющиеся механизмы - просто устанете переписывать и будет копиться неготив. Пока я бы вот это рекомендовал.

Критерий “часто меняющиемя механизмы” не понятен. Обычно ”частоменяющиеся” и ”наиболее важные” это одно и тоже. Как быть с этим? Меня тоже напрягает объем кода который нужно поддерживать в связи с появлением тестов. Что с этим делать пока непонимаю.

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

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

ок, а если сценарий слегка изменился, тест (ну или ту его часть, которая изменилась) заново накликивать/переписывать?

ок, а если сценарий слегка изменился, тест (ну или ту его часть, которая изменилась) заново накликивать/переписывать?

Это в рамках "накликивания" - интерфейсный тесты.  Ещё есть юнит тесты - проверка определённых процедур. Если простым языком - то внутри "интерфейса" мы можем сколько угодно переписывать код и наш тест не упадёт.

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

ок, а если сценарий слегка изменился, тест (ну или ту его часть, которая изменилась) заново накликивать/переписывать?

переписывать тесты после рефакторинга, зачем? какой смысл такого рефакторинга?

К стати да. Мы тоже аналитиков подключили к написанию тестов.

Написать тест может только программист, ведь никто кроме него не знает как внутри реализовано все? Аналитики должны дать на вход сценарии работы, а не готовые тесты.

Написать тест может только программист, ведь никто кроме него не знает как внутри реализовано все? Аналитики должны дать на вход сценарии работы, а не готовые тесты.

Написать тест может только программист, ведь никто кроме него не знает как внутри реализовано все? Аналитики должны дать на вход сценарии работы, а не готовые тесты.