Процесс Ручного Тестирования: Что Следует Автоматизировать?

Отказ от ответственности Читая книгу об автоматизированном тестировании, я нашел довольно интересное описание некоторых способов, которые используются для автоматизации процесса.

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

Читая книгу, я часто вспоминал свой путь к автоматизации.

В этой статье рассматривается то, что нельзя автоматизировать ни при каких обстоятельствах.



Процесс ручного тестирования: что следует автоматизировать?

Случайное, спонтанное (думаю, это более точный перевод Ad hoc) тестирование предполагает простое сидение перед компьютером и пробуние разных вещей.

У тестировщика может быть или не быть плана тестирования или контрольного списка.

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

Все идеи и действия тестировщиков не документируются и носят скорее спонтанный характер.

А некоторые сценарии впоследствии невозможно воспроизвести.

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

Типичная такая ситуация — спецификаций нет, требования еще в разработке и постоянно меняются, а ПМ говорит: «Нет времени писать, только тестируйте».

Работать над таким проектом не особо приятно и заслуживает сочувствия.

Зачастую автоматизация данного вида тестирования происходит следующим образом:

  1. Думаем, что делать, что тестировать
  2. Обдумывание конкретных входных данных
  3. Введите данные, которые вы только что создали
  4. Проверяем корректность работы программы, наблюдая за ответами, появляющимися на экране.

Трудно придумать множество преимуществ спонтанного тестирования.

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

Это аналогично вопросу «Почему он еще не программируетЭ» синдром, характеризующий простую разработку программного обеспечения.

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

К недостаткам такого типа тестирования можно отнести:

  1. Многие детали, которые следует проверить, можно просто пропустить.

  2. Некоторые детали, возможно, придется проверить больше, чем необходимо.

  3. Тесты не повторяемы, решения ошибок не могут быть достоверно проверены (в некоторых случаях ошибки могут просто не воспроизводиться)
  4. Обычно это неэффективно и непродуктивно.

Автоматизация такого тестирования зависит от решения тестировщика, что тестировать.

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

В противном случае это зависит от индивидуальной разработки и реализации тестов без какой-либо независимой проверки качества тестов.

Теги: #тестирование #автоматизация #тестирование ИТ-систем

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.