Pull to refresh

Процесс ручного тестирования: А что бы нам такое заавтоматизировать?

Reading time 2 min
Views 5.4K

Disclaimer


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


testing
Произвольное, спонтанное (думаю, это более точный перевод Ad hoc) тестирование подразумевает под собой просто сидение перед компьютером и опробование разных вещей. Тестер может иметь или не иметь тест план или список проверок. Тестировщик думает, что бы такое протестировать и просто клацает то тут, то там пробуя разные сценарии, значения и размышляя «А что будет, если сделать вот так». Все идеи и действия тестера не документированы и носят больше спонтанный характер. А некоторые сценарии впоследствии не могут быть воспроизведены.
Такое положение вещей обычно бывает, когда проект по разработке ПО запущен поздно, на планирование тестирования уделено мало времени. Для такой ситуации типично отсутствие спецификаций, требования находятся все еще в разработке и постоянно меняются, а ПМ говорит: «Нет времени на писанину, просто тестируй». Работа в таком проекте не особо приятная и заслуживает сочувствия.

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

Сложно придумать много преимуществ спонтанного тестирования. Единственный аргумент, который упоминают — это то, что оно должно спасти время (мы ведь не тратим время на планирование, дизайн тестов, мы просто начинаем тестировать). Это аналог синдрома «Почему он еще не программирует?», который характеризирует простейшую разработку ПО. Такой подход всегда обходится дороже при долгосрочных разработках (и в самой разработке и в тестировании) т.к. намного больше ошибок будет сделано, а они обойдутся дороже при их решении.

Минусы такого вида тестирования включают:
  1. Многие части, которые должны быть проверены просто-напросто могут быть пропущены
  2. Некоторые части могут быть проверены больше чем это необходимо
  3. Тесты не повторяемые, решение ошибок не могут быть достоверно проверены (в некоторых случаях ошибки просто могут не воспроизводиться)
  4. Обычно это неэффективно и непроизводительно

Автоматизирование такого тестирования зависит от решения тестера, что проверять. Это означает, что тестер должен иметь необходимые знания для составления хороших тестов. В противном случае, это зависит от индивидуального дизайна и реализации тестов без какой-либо независимой проверки качества тестов.
Tags:
Hubs:
0
Comments 7
Comments Comments 7

Articles