11

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

Я так часто иронизирую над автоматизацией тестирования, что может возникнуть ощущение, что я её ненавижу или считаю малозначимой. Это не так. Вот на днях как раз отловил довольно серьёзный баг, который *как я сперва подумал* ни в жизни не обнаружил бы, тестируя вручную. Автоматизируя тест-кейсы веб приложения, внезапно заметил, что вместо одного элемента окна диалога мне вернулся массив. Оказалось, что диалог, который используется во многих местах приложения всегда создается после открытия, но не удаляется из кода страницы после закрытия. Со временем "мусор" накапливается и тормозит отображение страницы.

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

...и вот, что оказалось. "Нас часто спрашивают"™, как выжить тестировщику, который не умеет писать программный код, в современном жестоком IT-мире, где всякий встречный пытается автоматизировать всё, что не успевает на счет 3 залезть на дерево. Отвечаю так. Приобретайте новые навыки, конечно, но... Не надо путать навыки автоматизации, без которых, *как я все еще не сомневаюсь*, можно обойтись от слова совсем, и навыки технической, пользовательской и исследовательской грамотности! Буквально неделю назад, я посмотрел небольшой курс c CodeSchool  (на сайте много неплохих бесплатных курсов, и еще больше хороших платных) про использование Developer Tools в Chrome, почерпнул для себя много нового, в частности методику проверки утечки памяти вручную (вот например, соответствующая часть инструкции на сайте Chrome). Выясняется, что быстрее и надежнее вышеупомянутую ошибку (и многие другие) можно было выявить ручным тестированием с использованием технических средств.

И вот уже закругляя, хочу поднять провокационный вопрос. Одна из важных задач тестирования - нахождение *новых* ошибок, вы со мной согласитесь? Может ли быть, что автоматизация тестов с этой задачей не может справиться, ну или если справляется, то *значительно хуже* чем ручное?

P.S. В Фейсбуке горячая дискуссия:  https://www.facebook.com/alexei.vinogradov/posts/1109312402419661

2

В Новосибирске с удовольствием сходил на квартирник:

http://2015.codefest.ru/lecture/1044 (видео писалось и будет выложено через некоторое время)

где обсуждались темы будущего тестировщиков в целом, и ручного тестирования в частности.

Ожидания оправдались, у тестировщиков и программистов оказалось очень широкое понимание вопроса. Услышал такие распространённые заявления, как "ручное тестирование медленно и должно быть заменено автоматизированным", "тестировщик не умеющий программировать скоро не будет нужен", "программисты должны взять на себя работу тестировщиков (в т.ч. и ручное тестирование), чтобы не терялось время на коммуникацию". Впрочем и за-тестировочные мнения тоже были :).

Моя позиция довольна простая - тестировщики были, есть и будут нужны для разработки программного обеспечения. Исключить тестировщиков - это как заменить в машине все окна на микро-мониторчики в салоне, в принципе можно и по ним смотреть на дорогу, но зачем?

А вот известное видео, на котором автоматизатор пытается научить ручного тестировщика автоматизировать тестирование:

4

Не могу не поделиться прекрасным. Презентации, посвященные в основном автоматизации и автоматизаторам, не новые, но раньше не видал.

Внимание, в слайдах присутствует не ISTQB-шная лексика! Не рекомендуется к просмотру людям впечатлительным и неумеющим понимать иронию.
Приведу подборку лучшего.

Краткое введение в тему:

А теперь подробно о том, как писать хорошие автотесты:

Опасности использования BDD: ...читать далее Автоматизация тестирования: советы от Captain Chaos

13

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

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

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

Надеюсь, всегда запоминается последняя фраза ;-).

6

В этом году я познакомился с фреймворком Selenide, который позволяет писать более компактные и читаемые тесты на языке Java с использование технологии Selenium Web Driver. Доклады на эту и другие темы автора фреймворка Андрея Солнцева показывают, что разработчики глубоко понимают проблемы UI тестирования и успешно работают над их решениями. Давайте же пользоваться!

Все хорошо, но есть проблема. Если посетить на сайте проекта раздел "Быстрый старт", то вам предложат воспользоваться одним из продвинутых тулов для разработчиков (maven, gradle, ivy). Необходимо ли это? Вовсе нет. Начать писать тесты и эффективно использоваться Selenide можно и владея только самым базисом тест-автоматизации - Java, Eclipse, основы Selenium. У вас есть 5-10 минут? Этого достаточно, убедитесь сами.

Нам понадобится:

  • Java SDK 1.6+
  • Eclipse for Java (практически любая версия) http://www.eclipse.org/downloads/
  • Браузер Firefox (с ним по умолчанию работают Selenium и Selenide)

...читать далее Selenide: теперь по-настоящему быстрый старт