В статье речь про тестирование, а в заголовке про QA. Если есть стремление приносить пользу, то лучше начать с азов: чтобы ваши сотрудники понимали разницу в этих терминах.
Но кому задавать эти самые вопросы? Где взять ссылку на чат-бота?
Локально, без регистрации и СМС. Делаем вот так для автоматизации тестирования https://habr.com/ru/articles/887226/ но очевидно можно не только для неё.
Нет, я имел ввиду что это серьезный недостаток инструмента
по крайней мере добавляет лишний код
Не могу согласиться. Вынести ожидание и получение элемента во враппер и пользоваться враппером везде вместо find_element. Вряд ли код, написанный для переиспользования и реализации какой либо функциональности (в данном случае «нормальное ожидание») можно назвать лишним. Разве что он «лишний» по сравнению с Selenide, где, судя по всему, эта функциональность не нуждается в реализации.
В чем проблема? Есть трудовая книжка, работодатели ее видят. Думаете туда можно приписать что угодно? Не говорю про случаи мошенничества - если уж дипломы покупают, то и тут можно.
Есть же трудовая книжка для тех кто по ТК работает. Если есть подозрение на нарисованный опыт - можно не обращаться к такому ментору или попросить эту информацию (выписка из электронной трудовой или фотографии бумажной).
HR в данном случае, которые не могут сформулировать текст вакансии
Я не HR, нанимаю к себе в отдел, текст вакансии пишу сам (описание проекта, обязанности, требования к опыту), смотрю чтоб на hh было идентично. Делал так в разных компаниях. Где в этом процессе место для неправильной формулировки HR’ами? Для меня выглядит, что нанимающий менеджер максимально безразличен к качеству и скорости выхода сотрудника, если текст вакансии сформулирован плохо.
Сейчас у нас используется похожий стэк: GitlabCI, Python, Appium, Selenium, Allure, FastAPI, Кастомный UI - MaterializeCSS + Plotly.
Действительно удобно видеть всё в одном месте для быстрого понимания состояния сборок по результату прохождения автотестов, особенно когда тестируемое приложение прогоняется на многих платформах (пока у нас 7 платформ). Также есть возможность фильтрации - по платформам, типам сборок, наличию процессных проблем. Вот как выглядит это у нас
Из каждого результата можно провалиться в соответствующий on-demand Allure репорт
КЭта история пока еще не отражает ни качества, ни готовности к релизу, на пути к этому. Однако о дашборде, который в том числе использовался для определения готовности к релизу в другой компании, можно почитать здесь.
Также смотрим на Grafana для мониторинга элементов, составляющих инфраструктуру автотестирования/CI.
В статье речь про тестирование, а в заголовке про QA. Если есть стремление приносить пользу, то лучше начать с азов: чтобы ваши сотрудники понимали разницу в этих терминах.
Я писал под комментарием @vagon333 :)
Ваш опыт интересен, но комментарий мог бы быть более полезен если указать конкретные LLM, с которыми наступили на эти минусы и получили плюсы
Да. И сам себя ревьювить, пропуская галлюцинации, потому что галлюцинировал.
Первое впечатление было такое же :)
Локально, без регистрации и СМС. Делаем вот так для автоматизации тестирования https://habr.com/ru/articles/887226/ но очевидно можно не только для неё.
Уже используем: https://habr.com/ru/articles/887226/
Используйте локальные модели. Бесплатно. Пожалуйста.
Жестко завязан на структуру, поэтому более хрупок, чем:
//a[descendant::h3[text()=‘*** QA Group’]]Можно почитать подробнее про XPath Axes
Нет, я имел ввиду что это серьезный недостаток инструмента
Не могу согласиться. Вынести ожидание и получение элемента во враппер и пользоваться враппером везде вместо find_element. Вряд ли код, написанный для переиспользования и реализации какой либо функциональности (в данном случае «нормальное ожидание») можно назвать лишним. Разве что он «лишний» по сравнению с Selenide, где, судя по всему, эта функциональность не нуждается в реализации.
Уже провал.
Это вообще не уместно. CI без разницы какой инструмент использовался для написания тестов.
Смешно. Если у элемента есть id или текст, то и в Appium будут простые локаторы.
Если Appium’у требуется СЛОЖНЫЙ xpath, значит у элемента нет ни id, ни текста, ни других уникальных свойств. В этом случае и maestro не поможет.
Не проблема. Ни разу при нормальном подходе тесты на ожидании элемента не упадут.
Вот это особенно забавно.
В чем проблема? Есть трудовая книжка, работодатели ее видят. Думаете туда можно приписать что угодно? Не говорю про случаи мошенничества - если уж дипломы покупают, то и тут можно.
Есть же трудовая книжка для тех кто по ТК работает. Если есть подозрение на нарисованный опыт - можно не обращаться к такому ментору или попросить эту информацию (выписка из электронной трудовой или фотографии бумажной).
Согласен, хотелось бы чтобы менторство если и было, то более честное - чтобы туда не лезли все, кому не лень
Спасибо за внимательность, поправлю
Сильно.
Всякий негр, амотный, автор, имеет, желание написать, на хабр.
Я не HR, нанимаю к себе в отдел, текст вакансии пишу сам (описание проекта, обязанности, требования к опыту), смотрю чтоб на hh было идентично. Делал так в разных компаниях. Где в этом процессе место для неправильной формулировки HR’ами? Для меня выглядит, что нанимающий менеджер максимально безразличен к качеству и скорости выхода сотрудника, если текст вакансии сформулирован плохо.
Приятно читать о таком подходе.
Сейчас у нас используется похожий стэк: GitlabCI, Python, Appium, Selenium, Allure, FastAPI, Кастомный UI - MaterializeCSS + Plotly.
Действительно удобно видеть всё в одном месте для быстрого понимания состояния сборок по результату прохождения автотестов, особенно когда тестируемое приложение прогоняется на многих платформах (пока у нас 7 платформ). Также есть возможность фильтрации - по платформам, типам сборок, наличию процессных проблем. Вот как выглядит это у нас
КЭта история пока еще не отражает ни качества, ни готовности к релизу, на пути к этому. Однако о дашборде, который в том числе использовался для определения готовности к релизу в другой компании, можно почитать здесь.
Также смотрим на Grafana для мониторинга элементов, составляющих инфраструктуру автотестирования/CI.
Мы тут делаем кеши appium/nodejspython пакетов в локальной сети, свою миниферму, а вы до сих пор расчитываете на >забугорный< >облачный< сервис?