100+ тестов на Vanessa-Automation. Личный опыт без маркетинга

Кому удобнее видео-формат, вот статья в виде доклада:

Ну а всем любителям текста добро пожаловать под кат.

Но прежде крайне важный дисклеймер:

• В данной статье автор НЕ представляет официальную или неофициальную позицию какой-либо организации, сообщества или группы людей.

• Автор не является экспертом в области тестирования 1С, как и экспертом в тестировании вообще.

• Автор выражает только свое личное субъективное мнение.

Итак, важное замечание озвучил, а то мало ли что… поехали...

1. Нудная теоретическая часть

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

Работает этот механизм следующим образом:

1. Вы запускаете клиент 1С:Предприятие со специальным ключом «/TESTMANAGER» в режиме менеджера тестирования, и рядом запускаете уже клиент для тестирования приложения, соответственно с ключом «/TESTCLIENT». То есть у вас открыто 2 сеанса 1С:Предприятие.

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

Код на встроенном языке 1С:Предприятия может выглядеть как-то так:

&НаКлиенте
Процедура СоздатьРеализацию()

  // Адрес тестируемого приложения
  НовыйПодопытный = Новый ТестируемоеПриложение("127.0.0.1", 1538, );

  // Попытаемся подключиться не более одной минуты
  ВремяОкончанияОжидания = ТекущаяДата() + 60;
  Подключен = Ложь;
  Пока Не ТекущаяДата() >= ВремяОкончанияОжидания Цикл

    Попытка
      НовыйПодопытный.УстановитьСоединение();
      Подключен = Истина;
      Прервать;
    Исключение
    КонецПопытки;

  КонецЦикла;

  Если Не Подключен Тогда

    // Завершаем работу теста
    НовыйПодопытный = Неопределено;
    Сообщить("Не смогли установить соединение!");
    Возврат;

  КонецЕсли;

КонецПроцедуры

Далее необходимо найти основное окно тестируемого приложения, например, так:

  // Получим основное окно
  ОкноПриложенияОсновное = Неопределено;
  КлиентскоеОкноТестируемогоПриложения = НовыйПодопытный.ПолучитьПодчиненныеОбъекты();
  Для Каждого ТестируемоеОкно Из КлиентскиеОкнаТестируемогоПриложения Цикл
    Если ТестируемоеОкно.Основное Тогда
      ОкноПриложенияОсновное = ТестируемоеОкно;
      Прервать;
    КонецЕсли;
  КонецЦикла;

А теперь попробуем ввести документ "Реализация товаров и услуг"

// Введем новый документ "Реализация товаров и услуг"
ОкноПриложенияОсновное.ВыполнитьКоманду("elcib/list/Документ.РеализацияТоваровУслуг");

// Получим открытое окно со списком документов
ОкноРТиУ = ТестируемоеПриложение.НайтиОбъект(Тип("ТестируемоеОкноКлиентскогоПриложения"), "Реализация (акты, накладные)");
ОкноРТиУФорма = ОкноРТиУ.НайтиОбъект(Тип("ТестируемаяФорма"), "Реализация (акты, накладные)");

// Нажмем кнопку с нужным видом документа
КнопкаТовары = ФормаРТиУ.НайтиОбъект(Тип("ТестируемаяКнопкаФормы"), "Товары (Накладная, УПД)");
КнопкаТовары.Нажать();

// Получим окно с новым документом
ОкноРТиУСоздание = ТестируемоеПриложение.НайтиОбъект(Тип("ТестируемоеОкноКлиентскогоПриложения"), "Реализация товаров");
ОкноРТиУСозданиеФорма = ОкноРТиУСоздание.НайтиОбъект(Тип("ТестируемаяФорма"), "Реализация услуг: Акт (создание)");

// Активизурем поле "контрагент"
ПолеКонтрагент = ОкноРТиУСозданиеФорма.НайтиОбъект(Тип("ТестируемоеПолеФормы"), "Контрагент");
ПолеКонтрагент.Активизировать();

// Ждем, пока активизируется
Подождать();

// Вызываем выпадающий список
ПолеКонтрагент.ОжидатьФормированияВыпадающегоСписка();

// Ждем, пока прорисуется
Подождать();

// Выбираем контрагента
ПолеКонтрагент.ВыполнитьВыборИзСпискаВыбора("Ромашка ООО (00-000056)");

// и т. д. ...

Как вы можете заметить, как-то это все не очень удобно. Это еще нет необходимых проверок, например не реализован код, когда в списке ООО Ромашки не будет, и так на каждом шаге. Нет записей в журнал регистраций или другой лог и т. д.

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

