Когда стоит переходить к автоматизации тестирования

в 15:07, , рубрики: heisenbug2017moscow, автоматизация тестирования, Алан Пейдж, Блог компании JUG.ru Group, высокая производительность, гейзенбаг, Тестирование IT-систем, Тестирование веб-сервисов

В этот раз мы поговорили об автоматическом тестировании с Аланом Пейджем, приложившим руку к созданию Windows 95, Internet Explorer и MS Office. Алан — великолепный специалист и собеседник. В этом интервью он простым и доступным языком рассказывает о нетривиальных аспектах процесса. Мы сконцентрировались на вопросах определения границ между разработкой и тестированием, проблемах с легаси, оценке качества тестов и отличии тестирования крупных проектов от малых.

Когда стоит переходить к автоматизации тестирования - 1

Но сначала несколько фактов из его биографии. Автоматизацией тестирования Алан Пейдж занимается уже почти 25 лет. Главный автор книг «How We Test Software at Microsoft» и «Beautiful Testing and Experiences of Test Automation: Case Studies of Software Test Automation»; автор целого ряда работ и заметок по автоматическому тестированию «The A Word». Ведет свой блог по разработке и тестированию. Алан пришел в Microsoft в команду Windows 95, впоследствии работал над ранними версиями Internet Explorer и Office Lync. В течении двух лет возглавлял центр Microsoft Test Excellence. В январе 2017 ушел из Microsoft в Unity в качестве директора по качеству.

На данный момент Алан — один из наших основных докладчиков на грядущей декабрьской конференции Heisenbug 2017 Moscow, в связи с чем мы поспешили его расспросить его о главных признаках необходимости перехода к автоматизации всего и вся.

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

Алан Пейдж: Что касается экспертизы, то уметь работать с такими фреймворками, как appium или selenium, важно, но не первостепенно. Цель моей команды — ускорить достижение качества, приемлемого для клиента, поэтому я присматриваюсь к вещам, которые делают команду эффективнее в тестировании и таргетируют качество. Сюда, конечно, входит и экспертиза в написании автоматических тест-кейсов, но куда важнее уметь писать полномасштабные тесты и разбираться в инструментах тестирования, нацеленных на повышение эффективности всей команды.

— О технологиях: каковы самые передовые must-have инструменты, IDE и плагины? И что вы посоветуете почитать об этом? Кто хорошо и качественно пишет про тестирование?

Алан Пейдж: Тут я, пожалуй, ничего удивительного не скажу. Selenium никуда не денется. Мне лично импонирует Python и pytest (и я, как автор, с ним согласен), хотя где-то в глубине души у меня всё ещё живёт С. Что касается IDE: годами писал в Notepad++ на самых разных языках и только шесть месяцев назад переключился на Sublime Text. Поэтому, думаю, что тут я не советчик.

Про блоги: стоит подписаться на Richard Bradshaw (twitter @friendlytester), он полон идей по автоматизации. И у него можно позаимствовать много всего интересного. Кстати, вот тут его блог: thefriendlytester.co.uk.

— Немало проектов страдают от проблем с легаси кодом: какие-то части кода становится трудно поддерживать и фактически невозможно изменить. Как меняет процесс автоматического тестирования в проектах с легаси (особенно, если его немало)? В чем плюсы от покрытия легаси кода тестами?

Алан Пейдж: Тут, конечно, есть пара факторов. Если легаси не меняется, код достаточно старый, и баги там уже точно не пофиксят, я бы вообще не стал тратить время на какие-то автоматические тесты.

Во всех остальных случаях тесты, наверное, все-таки понадобятся. Книга «Working Effectively WIth Legacy Code» авторства Михаила Фезерса (Michael Feathers) подробно описывает такие ситуации и в общем-то может помочь любой команде разработчиков разобраться в ситуации: идеями и стратегией  — как сделать код легко изменяемым и перерабатываемым и как писать нужные тесты.

