Автотестер. Какие нынче требования?

[XpoH]

это вообще про другое, то что ты описал (отслеживать ключевые метрики вовлечённости и при абнормальных значениях) обязанность программиста (владельца сервиса), имхо, и уж никак не reliability engineer.

Ась? Сосать с базы дату куда-то в кибану или добавить в код логирование всяких событий а там красивые прямые показывать. Регистрации юзеров, использованое сервиса/фич, отсылание/открывание писем и тыды. И как только например видно что народ стал меньше тыкать на кнопку "поделится" то понимаем что какие-то кейсы сломались. Или код, или что-то с UX намутили. Пограмистам обычно такое делать взападло - там скорее нужно собирать кучи метрик и смотреть как они изменяются со временем.

И при чем тут reliability engineer?

[valchkou]

Зовете умного контрактора, который под ваши требования пилит фреймворк сверх над тем же TestNG+rest-assured, который включает в себя создание юзера, авторизацию и тд, писание репортов в любо удобный репортинг тул, встраиваете это в ваш CI\CD пайплайн

аналог этого у нас уже есть и это все в руках программеров.
rest assured я воткнул в самом начале, но в данный момент стандартные спринговые билиотеки все это покрывают.
единственный недостаток сейчас что код идет вместе с сервисом и программисты за него отвечают, а требуется чтобы тесты были независимы от кода и чтобы как можно меньше кода и как можно больше UI.

и натравливаете программистов и ручных тестов писать тесты. Садите умного программиста чтоб разобрался с Testcontainers.

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

осталось понять какие должны быть скилзы и уломать бухгалетера

[SteveQA]

Если с огурцом хотите автотесты, то лучше cucumber, selenium, ruby. И так ручным тестировщикам легче будет обучится.
Я в Чикаго написал фреймворки, а потом обучил ручных тестировщиков, которые и UI покрыли автотестами, и Rest сервисы.
А без огурца лучше Java, Webdriver, TestNg.

[АццкоМото]

Интересно что наиболее полно в состоянии покрыть нашу систему и современные распределенные системы вообще.

А в этом плане рацуха такая. Нужно смотреть на а) наиболее часто изменяемый код б) изменяемый из-за внесённых ошибок в) наиболее часто ломаемый из-за внесённых изменений

Б и В могут показаться (и даже оказаться на практике!) одним и тем же, но это разное. Если сумеете собрать метрики и приоритизировать работу тестирования так, чтобы это код покрывать, как бык овцу, а остальному — присовывать вяленький тестик по остаточному принципу, будете круты нии.. тащемта, очень круты. Но это на стыке дева и кюэй, в отдельности редко тянут

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

Я согласен, что рацуха покрыть систему умнО, а не полно, не имеет отношения к задаче покрыть полно. Так что да, нужно искать фреймворк. Для замены мозгов.

[stenking]

Но нам нужна типа система, (боюсь слова платформа) на которую можно натравить ручных тестеров и они смогут чего то там начать автоматизировать. Потому что если их на травить на селениум то ничего не получится так как для начала им нужно стать жава программистами.

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

Т.е. это всё самое что ни на есть погромирование. Поэтому или все пограмисты пишут тесты или ты делаешь отдел из одного умного и 4-х средних) Просто найти чувака который с НУЛЯ тебе сделает такую системы нельзя. Точнее такие люди есть но денег они захотят вполне себе около твоих


На чём ты это делаешь не так уж важно.

Я меня вот так оно. Притом если посмотреть то видно что внутри куча лишних шагов, лейбл кривыми руками поставленные

Code: Select all