&НаКлиенте
Функция КнопкаСуществует(ОкноКлиентскогоПриложения, ИмяКнопки)

&НаКлиенте
Функция НажатьНаКнопку(ОкноКлиентскогоПриложения, ИмяКнопки)

&НаКлиенте
Функция КнопкаКоманднойПанелиСуществует(ОкноКлиентскогоПриложения, ИмяКнопки)

&НаКлиенте
Функция НажатьКнопкуКоманднойПанели(ОкноКлиентскогоПриложения, ИмяКнопки)

&НаКлиенте
Функция ПолеФлажокСуществует(ОкноКлиентскогоПриложения, ИмяКнопки)

&НаКлиенте
Функция ПолеФлажокУстановить(ОкноКлиентскогоПриложения, ИмяКнопки)

// и т. д. ...

То есть у вас будет некая библиотека универсальных функций для написания тестов или еще мы ее назовем «Библиотека шагов». Мы к этому термину еще вернемся.

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

Но в какой-то момент вы поймете, что описывать всю логику теста кодом на языке 1С не очень удобно. Хотелось бы мышкой записываться сценарий прямо в клиенте 1С:Предприятие, а чтобы тест его потом воспроизводил. Благо у 1С такой механизм есть.

Можно запустить клиент 1С:Предприятие в режиме записи журнала действий пользователя (есть даже такая команда в конфигураторе).

При этом в правом верхнем углу окна клиента появятся кнопки для запуска и остановки записи действий.

Далее вы выполняете какие-то действия в приложении, а результат журнала действий платформа возвращает в формате XML.

На скриншоте выше я выполнил те же действия, для которых ранее показывал код на языке 1С, то есть создание документа «Реализация товаров».

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

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

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

В результате у вас получится полноценный фремворк для тестирования в 1С. И таких фреймворков сделано уже несколько.

2. Фреймворки тестирования в 1С

Давайте рассмотрим самые популярные.

Первым идет самый старый и известный инструмент от вендора «1С:Сценарное тестирование». Это отдельная конфигурация от фирмы 1С. Она платная, стоит на момент написания статьи 42000 рублей.

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

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

Все это на старом хорошо знакомом СКД.

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

Не так давно вышла более простая и бесплатная версия сценарного тестирования - «1С:Тестировщик». Для полноценной глубокой работы с тестами она, наверное, не самое лучше решение, но вот чтобы попробовать, оценить инструмент, попытаться написать простые тесты без долгой первоначальной настройки, вполне годится, ведь сценарии «1С:Тестировщик» и «1С:Сценарное тестирование» полностью совместимы. То есть посмотрели, попробовали, если понравилось, можно покупать полную версию.

Ну и раз мы перечисляем инструменты от вендора, стоит упомянуть и
«Тест-центр». Он работает немного по другому принципу, но добавим его тоже для полноты картины.

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

Про нагрузочное тестирование в 1С:ERP с помощью конфигурации Тест-центр у меня есть отдельная статья.

Далее идут уже инструменты от сообщества.

