Алексей Баранцев, вероятно, один из самых известных людей в российском тестировании: его знают и по software-testing.ru, и по selenium2.ru, и по участию в Selenium WebDriver, и не только. При этом он ещё и один из наиболее опытных: в тестировании аж с 1994-го. И когда стало известно, что он выступит на нашей конференции Heisenbug с докладом «Заморочки в Selenium WebDriver», нам захотелось расспросить такого спикера. Начали с вопросов о том, чем тестирование в 90-х отличалось от сегодняшнего, а затем перешли к современным реалиям.

— Среди читателей интервью могут быть люди, которые ещё даже не родились, когда вы уже занялись тестированием. Расскажите, чем тогда всё отличалось от наших дней?

— Если говорить про какие-то основы тестирования (теорию, ключевые техники), то особых изменений нет. Но при этом автоматизация тестирования, конечно, постоянно меняется. Появляются и исчезают новые технологии разработки, а вместе с ними возникают или исчезают технологии и инструменты, предназначенные для тестирования ПО. Как можно сравнивать тестирование того, что было тогда, и того, что есть сейчас? Все равно, что сравнить, что лучше — раньше был SOAP, теперь REST. Тогда мы тестировали веб-сервисы, написанные с использованием SOAP, а сейчас те, что написаны с использованием REST. Да какая разница?

— Ну, некоторые технологии не просто «появились и исчезли», а стали тем, без чего теперь сложно представить индустрию: «Как мы вообще жили без Git?»

— Без Git нормально жили. Был CVS, прекрасно жили с ним, потом был Subversion, потом Git. Это все не так интересно, а вот что реально очень сильно поменялось — это скорость. Скорость разработки, а вместе с ней и скорость тестирования. Речь даже не о коротких итерациях, Agile, подходе к организации рабочего времени. Изменилась именно скорость разработки продукта.

Когда мы только начинали работать, в середине 90-х, у нас были проекты длительностью полгода, год, два года. Разработка и тестирование. Потом эти проекты начали сокращаться до трех месяцев, двух. По сути, за два месяца разрабатывалось то же самое, что раньше за год. А сейчас что происходит: люди приходят на хакатон, за день разрабатывают работающий продукт, тестируют его и запускают. Понятно, что это еще прототип, но тем не менее, за день. Это же помыслить себе нельзя было.

Почему так происходит? Конечно, инструменты развиваются. Но дело даже не в инструментах, некоторые и сейчас пишут код в vi или emacs. Важнее, что написано уже очень много готового кода, есть хорошие библиотеки, тщательно протестированные. Где-то по-прежнему нужно писать много своего кода, уникальные алгоритмы разрабатывать, и там по-прежнему всё происходит долго. Но в других ситуациях можно взять готовые компоненты, из них быстренько, как из конструктора, собрать готовый продукт. И, соответственно, тестировать его тоже проще, потому что собираем уже из надежных, проверенных компонентов. Вот это очень сильно поменялось.

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

— В 90-х и у разработчиков, и у тестировщиков было больше веры в стандарты. Собственно, Agile возник не на пустом месте, а как раз из-за разочарований во всех этих стандартах.

Во-первых, была мысль, что стандарты нас спасут от некачественного кода: мы будем писать всё в соответствии со стандартами, и всё будет хорошо интегрироваться, работать. Может быть, это даже правда, просто стандарты очень медленно разрабатываются, а всё очень быстро убегает вперед и устаревает раньше, чем стандарты приняты.

Во-вторых, была уверенность, что можно станет формально нарисовать схемы по UML-диаграммам, описать требования к ПО и автоматически сгенерировать исходный код, и всё это будет работать, а тестировать даже не нужно будет. Предполагалось, что скоро разработчики перестанут писать код, вместо этого они будут рисовать UML-диаграммы и описывать условия на каком-то высокоуровневом языке. Не взлетело, не получилось. Хотя в той тусовке, где я вращался, на это делались очень большие ставки.

Сейчас, наверное, пошла какая-то новая волна: отовсюду прорастает искусственный интеллект из всех мест, и опять возникает эта идея, что скоро разработчики не будут писать код. Вместо этого будут обучать какие-то системы искусственного интеллекта, и всё само будет работать. Соответственно, тестировщикам ничего не надо будет делать. Разработчики обучат искусственный интеллект, и он сам всё сделает. Посмотрим, как оно будет. Может, получится, как в прошлый раз.