Feature: Password restore
  User forgot their password, and attempts to restore

  Scenario:
    Given I am on the page "/"
    When I click on the button "to-sign-up"
    Then I see login form
    When I fill name with "test-password" and email with "test-password@хххххххх.com"
    And I click on the button "sign-up"
    And I wait few seconds
    Then I see in the url "/projects"
    When I click on the button "logout"
    Then I see in the url "/login"
    And I click on the button "restore-password"
    And I fill email field with my email
    And I click on the button "restore-password"
    Given I see in mailbox the latest message with QA label "reset-password"
    When I click on the link "reset-password" in the latest message
    Then I see login form
    When I fill password field with "123123123"
    And I click on the button "reset"
    And I wait few seconds
    Then I see in the url "/projects"
    When I click on the button "logout"
    When I fill email and password with my credentials
    And I click on the button "log-in"
    And I wait few seconds
    Then I see in the url "/projects"
    And I see "projects"

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

[stenking]

Поэтому самый умный способ такой:

1. Отслеживать и быстро реагировать на поломки.

2. Внедрить систему тестов в процесс разработки и решить все сложные случаи ( откат билда, проблемы с JS, создание фейковых данных...)

3. Как только что-то ломаеется много и часто - добавлять тест. Без 1 и 2, 3 имеет мало смысла так как покроет всякую фигню а не то что реально нужно.


Т.е. 1 и 2 должен спроектировать тот глав чувак который и занимается проектом - возможно ты) А 3. уже бери кого угодно

[ystar]

Цель данного топика понять что сейчас в тренде у автотестеров,
какие навыки, фреймворки, языки нужны и что должно быть в резюме автотестера - эксперта.
Оринeтировочная цель автоматизация IoT, microservice платформы (java, node, REST, MQ)+- UI (javascript), облака, jenkins, kubernetes, docker.

Так же хочется понять сколько такой чувак ориентировочно может стоить в чикагах.

Пока не нанимаем, но уже начинаем думать о том чтобы подумать об этом

Тут больше важно построить процесс, фреймворки написать, и все это использовать правильно.

Автотесты - можно писать на чем угодно, а не на селениум огурец и питон.

Селениум - это фреймворк для web ui тестов, можно так же сделать и для перформанс тестирования. Язык программирования вообще не важен.
Всякие cucumber и прочий bdd советую избегать. Излишний слой, который только усложняет процесс автоматизации (опыт на 5-ех bdd проектах).

Нужно понимать, какие тесты вам необходимы и что у вас есть.
Если web ui - то по вашему стеку - это java, selenium-webdriver, docker, какой нибудь отчет (allure, report-portal, thucydides), junit/testng
Если ещё хотите и нужно API - то java, rest-assured хватит.

С моей точки зрения и опыта на 15 проектах по автоматизации, важно понимание того, что необходимо получить по итогу:
Процесс - после каждого коммита на дженкинсе запускаются юнит тесты на данном бранче для данного коммита, если мерж произошел в мастер - автоматом запускаются все тест по очереди, unit -> api -> web ui.
Каждую ночь запускаются автотесты на дженкинсе.
Очень хорошо, если человек сможет убедить, что unit и api тестов должно быть 80% и только 20% ui.
Построить фреймворки для API и UI, таким образом, чтобы ручные тестировщики могли писать автотесты после небольшого интродакшн.

Для web ui тестирования - нужно разобраться на сколько большое веб приложение, на сколько необходимо много настроек, и на сколько много можно переиспользовать api тесты в UI. Нужно ли писать свой фреймворк, либо по возможности заюзать сторонние типа selenide.

Пиши в личку, может могу помочь подробнее.

Думаю в Чикаго будет зп такого человека 130-150.

[ystar]

А такие есть в Чикагах? Не так чтобы в объявлении, а на местах?

Нанять хотите? Из своих тестеров не хочет никто прогрессировать или вообще пока нет тестеров и решили обзавестись?

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

если у вас джава, то смысла писать автотесты на питоне - 0.0%

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

[ystar]

Интересно что наиболее полно в состоянии покрыть нашу систему и современные распределенные системы вообще.

А в этом плане рацуха такая. Нужно смотреть на а) наиболее часто изменяемый код б) изменяемый из-за внесённых ошибок в) наиболее часто ломаемый из-за внесённых изменений