Очень неплохую конфигурацию, написал Дмитрий Решитко, называется она «Тестер» (http://tester.help). Отличительной особенностью данного продукта является очень подробная документация и множество видео по работе с данным решением. Сценарии пишутся и хранятся в информационной базе «Тестер».

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

Следующий инструмент называется «Тестирование 3.0» от Владимира Крючкова и его коллег (https://github.com/ivanov660/TestingTool-3). И это тоже конфигурация 1С. Ну и это, в общем то, понятно, т. к. разработчики этих решений - это разработчики 1С, и они и разрабатывали свои решения в понятной для себя парадигме.

«Тестирование 3.0» также имеют довольно подробную документация (что редко бывает для бесплатных проектов). Очень много видео по работе с конфигурацией. Она похожа на Сценарное тестирование. Тест представляет собой также дерево из заранее определенных шагов.

Идем далее. В далеком уже 2012 году появился продукт Vanessa-Behavior, который в общем-то заметно отличался от существовавшего уже тогда 1С:Сценарное тестирование (первый релиз которого вышел в 2008 году).

Библиотека шагов представляла собой набор внешних обработок лежащих в папке проекта. Для языка написания сценариев был выбран известный в НЕ 1С-мире язык Gerkin. Далее он был адаптирован, скажем так, для 1С-ных задач. В качестве хранения и контроля версий предлагалось использовать GIT. И вообще, как видно, этот фреймворк вобрал в себя очень много идей и инструментов из НЕ 1С-ного мира.

Но это и понятно, так как идейным и не только идейным автором его был известный в 1С-ных кругах Алексей Лустин, а также Леонид Паутов. Далее фреймворк активно развивался сообществом разработчиков, которые называли себя «Серебряная пуля».

Но сейчас, «Серебряной пули» в том виде, в котором она была тогда уже не существует. А инструмент продолжает жить в двух независимых фреймворках: «Vanessa ADD» (https://github.com/vanessa-opensource/add), который также включил в себя и фреймворк «xUnitFor1C» и «Vanessa-Automation» (https://github.com/Pr-Mex/vanessa-automation).

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

Основным контрибьютером Vanessa ADD является Артур Аюханов, который сейчас работает в Infostart.ru.

А Леонид Паутов развивает продукт Vanessa-Automation, работая уже в фирме 1С.

Вот такой вот у меня получился список фреймворков тестирования.

1. 1С:Сценарное тестирование 8

2. 1С:Тестировщик

3. Тест-центр

4. Тестер (http://tester.help)

5. Тестирование 3.0 (https://github.com/ivanov660/TestingTool-3)

6. Vanessa ADD (https://github.com/vanessa-opensource/add)

7. Vanessa-Automation (https://github.com/Pr-Mex/vanessa-automation)

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

Далее я буду рассказывать о своем опыте с Vanessa-Automation и исключительно потому, что я только с ней и работал. Как там обстоят дела в других фреймворках, я просто не знаю.

3. Vanessa-Automation

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

Итак, первое преимущество возможно покажется вам очевидным или надуманным, но я должен об этом сказать. Vanessa-Automation - это абсолютно рабочий инструмент для полноценной реализации автоматизированного сценарного тестирования в 1С. Если кто-то вдруг еще посматривал с боку и сомневался, а реально работает ли оно. Да, конечно же работает, это подтверждается опытом многих команд, которые используют Vanessa-Automation в своей работе и моим личным опытом также. Например, на Vanessa-Automation тестируются типовые конфигурацию 1С:ERP, 1С:УНФ, 1С:Управление холдингом. Кстати, для последних двух часть тестов есть в общем доступе на сайте релизов 1С. Можете начать с них, если у вас УХ или УНФ.

Технически, Vanessa-Automation представляет собой каталог с файлами внешних обработок, различных внешних компонент, файлов настроек и прочих сопутствующих файлов.

А точкой входа служит единая обработка Vanessa-Automation.epf в которой и происходит вся основная работа. Причем, эти внешние обработки представляют собой очень большую библиотеку шагов, где реализовано множество самых необходимых шагов почти на все случаи жизни.

Есть готовые шаги для работы с любыми элементами формы, командами, файлами, таблицами и табличными документами.

Как видно на скриншоте, все шаги представлены одним списком с разбиением по категориями с подсказками и поиском по ключевым полям. Это очень удобно.

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

Добавим это в преимущества инструмента. Теперь поговорим о сложностях использования.

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

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

Зато неоднократно помогало сообщество. Это прям очень большой плюс инструмента. Есть телеграм-чат, с более чем 2500 участников, где можно задать вопрос и вам обязательно ответят, почти в режиме реального времени. Я неоднократно находил решение именно там. Если будете использовать этот фреймворк, обязательно вступайте.

Идем дальше. Как я вам говорил уже, для написания тестов в ванессе используется человекочитаемый язык Gherkin. Он сильно адаптирован под наши реалии. Например, в нашем Геркине есть циклы и условия.

Можно выполнять вставки кода на встроенном языке 1С и т. д.

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

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

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

В мае этого года, я был на круглом столе по инструментарию разработчика 1С на INFOSTART EVENT. В зале было больше 100 человек. Я задал залу вопрос, кто использует тестирование в своей работе, процентов 80 подняло руки, то есть практически все. Здесь правда надо понимать, что туда пришли люди, что называется «в теме». А второй вопрос я задал, спросив, у кого тесты пишут НЕ разработчики. И было, к сожалению, всего пару рук. Как-то так.

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

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

Кроме того, следует все время помнить о некоторых ограничениях при написании тестов. Например, нельзя протестировать перетаскивание объекта между окнами, выполнение действий с зажатым контролом, выбрать пункт контекстного меню, если это не команда формы и т. д. Это, на самом деле, не проблемы ванессы, а ограничения API платформы. В состав фреймворка входит внешняя компонента (даже две), которая решает некоторые такие проблемы. Более того, есть расширение, которое нужно установить в тестируемую базу и с его помощью разработчики ванессы пытаются закрыть часть таких вот дыр. Но все равно, нередко приходится переписывать функционал таким образом, чтобы потом можно было покрыть его тестом. Об этом, в общем то, тоже приходится помнить.

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

Я вот, например, очень люблю СКД. Это очень удобный инструмент для формирования отчетности. Тут вам и группировки и условное форматирование, любой состав колонок и т. д. Здесь же ничего подобного «из коробки» не имеется.

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

Есть и СППР, с которой у Ванессы тесная интеграция. Но самой часто используемой системой получения отчетов является бесплатная Allure.

Вот примерно так выглядит итоговая отчетность в Allure. Тут не так много сведений, нет любимого «СКД», но все же для повседневной работы, вполне хватает.

Например, раз каждый тест и свои шаги – это отдельные файлы на диске, а не элементы в справочнике, вам понадобится какая-то система контроля версий и командной разработки для файлов. Почти всегда это git. С ним тоже придется научиться работать, кто еще не умеет.

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

Но и вообще: вот вы написали тесты. Вы же ну будете запускать их каждый день руками?

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

В общем, вам понадобится полноценный контур CI/CD. И у вас в команде должен быть как минимум 1 человек, который сможет все это организовать, настроить и затем поддерживать. А если такого человека нет, то нужные компетенции придется приобрести. Будьте сразу, с самого начала к этому готовы. Вполне возможно, что понадобится и немного или может быть даже намного поменять вообще процессы работы в команде.

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

А самые извращенные пишут даже свои инструменты для автоматизации данных действий.

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

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

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

Давайте посмотрим короткое видео из интерактивной справки, где ванесса рассказывает сама про себя.

В итоге, у меня получилось вот такая вот таблица:

4. Заключение

В конце позволю себе еще чуточку ламерских размышлений на тему тестирования.

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

Кроме того, любой тест, как и любая программа, когда-нибудь свалится, устареет, станет неактуальным и т. д. Будьте готовы все это поддерживать.

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

А кто вообще не умеет делать оценки? Я очень много рефлексировал над вопросом оценки, над своими оценками, план-фактом и пришел к выводу, что я вообще не умею оценивать задачи.

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

Конечно же нет прямой зависимости между оценкой задачи на разработку и оценкой задачи на написание теста. Может так сложиться, что задача огромная, но тест относительно простой и наоборот. Тут все очень индивидуально. Но если вы никогда не писали тестов и надо сделать верхнеуровневую оценку пальцем в небо. Частый запрос, да? То пожалуйста: будьте готовы, что на начальном этапе у вас будет уходить на тест столько же времени, сколько и на саму разработку. Один в один. Например, если есть задача, скажем на создание нового документа и она была оценена, предположим, в 40 часов. То еще столько же, то есть неделя, потребуется чтобы покрыть этот документ начальными тестами – ведь нужно подготовить тестовые данные, реализовать различные сценарии проведения документа в зависимости от этих данных, например, когда хватает условных «остатков», когда не хватает. Проверить, что все элементы формы отрабатывает так как надо, и, что намного сложнее, НЕ отрабатывают как НЕ надо. Проверить движения документа, печатную форму, если есть и т. д.

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

Есть еще и такой метод, который я слышал. Что у опытного (!) тестировщика на написание автоматизированного теста уходит в 4 раза больше времени, чем на аналогичный ручной тест. В общем, надо учиться отдельно оценивать и тестирование.

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

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

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

Другой пример, если у вас, розница, базы все распределены и из-за одной ошибки утром все магазины могут оказаться нерабочими. Это вот мой печальный кейс. Однажды, я как-то одну среднего размера торговую сеть, сделал просто сетью… без слова «торговая». Клининговая компания получилась, т. к. ничего не работало и продавцов отправили убираться... Так вот, в этом случае, наверное, имеет смысл критичную функциональность покрыть тестами, да.

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

В общем, поймите какую бизнес-задачу вы решаете, проведите экономические расчеты и затем уже решайте, нужно ли вам и в каком объеме нужно автоматизированное тестирование.

Итого имеем:

1. Автоматизация тестирования = Разработка ПО

   1. Этим нужно управлять

   2. Нет мгновенной отдачи

   3. Это придется поддерживать

   4. Невозможно точно оценить

   5. …

2. Придется много учиться новому

3. Необходимо просчитывать экономическое обоснование

Ну а у меня все. Всем спасибо, кто дочитал до конца. Буду рад пообщаться на данную тему.

Ну а если вам понравилась статья, приходите на ее логическое продолжение, доклад «Все, что вы хотели знать про дымовые тесты, но боялись спросить» на предстоящей Infostart Event 2023.