Автоматизация тестирования. С чего начинать, возможные проблемы.

Disclaimer: Началось все "с чего начать", потом превратилось в копилку полезных ссылок по автоматизации.

С чего начать? 

Полезные советы

• Начинайте с малого в самом начале проекта, регулярно запускайте тестовую сюиту.
• Заведите себе backlog для задач автоматизации и их приоритизации. Это поможет вам сфокусироваться на неотложных задачах без потери общего направления, вашей конечной цели. 
• Не бойтесь потратить 1-2 спринта на изучение существующих тестовых фреймворков, их возможностей. Попробуйте написать реальные тесты с их помощью, это поможет вам выбрать фреймворк наиболее подходящий вашим требованиям. Желательно потом ответить себе на ряд вопросов.
• Старайтесь сохранять независимость тестов от данных. Это даст вам возможность менять инструменты (фреймворки), когда в этом возникнет необходимость.
• Создавайте самодостаточные тесты. Обращайте внимание на сложность поддержки и время прогона тестов каждый раз, когда добавляете новые тесты в автоматическую сюиту. 
• Ваши тесты не должны создавать ложного ощущения безопасности (false positive). Это убивает всю идею автоматических тестов.
• Сделайте все возможное, чтобы исправлять ошибки выявленные тесты максимально быстро.
• Обязательно включайте запуск автоматических тестов в систему сборки (continuous integration)
• У вас должен быть интуитивно понятный способ отчетов, дающий возможность любому в команде увидеть результаты тестов и историю их предыдущих запусков. Это дает возможность каждому быть включенным в мониторинг состояния проекта и помогает принимать правильные решения.

Шпаргалка для определения мест, которые нужно автоматизировать 

(из Agile Testing: A Practical Guide for Testers and Agile Teams)

Есть другие версии квадратов:  "The Testing Quadrants – We got it wrong!", "Let’s break the Agile Testing Quadrants".

А здесь, можно найти алгоритм от Martin Fowler для определения того, достаточно ли у вас тестов:

- вы редко выдаете "баги" в релиз

- вы редко опасаетесь изменить код из-за опасения привнесения "баги"

Кстати там же развенчивается миф о 100%  test coverage. Рекомендую.

Какие проблемы могут возникнуть  и что нужно учитывать?

Чем же помогают автоматические тесты? В первую очередь, это механизм обратной связи. Рано или поздно команда сталкивается с тем, что результат выполнения тестов приходится ждать все дольше и дольше. Начинается оптимизация (запуск тестов параллельно, обновление "железа", переписывание тестов). Все это увеличивает затраты.

Интересная дискуссия на тему автоматических тестов развернулась в комментариях к статье Michael Feathers "Taking Automated Test Off the Pedestal" (тут была ссылочка, уже померла). Майкл поднимает вопрос увеличения количества автоматических тестов на проектах и, как следствие, роста стоимости и временных затрат. При этом отмечается, что проблема политическая: стоимость поддержки и запуска автоматических тестов может быть высокой, но ее необходимо сравнивать со стоимостью их отсутствия. Считая, что тесты обеспечивают обратную связь, мы должны решить, какую именно реакцию и когда мы ожидаем. Предлагается установить временные рамки, в пределах которых мы рассчитываем получить результат. Если наши тесты позволяют нам это сделать - хорошо. Если нет, то начинаем делить сюиты, для того чтобы запускать их попеременно. Для этого важно определить те тесты, которые являются самыми важными для вас.

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

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

Не зацикливайтесь на автоматизации "через GUI", как правило, это неудобно и медленно (даже сейчас, в 2023, а в 2012 совсем грустно было).
В идеале (по крайней мере у вас в голове) должна сложиться такая картинка (см. новый вариант ниже)

К сожалению, чаще можно наблюдать такое, поэтому работы у нас еще море :) (пирамидки сперты отсюда):

Новая, классная картинка с пирамидой (треугольником?)

Еще одна запоминающаяся классификация ("домик")

Architecturally-aligned testing

Самая интересная от Noah Sussman, в виде фильтра через которые проходят фичи.

Свеженькое (2018) от Джеймса Баха: "Round Earth Test Strategy"

У меня даже есть своя "реализация":

Еще одна фигурка для упражнений :)

by Richard Bradshaw (link)

И еще. Не думайте, что автоматические тесты будут вам искать баги. Не будут! (Хотя практика и опыт показывает, что таки иногда находят, особенно когда это сложные многокомпонентные проверки). Это не их задача. Автоматика всего лишь доказывает, что ожидаемый функционал работает в тех условиях и в тех рамках, которые заданы тестом. Это все. Чудес ожидать не стоит.

Кстати, у меня появился пост про Fitnesse. Он может вам помочь вам с автоматизацией. Надеюсь получится полезная серия.

Update: Сергей Тепляков написал очень хорошую статью-обзор про автоматизацию тестирования. Крайне рекомендую.

Update 2: Еще рекомендую книжку "The A word" - интересный взгляд на эту тему.

Update 3: Сказка-быль о попытке оценить ROI автоматизации

Update 4: Automation - The Saviour?

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

Update 6: не нравится концепция "пирамиды автоматизации" - придумайте и используйте свою. Важно, чтобы у вас было как можно меньше тестов "через UI". Концепт "Test Automation Snowman"