Б и В могут показаться (и даже оказаться на практике!) одним и тем же, но это разное. Если сумеете собрать метрики и приоритизировать работу тестирования так, чтобы это код покрывать, как бык овцу, а остальному — присовывать вяленький тестик по остаточному принципу, будете круты нии.. тащемта, очень круты. Но это на стыке дева и кюэй, в отдельности редко тянут

наиболее часто изменяемый код - это не самый лучший выбор для автоматизации, так как выхлопа будет мало, а работы много.
будет так -> вы поменяли код -> автотестеры пока разобрались и поменяли автотесты -> вы опять поменяли код и к этому времени автотесты прошли раза три-четыре и уже не актуальны. (если это конечно не критический код и компонент системы).
а вот, покрыть автотестами стабильный код - самое оно, и автотесты - один раз написал и забыл, и если кто-то что-то изменит или поломает сразу будет видно.

Сразу надо код покрывать юнит тестами и апи -> тесты быстрые, стабильные, и место поломки будет быстро находится и локализироваться.
Web UI тесты -> долгие и нестабильные и причину поломки не всегда сразу найдешь.

unit test - 50%
api test - 30%
ui - 20%

[ystar]

"А где б найти мне такого
Работника не слишком дорогого"
(Сказка о попе и о работнике его Балде)

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

Реальнее своих растить, ну или какого программера попокладистее сделать тимлидом и поручить ему это направление.

Существуют и найти можно. Стоимость на уровень Senior девелопера. Но знания должны быть как и со стороны программирования, так и со стороны QA, по сути такой человек должен знать побольше senior девелопера.

[ystar]

Но нам нужна типа система, (боюсь слова платформа) на которую можно натравить ручных тестеров и они смогут чего то там начать автоматизировать. Потому что если их на травить на селениум то ничего не получится так как для начала им нужно стать жава программистами.

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

Т.е. это всё самое что ни на есть погромирование. Поэтому или все пограмисты пишут тесты или ты делаешь отдел из одного умного и 4-х средних) Просто найти чувака который с НУЛЯ тебе сделает такую системы нельзя. Точнее такие люди есть но денег они захотят вполне себе около твоих


На чём ты это делаешь не так уж важно.

Я меня вот так оно. Притом если посмотреть то видно что внутри куча лишних шагов, лейбл кривыми руками поставленные

Code: Select all

Feature: Password restore
  User forgot their password, and attempts to restore

  Scenario:
    Given I am on the page "/"
    When I click on the button "to-sign-up"
    Then I see login form
    When I fill name with "test-password" and email with "test-password@хххххххх.com"
    And I click on the button "sign-up"
    And I wait few seconds
    Then I see in the url "/projects"
    When I click on the button "logout"
    Then I see in the url "/login"
    And I click on the button "restore-password"
    And I fill email field with my email
    And I click on the button "restore-password"
    Given I see in mailbox the latest message with QA label "reset-password"
    When I click on the link "reset-password" in the latest message
    Then I see login form
    When I fill password field with "123123123"
    And I click on the button "reset"
    And I wait few seconds
    Then I see in the url "/projects"
    When I click on the button "logout"
    When I fill email and password with my credentials
    And I click on the button "log-in"
    And I wait few seconds
    Then I see in the url "/projects"
    And I see "projects"

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

В приличном обществе такой код не показывайте.

[АццкоМото]

Интересно что наиболее полно в состоянии покрыть нашу систему и современные распределенные системы вообще.

А в этом плане рацуха такая. Нужно смотреть на а) наиболее часто изменяемый код б) изменяемый из-за внесённых ошибок в) наиболее часто ломаемый из-за внесённых изменений

Б и В могут показаться (и даже оказаться на практике!) одним и тем же, но это разное. Если сумеете собрать метрики и приоритизировать работу тестирования так, чтобы это код покрывать, как бык овцу, а остальному — присовывать вяленький тестик по остаточному принципу, будете круты нии.. тащемта, очень круты. Но это на стыке дева и кюэй, в отдельности редко тянут