— Перейдём к нашему времени. Вы занимаетесь сайтом software-testing.ru. Для тех, кто активно за ним не следит: что там происходит?

— Мы публикуем много контента, сейчас основная часть — переводной контент. Потому что, честно говоря, в России очень трудно найти авторов, пишущих о тестировании. Не знаю, почему так получилось: был какой-то момент, когда на русском писало много людей, а потом то ли у них горючее кончилось, то ли ещё по какой-то причине в рунете стало мало блогов и статей. А в англоязычной части интернета всё это по-прежнему цветёт, там пишется очень много статей.

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

— От текстов люди сейчас уходят ещё и к видеоблоггингу — а в тестировании такое есть?

— В тестировании этот тренд практически незаметен. Буквально есть один-два видеоблогера, единичные случаи.

— Есть выражение «Хочешь понять что-то по-настоящему — попробуй объяснить это другим». А когда систематически редактируешь чужие тексты, начинаешь ли лучше разбираться в теме, включая уголки, куда сам бы не заглянул? Полезно ли тестировщику быть ещё и редактором?

— Редакторская работа достаточно сильно отличается от читательской. Задача редактора заключается не в том, чтобы понять, что написано в тексте, а скорее в том, чтобы не пропустить огрехи. Честно говоря, это не способствует целостному взгляду. Когда мы выбираем материал, я больше смотрю на него как читатель: интересно это прочитать или нет. В этот момент я ещё не редактор. А вот когда смотрим переведённый текст и готовим к публикации, то в этом случае как редактор. Чтобы во время редактирования, во время подготовки к публикации, что-то понял — такого не бывает. Так что разные режимы: один режим — редактора, другой — читателя.

— Нескромный вопрос. На software-testing.ru есть баннерная реклама, но в обычной журналистике монетизироваться с её помощью трудно — а в случае с тестированием лучше, или у вас это тоже не компенсирует трудозатраты и сайт существует из любви к искусству?

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

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

— Тут работает принцип, который вы упомянули чуть раньше: пока кому-то что-то объясняешь, сам что-то поймешь. Это действительно помогает лучше понять, разобраться. Когда первый раз рассказываешь какую-то тему, то кажется, что всё понятно. А потом свои лекции смотришь, понимаешь, что можно лучше рассказать, переделываешь, появляются какие-то новые вещи. Я после этого иногда какие-то дополнительные статьи пишу: сначала готовишь материал для курса, а потом понимаешь, что нужно что-то ещё дописать, чтобы было понятнее. И, конечно, ещё интереснее получать какую-то обратную связь. Люди тоже что-то интересное рассказывают. Тебе задают какой-то внезапный вопрос, и только тут ты понимаешь, что не понимаешь. И что вообще не думал, что об этом надо подумать. Вот это ценно.

— Когда учишь многих людей, то начинаешь замечать какие-то типичные для многих людей ошибки. Можете ли вы сформулировать какую-то общую «типичную ошибку тестировщика»?

— Типичная ошибка вообще любого человека заключается в том, что большинство людей в IT пытаются всё познать на собственном опыте, пройтись по всем граблям. С моей точки зрения, логичнее двигаться другим путем: изучить что-то, и только после этого приступать к выполнению работы.

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

— Теперь хочется поспрашивать о Selenium. Как попадают в комьюнити разработчиков Selenium Driver и всей экосистемы вокруг него? Есть ли там какие-то ступени и ачивки? Например, «сделай десять пулл-реквестов и переходи на следующую ступень».

— Нет никакой стандартной процедуры, никаких регламентов, никаких конкретных критериев отбора. Все полностью индивидуально. Когда видно, что человек уже вовлёкся, то ему постепенно дают больше прав. Этот процесс входа происходит у всех по-разному. Кто-то начинает править баги и отправляет пулл реквесты. А кто-то начинает отвечать пользователям в мейлинг-листе: у нас есть ответственный за работу с пользователями человек, у которого нет вообще ни одного коммита в код, зато он фактически держит на себе мейлинг-лист. Кто-то пишет документацию —
это задача, которая тоже предполагает работу с исходным кодом, но, конечно, большинство людей воспринимают участие в проекте именно с пулл-реквестами.

С пулл-реквестами есть организационная проблема, связанная с тем, что у нас не хватает рабочих рук, поэтому пулл-реквесты могут очень долго лежать, и их никто не рассматривает. Поэтому нужно проявлять настойчивость, чтобы тебя заметили. Нужно не просто отправить пулл-реквест, нужно его пробить. Тем, кто пробивается сквозь этот фильтр, удаётся потом постепенно войти в проект.

