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

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

Определить ожидания

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

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

Определить, что автоматизировать

Очевидно, что бездумная автоматизация — это неправильно. Но как понять, какие тесты достойны автоматизации, а какие нет?

Вот несколько советов, что не стоит автоматизировать с самого начала:

  • Тесты на наличие ошибочных функций/функций в стадии разработки. Вы потратите время на первоначальную автоматизацию и дальнейшую доработку тестов.
  • Автоматизация с отрицательным ROI. Нужно все просчитать. Например, вам нужно потратить три часа на автоматизацию тестирования. Если этот тест запускается один раз в день, его время выполнения составляет одну минуту, и вам нужна одна минута для анализа результата. В этом случае затраты времени на автоматизацию составят 180+2*30=240 минут. Если вам нужно всего 4*30=120 минут для ручного тестирования, то понятно, что автоматизировать такие тесты не стоит, это не сэкономит время.

Выберите платформу для использования

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

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

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

Настроить план

Просто тесты не пишут… Нужно идти к аналитикам или руководителю проекта, если они есть, или самому составить список тестов, расставить приоритеты для каждого теста и т.д.

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

Заключительные мысли

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