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

Но сначала несколько фактов из его биографии. Автоматизацией тестирования Алан Пейдж занимается уже почти 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 ^[1], в связи с чем мы поспешили его расспросить его о главных признаках необходимости перехода к автоматизации всего и вся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

• Truths about technical testing ^[4] (Alan Page, Unity)
• Автотесты в World of Tanks: боты на страже качества ^[5] (Александр Шуков Wargaming.net)
• Тестирование геолокации в Badoo: шишки, камни, костыли и селфи-палка ^[6] (Александр Хозя и Николай Козлов, Badoo)
• Как проверить систему, не запустив ее ^[7] (Андрей Сатарин, Яндекс)

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

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

Источник ^[9]