Я подозревал, что неправильно понимаю слово "нетворкинг" в данном контексте, но не знал о существовании именно нетворкинг-мероприятий. Думал, что это общение до, между и после докладов с участниками митапа (пункты 3 и 4 о спикерах, возможно, укрепили моё невежество). Спасибо, что объяснили.
Возможно, имеет смысл поподробнее рассказать про разные типы мероприятий и какие советы к каким именно типам относятся. Потому что, судя по абзацу из первого комментария о
Знакомство людей на нетворкинге — очень неоднозначно.
я не единственный, кто Вас неправильно понял. Надеюсь, не сочтёте за претензию.
посыл верный, а вот пункты и предложения какие-то странные
У меня сложилось такое же впечатление.
ElKornacio несколько раз сделал акцент на пользе для участников. Но у меня появилось ощущение, что моя "польза" не совпала с "пользой", которую помогает достичь автор. Например, я узнал себя в негативном примере
На нетворкингах интроверты смотрят в телефоны и уходят, не раскрывшись, без новых знакомств
и хотел бы поделиться, как зачастую это выглядит с моей стороны:
я увидел интересную тему и захотел послушать доклад. Но я не собирался заводить новых знакомств.
я делюсь интересными вещами с коллегами (которых я уже знаю) и пишу им про ту крутую идею/библиотеку/технологию, о которой мне прямо сейчас рассказывают. Поэтому я смотрю в телефон, а не на докладчика. Это могут быть сообщения типа: "сижу-слушаю про hypothesis — давай попробуем на хакатоне, который планируется в компании через месяц?"
мне не всегда есть, что сказать. Поэтому я могу присоединиться к толпе разговаривающих людей, но промолчать почти весь вечер. При этом мне интересно послушать, как компетентные люди обсуждают сложную (или не очень) тему.
В итоге, я вроде бы и согласен с автором, но сам бы избегал митапов с описанной модерацией. Возможно, кроме ожидаемого уровня аудитории, о котором говорит TheGodfather, имеет смысл ещё явно описывать модерацию на митапе, типа:
участники будут разделены на группы, чтобы стимулировать нетворкинг.
возможны интерактивы и/или игры с участниками.
вопросы могут быть изменены или дополнены модератором.
Резкие, самодовольные фразы в стиле "этот болван четыре раза пробежался по коллекции, хотя можно было один", и тому подобное.
а Ваш комментарий, который, мне кажется, напоминает фразу "эти болваны, наверно, написали сервер на питоне, хотя можно было взять <высокопроизводительный язык>", получает только положительные оценки.
Допускаю, что я предвзят (сам люблю питон), и Ваш комментарий не осуждает использование питона в серверной разработке.
Не являюсь экспертом по статическим анализаторам, но очень люблю pylint, хотя моё первое впечатление было очень похоже на мнение автора оригинальной статьи. Мне кажется, прелесть pylint'а в том, что он хорошо подходит, чтобы задавать правильные вопросы, а не требовать немедленно что-то исправить.
Во-первых, многие сообщения содержат альтернативы. Например,
no-self-use: Method could be a function Used when a method doesn’t use its bound instance, and so could be written as a function.
Можно задуматься: "Ok. Если я вынесу это в функцию, какие будут последствия". Лично мне это помогает: иногда приходит понимание, что класс вообще не нужен, или метод должен быть явно объявлен статическим. Естественно, бывают и ситуации, когда приходится оставлять, как есть (например, для callback'ов в kivy).
Во-вторых, pylint имеет несколько уровней сообщений: error, warning, refactor, convention (возможно, какие-то упустил). Ни для кого не будет секретом, что все сообщения имеют код, начинающийся с буквы соответствующего уровня (например, R0801 для duplicate-code), но не все знают, что pylint формирует код возврата в зависимости от наличия сообщений той или иной группы: 1 группа — 1 бит. Мы это использовали, чтобы автоматически блокировать merge, если pylint находит ошибки (errors) или предупреждения (warnings), исходя из (status_code | 3). В итоге, у нас прикручен автоматический статический анализ, и именно команда решила, какие проблемы кода считать блокирующими.
Мне понравилось, что автор отметил несколько тонких моментов, таких как no-member, но смутил вывод по этому поводу. На всякий случай напишу, чтобы люди не отказывались от pylint'а из-за этого. Иногда модули создаются динамически, и pylint не может делать выводы на их основе (не знаю, как к этому относятся другие анализаторы кода). Эту проблему можно встретить, например, для sqlalchemy или pyvmomi. Но будет неправильным делать вывод, что настоящие ошибки no-member "утонут" среди ложных срабатываний из-за обращения к sqlalchemy. В конфиге pylint'а есть отдельная секция TYPECHECK, где можно указать динамически сгенерированные атрибуты или исключить классы и модули из проверки. Поэтому, мне кажется, что автор зря выгоняет pylint
Если бы Pylint был моим коллегой, помогающим делать ревью кода, я бы умолял его уйти.
Вы ведь не выгоняете коллегу, чьим комментариям не собираетесь следовать, а объясняете, почему не считаете изменения необходимыми?
Второй тонкий момент — это анализ тестов. Как автоматизатор тестирования, тоже часто обращаю на это внимание. Глобальных проблем в общем-то две. Первая — это duplicate-code. Выбирая между стремлением к "1 тест — 1 проверка" и DRY, я в 100% случаев выберу первое. Pylint достаточно (возможно, слишком) чувствителен к похожему коду и, к сожалению, не предоставляет возможности этим управлять так же, как другими сообщениями. Вторая проблема связана с фреймворками тестирования. Большинство проектов используют либо unittest, либо pytest. Первый был вдохновлён фреймворком из Java (jUnit?), поэтому там всё завязано на классах, что действительно приводит к их избыточности (too-many-public-methods и, подозреваю, too-many-ancestors). Переход на pytest поможет избавиться от этих сообщений, но привнесёт redefined-outer-name из-за фикстур, которые передаются, как аргументы другим фикстурам и тестовым функциям. В любом случае, это объективная реальность, о которой pylint Вам будет сообщать.
В некоторых пунктах мне показалось, что автор лукавит. В статье не так много кода, поэтому предметно не поговорить. Но, в частности, в примере с
foo, bar = get_some_stuff()
мне не понятно, почему не убрать неиспользуемую bar так
foo, _ = get_some_stuff()
или так
foo = get_some_stuff()[0]
С docstring'ами, мне кажется, тоже есть доля лукавства. Docstring подаётся, как аналог комментария к неочевидному куску кода. Но это ведь в большинстве случаев не так: даже для очевидных функций docstring может дать дополнительные детали, такие как варианты использования и doctest'ы, не говоря уже об аргументах и возвращаемых значениях: современные IDE прямо из коробки умеют их парсить и использовать, как альтернативу type hint'ам.
Боюсь показаться токсичным, но хотел бы показать, как бы на Ваш спор про random(0, 1000) посмотрел бы отдел обеспечения качества:
Разработчик написал тесты. Видимо, даже применил какую-то теорию (осознанно или случайно): граничные значения, рандомизацию для избежания т.н. эффекта пестицида. Вроде хорошо. Но
разработчики тратят день на то, чтобы договориться (на самом деле, сцепиться языками) по поводу раздомизации притом, что у нас
есть более серьёзные проблемы с точки зрения качества продукта и процесса, а именно
проблема рандомно валящихся билдов
билд итак занимал четыре часа
пулл реквест твой никто и не посмотрит, пока он не прошёл CI
Насколько я понял из статьи, команда понимала плюсы рандомизации, но не могла её принять из-за "объективной реальности", обусловленной проблемами из п. 3. Лично для меня это выглядит достаточно странным, потому что обычно, когда кто-то говорит об улучшении процесса, обязательно вспоминают словосочетания типа "шаг за шагом", "baby steps" и "итеративно". И в данной ситуации рандомизация — это такой же "baby step", который не ухудшает ситуацию сейчас и улучшит процесс, когда билды будут быстрее и надёжнее, но команда не готова его принять. Я понимаю, это связано ещё и с
Ты должен сесть, и посчитать, как долго просуществует проект, в какую сторону он пойдёт ...
но, судя по описанию обсуждения, команда скорее обсуждала уровень владения английским, но не откладывание этого "шажка" в пользу более приоритетных.
К сожалению, часто вижу подобную ситуацию. Иногда мне кажется, что разработчики считают себя достаточно компетентными в (авто)тестировании только потому, что они пишут юнит-тесты. Зачастую оказывается, что это даже не тесты, а код, который просто вызывает функции, модули и компоненты для обеспечения 80% покрытия продуктового кода. На моей практике был случай, когда разработчики увлеклись mock'ами настолько, что в юнит-тестах одни mock'и тестировали другие. Естественно, пользы от такого "тестирования" очень мало.
Прошу прощения, если задел кого-нибудь подобным комментарием. Посыл не в том, чтобы сказать: "команда автора — сплошь джуны и не умеют работать", а в том, что в разных областях есть специалисты и эксперты, и важно понять, когда нужно делегировать принятие решения им. И к сожалению, зачастую отделы разработки и управления не понимают, что тестировщики и отдел качества — это не просто люди для нахождения багов и приёмочного тестирования по stories в Jira.
Разница во времени появлялась из-за того, что пункт 1 (обновление антивируса) был очень тяжёл для автоматизации. Вот несколько проблем, которые легко решаются вручную, но сложны в автоматизации:
Какие-то антивирусы не предоставляли возможность конфигуации/обновления на клиенте — это означает, что надо каким-то образом тригернуть обновление с серверной компоненты.
Антивирусы не склонны, по понятным причинам, предоставлять возможность конфигурации/обновления извне (CLI, например). У некоторых антивирусов есть возможнось импортировать настройки, за что им огромное спасибо. У большинства (по крайней мере, на тот момент) вся конфигурация жила в кастомных UI. Это касается и серверных компонент из предыдущего пункта.
Обновление лицензии. Если лицензия кончилась, человек знает, что делать. А для автотестов это, естественно, головная боль.
В конечном итоге, мы автоматизировали тесты только для тех антивирусов, для которых нашли надёжные решения проблем выше (осталось примерно 3-4 штуки). Сам процесс стал другим:
Установка антивируса на чистую машину.
Установка/выбор триальной лицензии.
Обновление модулей.
Запуск автотестов.
В данном случае получилось ещё избавиться от хранения машин с антивирусами и сэкономить на лицензиях (жаба особенно душила покупать лицензии, чтобы использовать раз в месяц). Но, естественно, пришлось провести анализ модулей, которые присутствуют в триальной лицензии, чтобы понимать, что тестирование совместимости действительно имеет смысл.
Плюс ещё получилось иметь возможность тестировать разные версии одного антивируса (процесс установки редко меняется).
Естественно, этот процесс намного медленнее пункта 1 (обновление антивируса вручную), даже с учётом того, что пункты 2, 5 и 6 (управление снепшотами) больше не нужны.
Надеюсь, достаточно подробно ответил на Ваши вопросы.
Насколько я понимаю, у нас с Вами разное понимание smoke-тестирования. Возможность выполнить один из самых основных юзкейсов, на мой взгляд, это тоже часть smoke-сценариев (проверил заодно, что ISTQB думает по этому поводу). Судя по
Smoke-тест должен проверить, что все работает на выходе и не сломалось минимально. Совсем примитивный smoke-тест о том, что система запустилась и как-то работает, в нашем случае не приносит никакой пользы. Допустим, мы проверили, что подключение к базе есть, что-то запускается, UI получает какой-то API. А потом шаг влево, шаг вправо — и ничего не работает. То есть smoke-тест как бы есть, но с продакшена все равно летят ошибки.
команда Юлии тоже воспринимала smoke, как к проверку на "невозможность выполнить никакие юзкейсы", и это не приносило практической пользы. И в итоге, проблема была решена unit-тестами, что хорошо (shift-left, все дела).
В целом, я вроде понял, про какие тесты Вы говорите. Кажется, это то, про что я написал "лишь малая часть тестирования" в предыдущем комментарии. Дискуссия оказалась только о терминологии.
Мне кажется, это очень однобокий взгляд на Smoke-тесты. Взять ваш же пример со страничкой гугла. Вы делаете акцент на "что-то похожее", наверное, потому, что всё-таки готовы к каким-то изменениям на странице. Проблема в том, что очень трудно понять, когда изменения позитивные, а когда негативные. Например, зайдёт такой "умный" тест на страничку гугла, а поисковой строки не будет вовсе. "Достаточно похоже", — подумает алгоритм, и тест пройдёт. Если Вы думаете, что поисковая строка слишком большой элемент, чтобы его проигнорировать, представьте интернет магазин, у которого удалили кнопку + ("плюс") для добавления товара в корзину. Ничего купить нельзя, зато мы сэкономили время на написании Smoke-тестов.
На моей практике, все попытки масштабной автогенерации тестов сводятся к фразе: "ну мы же не обязаны использовать только сгенерированные тесты!". Это правда, и по факту данные сгенерированные тесты занимают лишь малую часть тестирования, и уж точно не способны целиком заменить smoke-тестирование.
Обычно сгенерированные тесты оказываются хороши для каких-то специфических проверок, в тех случаях, когда никакого интеллекта не нужно, но объём тестов либо очень большой, либо динамически меняется. Например, если команда делает конструктор для создания страниц компании в одинаковом стиле. Имея список созданных страниц, может быть полезно при релизе пройти по ним и проверить, что ни одна из них не возвращает 500.
В большинстве случаев время прохождения автотеста меньше времени ручного тестирования. Но это не значит, что если это не так, то это что-то странное. Потому что не совсем корректно сравнивать машиночасы с человекочасами.
У меня было несколько примеров на практике: тестирование совместимости и compliance testing (прошу прощения, не знаю, как это нормально переводится на русский). Представьте, что у вас есть приложение, которое теоретически может конфликтовать с антивирусами (драйвера, системные перехваты и т.п.). Скорее всего вам придётся регулярно проводить тестирование на машинах с разными антивирусами. Ручные тестировщики делают это так: держим машины с установленными антивирусами, а сам процесс тестирования выглядит следущим образом:
обновляем версию антивируса, устанавливаем последние модули проверки;
делаем новый снепшот машины для следующего прогона;
устанавливаем наш продукт;
тестируем;
откатываем на снепшот;
удаляем самый старый снепшот для экономии ресурсов.
В данном случае тестирование очень небольшое, потому что нам достаточно буквально несколько (максимум пару десятков) тест-кейсов, чтобы убедиться, что не возникают deadlock'и или прочие конфликты с антивирусом. В итоге оказывается, что большую часть времени тестировщики тратят на пункты 1, 2 и 5, 6, т.е. те, которые с нашим продуктом вообще не связаны.
К сожалению, в то время, когда я этим занимался, руками обновлять или конфигурировать антивирусы было в 100 раз проще, чем надёжно автоматизировать (попробуйте надёжно кликнуть кнопку "Обновить" в кастомных GUI под Windows).
В итоге, в данном случае пожертвовать временем ради освобождения ручных тестировщиков будет вполне себе разумной идеей. Автотесты автономно гоняются раз в неделю, пусть это даже будут 2 машинодня по выходным и 2 человекачаса в понедельник на разбор результатов. И это будет примерно в 4 раза лучше чем 1 человекодень каждую неделю.
Аналогичная история с compliance'ом: если вам раз в месяц нужно проверить совместимость с обновлениями Windows, освобождение ручных тестировщиков от этой задачи будет ценнее сэкономленных машиночасов. Да и если посмотреть, то подобных задач не так уж и мало. Другой вопрос, что в большинстве своём они связаны с нефункциональными требованиями, куда автоматизация не всегда успевает (или физически может) добраться, кроме, может быть, требований производительности и надёжности под нагрузкой.
Большое спасибо за интервью и за вопрос про Juggler в частности.
Честно говоря, не очень понятно, как команда позиционирует Juggler. С одной стороны, насколько я понял из интервью, Juggler — это протокол именно для FF, который только идеологически связан с CDP, т.е. решает схожие задачи, но не обязательно схожим образом, поскольку некоторая часть протокола очень тесно связана с самим Chrome'ом и фактически не может быть кроссбраузерной.
С другой стороны, Juggler похож на CDP, и Андрей упомянул, что они работают над долгосрочным API. Будет ли это API поверх CDP/Juggler, или Juggler и будет основой для данного API? Будет ли оно кроссбраузерным?
Мне кажется, это важный вопрос для будущих инструментов. Например, если кто-то захочет создать библиотеку на Python, в каком направлении ему следует двигаться?
Библиотека реализует общие методы, которые под капотом используют CDP/Juggler в зависимости от браузера.
Библиотека реализует клиента для кроссбраузерного API.
Библиотека коммуницирует с playwright, запущенным на node js.
По поводу недоверия к пропатченным браузерам: на мой взгляд, проблема не столько в боязни за Rendering Engine. Представьте, что у нас есть веб приложение, и пользователи завели баг для определённой версии браузера (например, баг воспроизводится в FF версии < 70). В итоге мы создаём тест для регресса и гоняем автотесты и для новой версии FF, и для старой. Поскольку, насколько я это понимаю, определённая версия Playwright'а использует свою фиксированную версию браузера, мне, как автоматизатору, теперь необходимо придумать, как прикрутить использование нескольких версий Playwright'а в автотестах: возможно, всё решается разными контейнерами или виртуальными машинами для каждой версии, но, опять же, инфраструктурные затраты несравнимо больше, чем запуск разных версий с одной машины. Не стоит ещё забывать, что в данном случае мы ещё надеемся, что наши тесты совместимы с обеими версиями Playwright'а, особенно если протокол не менялся между версиями.
С другой стороны, проблемы разделения Playwright и браузеров тоже понятны: наверняка, у всех была ситуация, когда при работе с selenium'ом возникала проблема совместимости вебдрайвера с соответствующим браузером из-за различия в версиях.
Желаю удачи и успеха команде и проекту Playwright. Хочется верить, что это будущее автоматизации веб тестирования.
Большое спасибо за статью. Подскажите, пожалуйста, сколько времени прошло от первой попытки до текущего результата? Прошу прощения, если упустил это в статье.
Часто сталкиваюсь с ситуацией, когда компания страдает от недостатка автоматизации и нанимает сеньора/лида/команду со словами "мы хотим, чтобы вы сделали, как надо". Однако потом оказывается что-то в духе "у нас уже есть 5 E2E ручных тестов, которые мы гоняем раз в месяц, но хотим ежедневно. Осталось только заскриптовать." Или, что ещё хуже: "наши эксперты-программисты уже написали фреймворк для вас, но у них нет времени поддерживать, пока этим занимаются ручные тестировщики, но они тоже начали жаловаться на недостаток времени". И в том, и в другом случае команда автоматизации тратит больше времени не на то, чтобы "сделать, как надо", а на то, чтобы объяснить, что текущие практики не соответствуют (физически не могут, к сожалению) ожидаемым результатам, и показать (читай "продать") те baby steps, которые приведут к качественным изменениям. При этом менеджеры искренне удивляются, почему нанятые специалисты до сих пор не могут сделать автоматизацию стабильной. Достаточно типичным является диалог, когда автоматизатор предупреждает, что данная попытка приведёт к ситуации
"стабильности запусков не было и понимания, как это сопровождать — тоже"
на что менеджеры говорят что-то в духе "откуда ты знаешь — ты же не пробовал в нашей компании? Не сравнивай нас с другими — мы другая компания". Фактически, автоматизаторов просят пройти весь путь от первого подхода и первой попытки заново.
Данная статья хорошо показывает реальный опыт прохождения этого пути. Я искренне надеюсь, что она поможет компаниям осознать, сколько времени и ресурсов уходит на "попробовать" и прийти к тому, с чего они могли бы сразу начать.
Мне тоже было интересно, чем Playwright отличается от других инструментов. Я поизучал вопрос, и теперь мне кажется, что достижение команды разработчиков Playwright намного больше, чем новая библиотека на node js для UI автотестов.
CDP (Chrome DevTools protocol) находится "ближе" к хрому, чем Selenium, поэтому он предоставляет больше информации и возможностей в работе с браузером. Проблема в том, что протокол был сделан для хрома, а тестировать веб приложения хочется в том числе и в ФФ. И огромная заслуга команды Puppeteer и Playwright в том, что они фактически провоцируют объединение и стандартизацию данного (подобного?) протокола для браузеров. Вот, например, тикет с обсуждением https://bugzilla.mozilla.org/show_bug.cgi?id=1512337
Стоит отметить и отношение Mozilla к этому вопросу (из https://bugzilla.mozilla.org/show_bug.cgi?id=1512337#c10):
Not supporting Puppeteer also poses significant web interoperability
risk to Mozilla. As websites migrate automation to Puppeteer, the
lack of cross-browser support in many cases leaves Firefox untested,
forcing Firefox to play a catch-up game addressing web compatibility
issues.
Simultenously Mozilla’s ambitions stretch beyond Puppeteer’s feature
set. Puppeteer is backed by the Chrome DevTools Protocol (CDP), which
also drives an armada of other tools. The simlarities between the
Juggler protocol presented in this patch and CDP are uncanny, and we
believe that it is in the best interest of the open web for us to
instead implement the subsets of CDP that allows us to support the
Puppeteer API surface.
Playwright использует свой протокол для ФФ (Juggler), который, если я не ошибаюсь, похож на CDP, но тем не менее отличается от него и, соответственно, от remote protocol, который официально будет поддерживать Mozilla. С чисто прагматической точки зрения, использование Playwright сейчас для ФФ выглядит достаточно рискованно: кажется сомнительным, что браузер будет поддерживать и remote protocol, и juggler, поэтому можно ожидать, что и протокол, и внутренности playwright будут меняться (см. также https://wiki.mozilla.org/Remote/Meetings/2020/01/24#Minutes). Скорее всего, этот процесс не обойдётся без интеграционных проблем.
Резюмируя, хочется сказать огромное спасибо команде разработчиков. Благодаря их работе в области CDP-подобного протокола, мы можем ожидать, что появятся библиотеки и на других языках, что сильно облегчит многие задачи автоматизации тестирования.
Было бы ещё интересно узнать от самих разработчиков детали Juggler (https://github.com/puppeteer/juggler ?), его отличия от CDP и планы развития.
Хабр Документация.
Сервис для хостинга документации типа https://readthedocs.org/ с возможностью задавать вопросы авторам проектов в комментариях. Авторы в свою очередь могут:
обновить документацию и отметить вопрос решённым (resolved). Например, если в документацию забыли внести изменения последнего релиза.
ответить на вопрос и закрепить комментарий. Такие комментарии становятся частью документации. Например, примеры использования, неочевидные ограничения и т.п.
Думаю, ещё одним преимуществом может стать поиск по тематике. Часто приходится искать инструменты без привязки к языку программирования. Объединённый сервис может решить задачи списков вроде https://github.com/atinfo/awesome-test-automation, потому что их не надо будет обновлять вручную.
Комментарии и рейтинг, как и любая обратная связь, могут (теоретически) улучшить качество документирования проектов в среднем.
Спасибо большое за наводку! Действительно похоже на то, что нужно. Если несложно, поделитесь, пожалуйста, опытом использования: есть ли минусы, на которые стоит обратить внимание, или же, наоборот, запустил и работает?
Я подозревал, что неправильно понимаю слово "нетворкинг" в данном контексте, но не знал о существовании именно нетворкинг-мероприятий. Думал, что это общение до, между и после докладов с участниками митапа (пункты 3 и 4 о спикерах, возможно, укрепили моё невежество). Спасибо, что объяснили.
Возможно, имеет смысл поподробнее рассказать про разные типы мероприятий и какие советы к каким именно типам относятся. Потому что, судя по абзацу из первого комментария о
я не единственный, кто Вас неправильно понял. Надеюсь, не сочтёте за претензию.
У меня сложилось такое же впечатление.
ElKornacio несколько раз сделал акцент на пользе для участников. Но у меня появилось ощущение, что моя "польза" не совпала с "пользой", которую помогает достичь автор. Например, я узнал себя в негативном примере
и хотел бы поделиться, как зачастую это выглядит с моей стороны:
В итоге, я вроде бы и согласен с автором, но сам бы избегал митапов с описанной модерацией. Возможно, кроме ожидаемого уровня аудитории, о котором говорит TheGodfather, имеет смысл ещё явно описывать модерацию на митапе, типа:
Есть некоторая ирония в том, что статья осуждает
а Ваш комментарий, который, мне кажется, напоминает фразу "эти болваны, наверно, написали сервер на питоне, хотя можно было взять <высокопроизводительный язык>", получает только положительные оценки.
Допускаю, что я предвзят (сам люблю питон), и Ваш комментарий не осуждает использование питона в серверной разработке.
Не являюсь экспертом по статическим анализаторам, но очень люблю pylint, хотя моё первое впечатление было очень похоже на мнение автора оригинальной статьи. Мне кажется, прелесть pylint'а в том, что он хорошо подходит, чтобы задавать правильные вопросы, а не требовать немедленно что-то исправить.
Во-первых, многие сообщения содержат альтернативы. Например,
Можно задуматься: "Ok. Если я вынесу это в функцию, какие будут последствия". Лично мне это помогает: иногда приходит понимание, что класс вообще не нужен, или метод должен быть явно объявлен статическим. Естественно, бывают и ситуации, когда приходится оставлять, как есть (например, для callback'ов в kivy).
Во-вторых, pylint имеет несколько уровней сообщений: error, warning, refactor, convention (возможно, какие-то упустил). Ни для кого не будет секретом, что все сообщения имеют код, начинающийся с буквы соответствующего уровня (например, R0801 для duplicate-code), но не все знают, что pylint формирует код возврата в зависимости от наличия сообщений той или иной группы: 1 группа — 1 бит. Мы это использовали, чтобы автоматически блокировать merge, если pylint находит ошибки (errors) или предупреждения (warnings), исходя из (status_code | 3). В итоге, у нас прикручен автоматический статический анализ, и именно команда решила, какие проблемы кода считать блокирующими.
Мне понравилось, что автор отметил несколько тонких моментов, таких как no-member, но смутил вывод по этому поводу. На всякий случай напишу, чтобы люди не отказывались от pylint'а из-за этого. Иногда модули создаются динамически, и pylint не может делать выводы на их основе (не знаю, как к этому относятся другие анализаторы кода). Эту проблему можно встретить, например, для sqlalchemy или pyvmomi. Но будет неправильным делать вывод, что настоящие ошибки no-member "утонут" среди ложных срабатываний из-за обращения к sqlalchemy. В конфиге pylint'а есть отдельная секция TYPECHECK, где можно указать динамически сгенерированные атрибуты или исключить классы и модули из проверки. Поэтому, мне кажется, что автор зря выгоняет pylint
Вы ведь не выгоняете коллегу, чьим комментариям не собираетесь следовать, а объясняете, почему не считаете изменения необходимыми?
Второй тонкий момент — это анализ тестов. Как автоматизатор тестирования, тоже часто обращаю на это внимание. Глобальных проблем в общем-то две. Первая — это duplicate-code. Выбирая между стремлением к "1 тест — 1 проверка" и DRY, я в 100% случаев выберу первое. Pylint достаточно (возможно, слишком) чувствителен к похожему коду и, к сожалению, не предоставляет возможности этим управлять так же, как другими сообщениями. Вторая проблема связана с фреймворками тестирования. Большинство проектов используют либо unittest, либо pytest. Первый был вдохновлён фреймворком из Java (jUnit?), поэтому там всё завязано на классах, что действительно приводит к их избыточности (too-many-public-methods и, подозреваю, too-many-ancestors). Переход на pytest поможет избавиться от этих сообщений, но привнесёт redefined-outer-name из-за фикстур, которые передаются, как аргументы другим фикстурам и тестовым функциям. В любом случае, это объективная реальность, о которой pylint Вам будет сообщать.
В некоторых пунктах мне показалось, что автор лукавит. В статье не так много кода, поэтому предметно не поговорить. Но, в частности, в примере с
мне не понятно, почему не убрать неиспользуемую bar так
или так
С docstring'ами, мне кажется, тоже есть доля лукавства. Docstring подаётся, как аналог комментария к неочевидному куску кода. Но это ведь в большинстве случаев не так: даже для очевидных функций docstring может дать дополнительные детали, такие как варианты использования и doctest'ы, не говоря уже об аргументах и возвращаемых значениях: современные IDE прямо из коробки умеют их парсить и использовать, как альтернативу type hint'ам.
Боюсь показаться токсичным, но хотел бы показать, как бы на Ваш спор про random(0, 1000) посмотрел бы отдел обеспечения качества:
Насколько я понял из статьи, команда понимала плюсы рандомизации, но не могла её принять из-за "объективной реальности", обусловленной проблемами из п. 3. Лично для меня это выглядит достаточно странным, потому что обычно, когда кто-то говорит об улучшении процесса, обязательно вспоминают словосочетания типа "шаг за шагом", "baby steps" и "итеративно". И в данной ситуации рандомизация — это такой же "baby step", который не ухудшает ситуацию сейчас и улучшит процесс, когда билды будут быстрее и надёжнее, но команда не готова его принять. Я понимаю, это связано ещё и с
но, судя по описанию обсуждения, команда скорее обсуждала уровень владения английским, но не откладывание этого "шажка" в пользу более приоритетных.
К сожалению, часто вижу подобную ситуацию. Иногда мне кажется, что разработчики считают себя достаточно компетентными в (авто)тестировании только потому, что они пишут юнит-тесты. Зачастую оказывается, что это даже не тесты, а код, который просто вызывает функции, модули и компоненты для обеспечения 80% покрытия продуктового кода. На моей практике был случай, когда разработчики увлеклись mock'ами настолько, что в юнит-тестах одни mock'и тестировали другие. Естественно, пользы от такого "тестирования" очень мало.
Прошу прощения, если задел кого-нибудь подобным комментарием. Посыл не в том, чтобы сказать: "команда автора — сплошь джуны и не умеют работать", а в том, что в разных областях есть специалисты и эксперты, и важно понять, когда нужно делегировать принятие решения им. И к сожалению, зачастую отделы разработки и управления не понимают, что тестировщики и отдел качества — это не просто люди для нахождения багов и приёмочного тестирования по stories в Jira.
Разница во времени появлялась из-за того, что пункт 1 (обновление антивируса) был очень тяжёл для автоматизации. Вот несколько проблем, которые легко решаются вручную, но сложны в автоматизации:
В конечном итоге, мы автоматизировали тесты только для тех антивирусов, для которых нашли надёжные решения проблем выше (осталось примерно 3-4 штуки). Сам процесс стал другим:
В данном случае получилось ещё избавиться от хранения машин с антивирусами и сэкономить на лицензиях (жаба особенно душила покупать лицензии, чтобы использовать раз в месяц). Но, естественно, пришлось провести анализ модулей, которые присутствуют в триальной лицензии, чтобы понимать, что тестирование совместимости действительно имеет смысл.
Плюс ещё получилось иметь возможность тестировать разные версии одного антивируса (процесс установки редко меняется).
Естественно, этот процесс намного медленнее пункта 1 (обновление антивируса вручную), даже с учётом того, что пункты 2, 5 и 6 (управление снепшотами) больше не нужны.
Надеюсь, достаточно подробно ответил на Ваши вопросы.
Насколько я понимаю, у нас с Вами разное понимание smoke-тестирования. Возможность выполнить один из самых основных юзкейсов, на мой взгляд, это тоже часть smoke-сценариев (проверил заодно, что ISTQB думает по этому поводу). Судя по
команда Юлии тоже воспринимала smoke, как к проверку на "невозможность выполнить никакие юзкейсы", и это не приносило практической пользы. И в итоге, проблема была решена unit-тестами, что хорошо (shift-left, все дела).
В целом, я вроде понял, про какие тесты Вы говорите. Кажется, это то, про что я написал "лишь малая часть тестирования" в предыдущем комментарии. Дискуссия оказалась только о терминологии.
Мне кажется, это очень однобокий взгляд на Smoke-тесты. Взять ваш же пример со страничкой гугла. Вы делаете акцент на "что-то похожее", наверное, потому, что всё-таки готовы к каким-то изменениям на странице. Проблема в том, что очень трудно понять, когда изменения позитивные, а когда негативные. Например, зайдёт такой "умный" тест на страничку гугла, а поисковой строки не будет вовсе. "Достаточно похоже", — подумает алгоритм, и тест пройдёт. Если Вы думаете, что поисковая строка слишком большой элемент, чтобы его проигнорировать, представьте интернет магазин, у которого удалили кнопку + ("плюс") для добавления товара в корзину. Ничего купить нельзя, зато мы сэкономили время на написании Smoke-тестов.
На моей практике, все попытки масштабной автогенерации тестов сводятся к фразе: "ну мы же не обязаны использовать только сгенерированные тесты!". Это правда, и по факту данные сгенерированные тесты занимают лишь малую часть тестирования, и уж точно не способны целиком заменить smoke-тестирование.
Обычно сгенерированные тесты оказываются хороши для каких-то специфических проверок, в тех случаях, когда никакого интеллекта не нужно, но объём тестов либо очень большой, либо динамически меняется. Например, если команда делает конструктор для создания страниц компании в одинаковом стиле. Имея список созданных страниц, может быть полезно при релизе пройти по ним и проверить, что ни одна из них не возвращает 500.
В большинстве случаев время прохождения автотеста меньше времени ручного тестирования. Но это не значит, что если это не так, то это что-то странное. Потому что не совсем корректно сравнивать машиночасы с человекочасами.
У меня было несколько примеров на практике: тестирование совместимости и compliance testing (прошу прощения, не знаю, как это нормально переводится на русский). Представьте, что у вас есть приложение, которое теоретически может конфликтовать с антивирусами (драйвера, системные перехваты и т.п.). Скорее всего вам придётся регулярно проводить тестирование на машинах с разными антивирусами. Ручные тестировщики делают это так: держим машины с установленными антивирусами, а сам процесс тестирования выглядит следущим образом:
В данном случае тестирование очень небольшое, потому что нам достаточно буквально несколько (максимум пару десятков) тест-кейсов, чтобы убедиться, что не возникают deadlock'и или прочие конфликты с антивирусом. В итоге оказывается, что большую часть времени тестировщики тратят на пункты 1, 2 и 5, 6, т.е. те, которые с нашим продуктом вообще не связаны.
К сожалению, в то время, когда я этим занимался, руками обновлять или конфигурировать антивирусы было в 100 раз проще, чем надёжно автоматизировать (попробуйте надёжно кликнуть кнопку "Обновить" в кастомных GUI под Windows).
В итоге, в данном случае пожертвовать временем ради освобождения ручных тестировщиков будет вполне себе разумной идеей. Автотесты автономно гоняются раз в неделю, пусть это даже будут 2 машинодня по выходным и 2 человекачаса в понедельник на разбор результатов. И это будет примерно в 4 раза лучше чем 1 человекодень каждую неделю.
Аналогичная история с compliance'ом: если вам раз в месяц нужно проверить совместимость с обновлениями Windows, освобождение ручных тестировщиков от этой задачи будет ценнее сэкономленных машиночасов. Да и если посмотреть, то подобных задач не так уж и мало. Другой вопрос, что в большинстве своём они связаны с нефункциональными требованиями, куда автоматизация не всегда успевает (или физически может) добраться, кроме, может быть, требований производительности и надёжности под нагрузкой.
Большое спасибо за интервью и за вопрос про Juggler в частности.
Честно говоря, не очень понятно, как команда позиционирует Juggler. С одной стороны, насколько я понял из интервью, Juggler — это протокол именно для FF, который только идеологически связан с CDP, т.е. решает схожие задачи, но не обязательно схожим образом, поскольку некоторая часть протокола очень тесно связана с самим Chrome'ом и фактически не может быть кроссбраузерной.
С другой стороны, Juggler похож на CDP, и Андрей упомянул, что они работают над долгосрочным API. Будет ли это API поверх CDP/Juggler, или Juggler и будет основой для данного API? Будет ли оно кроссбраузерным?
Мне кажется, это важный вопрос для будущих инструментов. Например, если кто-то захочет создать библиотеку на Python, в каком направлении ему следует двигаться?
По поводу недоверия к пропатченным браузерам: на мой взгляд, проблема не столько в боязни за Rendering Engine. Представьте, что у нас есть веб приложение, и пользователи завели баг для определённой версии браузера (например, баг воспроизводится в FF версии < 70). В итоге мы создаём тест для регресса и гоняем автотесты и для новой версии FF, и для старой. Поскольку, насколько я это понимаю, определённая версия Playwright'а использует свою фиксированную версию браузера, мне, как автоматизатору, теперь необходимо придумать, как прикрутить использование нескольких версий Playwright'а в автотестах: возможно, всё решается разными контейнерами или виртуальными машинами для каждой версии, но, опять же, инфраструктурные затраты несравнимо больше, чем запуск разных версий с одной машины. Не стоит ещё забывать, что в данном случае мы ещё надеемся, что наши тесты совместимы с обеими версиями Playwright'а, особенно если протокол не менялся между версиями.
С другой стороны, проблемы разделения Playwright и браузеров тоже понятны: наверняка, у всех была ситуация, когда при работе с selenium'ом возникала проблема совместимости вебдрайвера с соответствующим браузером из-за различия в версиях.
Желаю удачи и успеха команде и проекту Playwright. Хочется верить, что это будущее автоматизации веб тестирования.
Большое спасибо за статью. Подскажите, пожалуйста, сколько времени прошло от первой попытки до текущего результата? Прошу прощения, если упустил это в статье.
Часто сталкиваюсь с ситуацией, когда компания страдает от недостатка автоматизации и нанимает сеньора/лида/команду со словами "мы хотим, чтобы вы сделали, как надо". Однако потом оказывается что-то в духе "у нас уже есть 5 E2E ручных тестов, которые мы гоняем раз в месяц, но хотим ежедневно. Осталось только заскриптовать." Или, что ещё хуже: "наши эксперты-программисты уже написали фреймворк для вас, но у них нет времени поддерживать, пока этим занимаются ручные тестировщики, но они тоже начали жаловаться на недостаток времени". И в том, и в другом случае команда автоматизации тратит больше времени не на то, чтобы "сделать, как надо", а на то, чтобы объяснить, что текущие практики не соответствуют (физически не могут, к сожалению) ожидаемым результатам, и показать (читай "продать") те baby steps, которые приведут к качественным изменениям. При этом менеджеры искренне удивляются, почему нанятые специалисты до сих пор не могут сделать автоматизацию стабильной. Достаточно типичным является диалог, когда автоматизатор предупреждает, что данная попытка приведёт к ситуации
на что менеджеры говорят что-то в духе "откуда ты знаешь — ты же не пробовал в нашей компании? Не сравнивай нас с другими — мы другая компания". Фактически, автоматизаторов просят пройти весь путь от первого подхода и первой попытки заново.
Данная статья хорошо показывает реальный опыт прохождения этого пути. Я искренне надеюсь, что она поможет компаниям осознать, сколько времени и ресурсов уходит на "попробовать" и прийти к тому, с чего они могли бы сразу начать.
Мне тоже было интересно, чем Playwright отличается от других инструментов. Я поизучал вопрос, и теперь мне кажется, что достижение команды разработчиков Playwright намного больше, чем новая библиотека на node js для UI автотестов.
CDP (Chrome DevTools protocol) находится "ближе" к хрому, чем Selenium, поэтому он предоставляет больше информации и возможностей в работе с браузером. Проблема в том, что протокол был сделан для хрома, а тестировать веб приложения хочется в том числе и в ФФ. И огромная заслуга команды Puppeteer и Playwright в том, что они фактически провоцируют объединение и стандартизацию данного (подобного?) протокола для браузеров. Вот, например, тикет с обсуждением https://bugzilla.mozilla.org/show_bug.cgi?id=1512337
Стоит отметить и отношение Mozilla к этому вопросу (из https://bugzilla.mozilla.org/show_bug.cgi?id=1512337#c10):
Насколько я понимаю, Mozilla активно работает над remote protocol'ом (https://firefox-source-docs.mozilla.org/remote/index.html), который будет близок к CDP, что не может не радовать.
Playwright использует свой протокол для ФФ (Juggler), который, если я не ошибаюсь, похож на CDP, но тем не менее отличается от него и, соответственно, от remote protocol, который официально будет поддерживать Mozilla. С чисто прагматической точки зрения, использование Playwright сейчас для ФФ выглядит достаточно рискованно: кажется сомнительным, что браузер будет поддерживать и remote protocol, и juggler, поэтому можно ожидать, что и протокол, и внутренности playwright будут меняться (см. также https://wiki.mozilla.org/Remote/Meetings/2020/01/24#Minutes). Скорее всего, этот процесс не обойдётся без интеграционных проблем.
Резюмируя, хочется сказать огромное спасибо команде разработчиков. Благодаря их работе в области CDP-подобного протокола, мы можем ожидать, что появятся библиотеки и на других языках, что сильно облегчит многие задачи автоматизации тестирования.
Было бы ещё интересно узнать от самих разработчиков детали Juggler (https://github.com/puppeteer/juggler ?), его отличия от CDP и планы развития.
Хабр Документация.
Сервис для хостинга документации типа https://readthedocs.org/ с возможностью задавать вопросы авторам проектов в комментариях. Авторы в свою очередь могут:
Думаю, ещё одним преимуществом может стать поиск по тематике. Часто приходится искать инструменты без привязки к языку программирования. Объединённый сервис может решить задачи списков вроде https://github.com/atinfo/awesome-test-automation, потому что их не надо будет обновлять вручную.
Комментарии и рейтинг, как и любая обратная связь, могут (теоретически) улучшить качество документирования проектов в среднем.