— На каких этапах работы над проектом должно появиться автоматическое тестирование и в какой момент стоит начать задумываться об этом?

Алан Пейдж: Я начинаю задумываться об автоматизации, как только вижу документ с проектом или схему на доске. Но иногда даже раньше — как только начинаются разговоры о том, что именно мы собираемся создать — сразу же задаюсь вопросом: «как мы будем это проверять и тестировать?» Мы садимся и обсуждаем это вместе с командой, я составляю диаграмму связей (Mindmap). И к тому моменту, когда появляется что-то, что можно физически «потрогать», у меня в голове все уже обдумано, так что процесс запускается без сучка и задоринки.

— Как происходит масштабирование системы автоматического тестирования с ростом проекта? В чем качественное отличие тестирования небольшого и крупного проектов?

Алан Пейдж: Хороший вопрос. И это отличный повод обратиться к пирамиде автоматического тестирования. В основании находится группа небольших тестов (от автора: иногда этот уровень также называют «нижним»). Набор тестов растет линейно с масштабом проекта. С усложнением логики проекта и выходе на средний уровень интеграционные (или средние) тесты потенциально могут начать расти. Я стараюсь ограничить зависимости, где могу, но на этом уровне тестирования рост самого проекта обычно не является существенной проблемой.

End-to-end тесты (прим.: или верхнего уровня; «крупные»; также встречается термин «неразрывное» тестирование; а под самим термином часто понимают тестирование через внешние интерфейсы) – именно им практически всегда требуется дополнительное внимание в крупных проектах. Необходимы тесты, гоняющие и анализирующие всю систему целиком. И это уже совершенно нетривиально (как с точки зрения автоматизации, так и в понимании системы с позиции тестировщика). Так как часто большой проект – это системы внутри систем, написание качественного набора тестов, покрывающих существенную долю вариантов поведения пользователей, возможно, но далеко не так просто.

— По каким признакам можно понять, что с процессом тестирования то-то не так?

Алан Пейдж: Главным виновником в такой ситуации обычно являются «странные» или не слишком ненадежные тесты, и большую роль тут играет то, как команда обрабатывает ложно-положительные результаты (false positive). Если они могут достаточно быстро разобраться и понять, почему тест себя так ведет – поводов для беспокойств нет. А когда понимания нет, или, еще хуже, когда такие тесты просто игнорируются – это всегда должно вызывать подозрение, что что-то здесь явно не так.

Еще стоит обратить внимание (возможно, чем-то это связано с предыдущим аспектом), когда команда не прогоняет тесты регулярно. Будь это юнит-тесты перед check-in (~commit из SVN — прим. ред.), интеграционные тесты перед слиянием веток или end-to-end тесты перед релизом. Если команда не полагается на автоматические тесты при принятии бизнес-решения – вложиться ли в еще более масштабное тестирование, вот тут я начинаю подозревать, что, возможно, с их системой автоматического тестирования все еще хуже, чем я думал.

— Какие сейчас ключевые тенденции в автоматическом тестировании и где проходит граница между тестированием и разработкой?

Алан Пейдж: Думаю, что сегодня эта граница размыта как никогда. Тестеры из моей команды в порядке вещей фиксят баги в продакшене, и их коллеги разработчики пишут большую часть автоматических тестов (маленькие и средние тесты, про которые говорил чуть раньше). Я регулярно вижу, как тестеры плечом к плечу с разработчиками организуют мозговой штурм по тестам, тестят в паре и отлаживают вместе. Современный тестировщик – в роли специалиста по тестам и качеству в команде, занимающейся новыми функциями системы, для по-настоящему эффективной работы должен быть на этой размытой границе, и я думаю, что качество только возрастет от размытия этой границы.


Если тема тестирования вам близка так же, как и нам, наверняка вас заинтересуют вот эти доклады на нашей декабрьской конференции Heisenbug 2017 Moscow:

Интервью подготовлено при участии Сергея Парамонова varagian.

Автор: Алексей Городищев

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js