суббота, 21 апреля 2012 г.

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

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

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

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


Есть другие версии квадратов:  "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", как правило, это неудобно и медленно.
В идеале (по крайней мере у вас в голове) должна сложиться такая картинка (см. новый вариант ниже)

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

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



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

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

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

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

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

Update 3: Test Automation Patterns

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

Update 5: Automation - The Saviour?

Update 6: Смешные (хотя до боли правдивые) слайды про автоматизацию от Капитана Хаос

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

4 комментария:

  1. Автоматические тесты это часть движения к увеличению ответственности команды за результат. Как только у команды пропадает щит в виде тестеров, они становятся вынуждены писать тесты. Для эффективного написания тестов им приходится и код делать по человечески. 

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

    ОтветитьУдалить
  3. Все сильно зависит от проекта. Нужно искать разумный баланс между стоимостью автотестов и профитом от них на какой-либо части продукта. А вот от эксплораторного тестирования никогда никуда не денешься! Если любой вид автотестов показывает, что баги нет, то это просто означает, что он ее либо не так либо не там.

    ОтветитьУдалить
  4. 2 года статье - только сейчас ошибку в названии нашел... :)

    ОтветитьУдалить