Хабрахабр

«Считалось, что код заменят UML-диаграммы, а тестировать станет не нужно»: интервью с Алексеем Баранцевым

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть