«

»

Фев 03

Семь смертных грехов автоматизации тестирования ПО.

Наткнулся на интересную статью Adrian Smith(а) о смертных грехах в автоматизации тестирования. Решил поделиться с читателями, да и самому, под рукой, комфортно иметь адаптированный вольный перевод. На случай, как говорится: «А вдруг война, а я уставший?» 🙂

Оригинал на английском здесь.

Мой вариант перевода ниже (любые замечания/пожелания/мысли — приветствуются).

Когда Craig Smith и я планировали нашу презентацию для Agile 2011 – мы обыграли идею списка 7 анти-паттернов для автоматизации тестирования. Я взял эти  Семь смертных грехов. Эта метафора позволила мне так же включить линогравюру которую сделал мой дядя Errol Smith.

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

1. Обжорство

Использование не подходящих инструментов тестирования
Многие коммерческие средства тестирования предоставляют простые функции для автоматизации записи и воспроизведения (capture and replay) ручных тестовых сценариев. Хотя такой подход кажется нормальным, он предусматривает тестирование через пользовательский интерфейс, это приводит к изначально трудно поддерживаемым тестам. Кроме того, цена и ограничения на количество лицензий, ограничивают доступ к тестовым наборам, это не способствует командной работе. Хранение тестовых случаев вне системы контроля версий создает ненужные сложности.
В качестве альтернативы можно рассмотреть инструменты с открытым исходным кодом. С их помощью, обычно, можно решить большинство задач автоматизации тестирования и тесты легко могут быть включены в системы контроля версий.

2. Лень

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

3. Похоть

Любовь к UI сильна настолько, что все тесты выполняются через него
Хотя автотесты пользовательского интерфейса обеспечивают высокий уровень доверия к результатам тестирования, они дороги в создании, медленны в выполнении и унылы в поддержке. Тестирование на низком уровне — практика, которая вдохновляет на  сотрудничество между разработчиками и тестировщиками, увеличивает скорость выполнения тестов и снижает затраты на реализацию теста. После интеграционных, функциональных, системных и приемочных тестов, большая часть усилий должна ложиться на автоматизированные юнит-тесты. Тесты на основе UI следует использовать только для проверки пользовательского интерфейса или когда нет другой альтернативы.

4. Зависть

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

5. Гнев

Разочарование, когда тесты периодически ломаются
Для команды ненадежные тесты являются главной причиной игнорирования или потери веры в автоматизированное тестирование. Однажды утерянное доверие ощутимо уменьшает вложения в автоматизизацию. Исправление поломанных (дающих неверные результаты выполнения) тестов и решение проблем, связанных с ненадежными испытаниями, должно быть приоритетной задачей для предотвращения ложных результатов тестирования (мое прим. Помним, что тестирование собирает информацию о качестве… 🙂)

6. Гордыня

Мысли о том, что автоматизированные тесты заменят все ручные
Автоматические тесты не являются заменой ручного исследовательского тестирования. Смесь различных типов и уровней тестирования необходима для достижения желаемого уровня минимизации рисков, связанных с дефектами.
Пирамида автоматизации тестирование, первоначально описанная Майком Коном объясняет инвестиции в зависимости от типа и уровня тестирования. Начинаем с базы: Unit и заканчиваем прикладным уровнем.

7. Жадность (Алчность)

Слишком много автоматизации не соответствующей определенному качеству системы
Усилия на тестирование следует соизмерять с требуемым качеством системы, в противном случае мы получим опасность того, что тестироваться будет:

  • слишком много
  • слишком мало
  • не то, что надо

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

Итого

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

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

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

Перейти полю для комментария

  1. Maxim Shulga

    Да, отличная статья. Обогнал меня 🙂 тоже хотел себе перевести. Но у меня бы так хорошо не получилось.

    1. Сергей Атрощенков

      Спасибо.
      Я уверен что получилось бы нехуже точно. 🙂

  2. LeshaL

    Спасибо за перевод. Видел оригинал, но заломало читать.

    Интересное наблюдение: в оригинале «effort/costs», в переводе «усилий\затрат» — слэш явно выдает предподчтения автора статьи/перевода к определённой ОС 🙂

    1. Сергей Атрощенков

      Спасибо за комментарий, да, палюсь с ОС.

      PS. ‘\’ ближе к enter в русской раскладке, а до нам-пада тянуться — ле-е-ень. =)
      PPS. Хотя, судя по wikipedia, грамотнее ставить / — поменяю.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>