— А кому писать, чтобы пробиться?

— Да всем писать. В IRC-чате попросить оценить пулл реквест. В общем, есть нетехнические фильтры, через которые постепенно человек проникает. А если сделал пулл-реквест и ждешь, пока пригласят в проект, то нет, не пригласят.

— Интуитивно хочется предположить, что если разрабатывается очень популярный среди тестировщиков инструмент, то он сам протестирован гораздо тщательнее, чем среднестатистический IT-проект. Пример Selenium подтверждает это или нет?

— Я не знаю насчёт «среднестатистического проекта», но Selenium действительно протестирован довольно тщательно. Тестов много, тесты постоянно работают, постоянно находят баги, в том числе регрессионные баги, в том числе регрессионные баги в браузерах. Я регулярно пишу баг-репорты разработчикам браузеров.

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

— Часто идут споры «какой браузер лучше», и раз вы отправляете им баг-репорты, интересно сравнить с нестандартной стороны: у каких браузеров команда лучше реагирует на баг-репорты, а у каких хуже?

— Мне не хотелось бы никого обижать, поэтому критиковать я никого не буду, зато похвалить могу. Лучше всего реагируют разработчики Firefox. Они самые вовлечённые, самые активные с точки зрения работы с баг-репортами. Что, возможно, как раз соответствует их опенсорсному духу.

А самое раздражающее — это не реакция команд на баг-репорты. Это то, что у компаний, разрабатывающих браузеры с закрытым кодом (Microsoft, Apple), закрытый баг-трекер. То есть при встрече с багом не можешь посмотреть, отправлял ли кто-то уже такой баг-репорт, известный ли это баг.

— Несколько лет назад вы говорили, что задача Selenium — стать веб-стандартом. Он стал, а что дальше? Какая следующая большая веха?

— Захватить мир в лице инструментов автоматизации. То есть нужно добиться, чтобы все этот новый стандарт поддерживали.

— То есть стать встроенным модулем для всех других новых инструментов автоматизации UI?

— Да. То есть они могут использовать еще десять других модулей, но они все должны уметь работать через стандартный протокол.

Внутри Selenium есть следующая важная задача, которая будет решаться сначала какими-то прототипными реализациями, а затем в рамках стандарта. Протокол HTTP принципиально односторонний, то есть одна сторона посылает запросы, другая их обрабатывает, и обратной связи практически никакой нет. И это не очень хорошо, и здесь как раз конкуренты на это очень активно указывают, давят на эту больную мозоль, потому что хотелось бы, грубо говоря, иметь коллбэки. Когда в браузере какие-то события происходят, хотелось бы, чтобы приходили какие-то оповещения об этом. Этого в инструменте Selenium пока нет. Но мы очень хотим это добавить. Так что, возможно, будут проходить кардинальные изменения, возможна смена протокола. Без этого будет уже трудно. Нужен двухсторонний протокол.

— Вы и Саймон Стюарт являетесь ключевыми контрибьюторами Selenium, так?

— Это так, если говорить про Java-часть.

— Насколько мне известно, вы при этом никогда не встречались. Как так вышло? У разработчиков Selenium не бывает каких-нибудь «корпоративов»?

— «Корпоративы» у нас бывают в виде встреч на конференциях, а отдельно — нет. И в случае с конференциями Саймон даже в Москву приезжал на прошлогодний Heisenbug, но меня в Москве в этот момент не было, поэтому не пересеклись.

Но, честно говоря, мы сейчас живем в таком мире, что ничего страшного, все равно же постоянно общаемся.

— Общий вопрос напоследок. Как вам кажется, каким будет будущее автоматизации тестирования в целом и UI в частности?

— Я не люблю делать прогнозы, потому что они практически никогда не сбываются. Тестирование идёт за разработкой с некоторым отставанием, плетётся. Поэтому моду диктуют разработчики: они дружно ломанулись на JS — в тестировании тоже все дружно ломанулись в JS. И нам надо будет соответствовать изменениям. А что там у разработчиков будет — кто его знает.

Алексей выступит на московском Heisenbug, проходящем 6-7 декабря — и помимо него, там будут десятки других докладчиков. На сайте Heisenbug можно и увидеть полную программу, и приобрести билет.