наиболее часто изменяемый код - это не самый лучший выбор для автоматизации, так как выхлопа будет мало, а работы много.
будет так -> вы поменяли код -> автотестеры пока разобрались и поменяли автотесты -> вы опять поменяли код и к этому времени автотесты прошли раза три-четыре и уже не актуальны. (если это конечно не критический код и компонент системы).
а вот, покрыть автотестами стабильный код - самое оно, и автотесты - один раз написал и забыл, и если кто-то что-то изменит или поломает сразу будет видно.

Сразу надо код покрывать юнит тестами и апи -> тесты быстрые, стабильные, и место поломки будет быстро находится и локализироваться.
Web UI тесты -> долгие и нестабильные и причину поломки не всегда сразу найдешь.

unit test - 50%
api test - 30%
ui - 20%

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

[ystar]

Интересно что наиболее полно в состоянии покрыть нашу систему и современные распределенные системы вообще.

А в этом плане рацуха такая. Нужно смотреть на а) наиболее часто изменяемый код б) изменяемый из-за внесённых ошибок в) наиболее часто ломаемый из-за внесённых изменений

Б и В могут показаться (и даже оказаться на практике!) одним и тем же, но это разное. Если сумеете собрать метрики и приоритизировать работу тестирования так, чтобы это код покрывать, как бык овцу, а остальному — присовывать вяленький тестик по остаточному принципу, будете круты нии.. тащемта, очень круты. Но это на стыке дева и кюэй, в отдельности редко тянут

наиболее часто изменяемый код - это не самый лучший выбор для автоматизации, так как выхлопа будет мало, а работы много.
будет так -> вы поменяли код -> автотестеры пока разобрались и поменяли автотесты -> вы опять поменяли код и к этому времени автотесты прошли раза три-четыре и уже не актуальны. (если это конечно не критический код и компонент системы).
а вот, покрыть автотестами стабильный код - самое оно, и автотесты - один раз написал и забыл, и если кто-то что-то изменит или поломает сразу будет видно.

Сразу надо код покрывать юнит тестами и апи -> тесты быстрые, стабильные, и место поломки будет быстро находится и локализироваться.
Web UI тесты -> долгие и нестабильные и причину поломки не всегда сразу найдешь.

unit test - 50%
api test - 30%
ui - 20%

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

немного не правильно выразился.
весь код должен быть покрыт unit тестами, вне зависимости, как часто он изменяется.
вот api и ui, как показывает мой опыт и опыт коллег, не имеет смысле покрывать автотестами, если код меняется очень часто, то автотестеры не будут успевать все поддерживать. Теоретически можно иметь достаточное количество автотестеров, чтобы все успевать параллельно менять, либо заставлять девелоперов все автотесты менять. Но теория это теория, на практике - ресурсы сильно ограничены.

И да, у нас с вами, возможно разное представление, о том, что подразумевается в частом меняющемся коде.

И как показывает практика, девелоперы далеки достаточно от тестирования в большинстве своем.

Хороший инструмент для определения чего автоматить, чего можно на потом оставить - с ошибкой в 20-30%.

[stenking]

Юнит тесты часто смысла имеют мало. Точнее они наверное нужны если вы пишите библиотеку или фраимворк но если у вас основной функционал это работа с базой то юнит тут бесполезный.

[Sergunka]

А такие есть в Чикагах? Не так чтобы в объявлении, а на местах?

Нанять хотите? Из своих тестеров не хочет никто прогрессировать или вообще пока нет тестеров и решили обзавестись?

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

стоить будет как сеньор-помидор.
такие всем нужны, какая вероятность того что вы ему понравитесь?
селениум это одно, бб тесты это другое.
TestNG, rest-assured и тд.
для интеграционных тестов Testcontainers.
Gatling+JMeter.

А Вы Testcontainers пользуетесь? Как впечатление?