было бы желание отказаться, а аргументы найдутся :)

Если есть возможность внести время на поддержание актуальности документации в рабочий процесс и учитывать его при планировании то почему бы и нет

потому что «есть более срочные задачи» :)

было бы желание отказаться, а аргументы найдутся :)

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

Никто не ставил чарлик на иОС? Я про мобила версию

потому что «есть более срочные задачи» :)

и скорее всего они более важные, по причине того что в его случае эта дока не будет нужна никому

они более важные потому, что они более важные

:)

они более важные потому что от этой выхлоп стремиться к нулю

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

если не читали книжку Даниэля Канемана «Думай медленно, решай быстро» — очень рекомендую почитать

надо бы добавить ее в список прочитать когда будет время, но смысл послания я уловил (надеюсь), надо подумать

используя ту же самую логику многие отказываются и от тестирования тоже. или от написания модульных тестов. или от код-ревью. всегда в ход идет один и тот же аргумент — «если у тебя много срочных задач, тратить время на XXX просто непростительно».

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

Всем привет. Кто работал с аутсорс-тестированием или может сам работает в такой сфере, какие компании можете порекомендовать? Желательно со специализацией в тестировании мобильных приложений.

Е-легион изучает таким образом конкурентов?)))

Нет, не конкурентов

Всем привет. Кто работал с аутсорс-тестированием или может сам работает в такой сфере, какие компании можете порекомендовать? Желательно со специализацией в тестировании мобильных приложений.

https://www.applause.com/ в целом хорошее впечатления находили интересные баги, контролировать конечно надо, обговаривать неоднозначные моменты, давать регулярно обратную связь

Благодарю!

https://www.applause.com/ у нас выделили русскоязычного менеджера и команду по желанию (программный продукт был на русском языке), по ценам - можно немного поторговаться

Никто не ставил чарлик на иОС? Я про мобила версию

Ух ты, круто что сказали, сегодня поставлю)

Привет Всем Кто сталкивался с проблемой когда выдает ошибку при запуске appium и настройке Desired Capabilities Error An unknown server-side error occurred while processing the command. Original error: ENOENT: no such file or directory, scandir 'C:\Users\admin\tools\build-tools'

У вас android sdk прописан неправильно

Привет Всем Кто сталкивался с проблемой когда выдает ошибку при запуске appium и настройке Desired Capabilities Error An unknown server-side error occurred while processing the command. Original error: ENOENT: no such file or directory, scandir 'C:\Users\admin\tools\build-tools'

Или, вероятно, вообще не прописан

У вас android sdk прописан неправильно

Как прописать правильно?

Ребята, написала статью на хабре по мотивам своего доклада на AgileDays. Рассказала почему разработчики автотестов не нужны для автоматизации тестирования. https://habrahabr.ru/company/alfa/blog/352312/

Как прописать правильно?

У вас android home настроен?

Да

@Travieso_nastya что-то похожее на эту тему я не раз видел, но все равно спасибо, почитаем

@Travieso_nastya что-то похожее на эту тему я не раз видел, но все равно спасибо, почитаем

если видели - скиньте плз ссылку. буду признательна.

?‍♂️ редко сохраняю подобные статьи, потому не могу подсказать где именно видел

кажется это было в блоге Badoo на хабре

на недавнем митапе в мейле мужик из Росбанка рассказывал почему круто когда наоборот отдельная тима для автотестов)

вот и кому верить?

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

вот и кому верить?

всем ))) зависит от модели разработки: в водопаде, наверное, лучше отдельная команда ) в статье речь об agile ну и еще от кучи факторов

так у них тоже аджайл

я так и не понял

нужны автотестеры или нет?

нужны автотестеры или нет?

смотря какой бюджет/lifetime проекта/масштаб

я под конец статьи тоже очень запутался

смотря какой бюджет/lifetime проекта/масштаб

это в рамках статьи вопрос был, а не в целом

Да

Напишите в личку, попробую помочь)

я так и не понял

а почему не поняли? понимаю, в статье много букв и наверное поэтому прочиталось по-диагонали у многих. Мне еще учиться и учиться писать кратко и лаконично.

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

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

Если у компании есть большие бюджеты и они используют lean-подходы, то возможно PO не считают сколько стоит автоматизация его продуктам и тогда никогда наличие выделенной команды автоматизаторов болеть не будет

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

у нас не так) за бюджет продукта отвечает PO. И он весьма скурпулезно считает, а на что потрачены деньги его продукты. И насколько эффективно потрачены.

ERROR: S client not available

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

“В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum.” - не призываете воспринимать маст хэв?

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

“В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum.” - не призываете воспринимать маст хэв?

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

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

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

я же скопипастнул со статьи, где прямым текстом написано “Они (автоматизатор) не нужны, особенно если вы внедряете у себя scrum.”, и это заявление в стиле маст хэв. Такие статьи - они как желтушные новости с пёстрым заголовком “Автотестеры не нужны”, и с банальщиной внутри “на самом деле проблема в мотиваации аутсорс сотрудников”. Только вы это растянули на N абзацев и описали чвть подробнее внутреннюю кухню на проекте. Поэтому n-ная часть сообщества негативно относится к статьям такого рода

я же скопипастнул со статьи, где прямым текстом написано “Они (автоматизатор) не нужны, особенно если вы внедряете у себя scrum.”, и это заявление в стиле маст хэв. Такие статьи - они как желтушные новости с пёстрым заголовком “Автотестеры не нужны”, и с банальщиной внутри “на самом деле проблема в мотиваации аутсорс сотрудников”. Только вы это растянули на N абзацев и описали чвть подробнее внутреннюю кухню на проекте. Поэтому n-ная часть сообщества негативно относится к статьям такого рода

мне показалось, что дело не в мотивации, а в плохом управлении ресурсами )

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

Похоже просто название сделано на привлечение внимания) Ну и в целом сработало))

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

Анастасия, мне кажется что в контексте вашей статьи - будет правильно называть не QA-Dev, a Automation QA

такое ощущение что статья очень задела автотестеров

Меня все статьи, которые дезинформируют - задевают

а в чем там дезинформация? человек описал свой опыт и как решили свои проблемы

3ий раз цитирую. “Они (автоматизаторы) не нужны, особенно если вы внедряете у себя scrum.”

И прочие высказывания в этом духе

Вообще некоторые фразы и название таки очень провокационные

Использовать их в проекции конкретного примера, не претендующего быть общим решением - так себе затея

Ребята, написала статью на хабре по мотивам своего доклада на AgileDays. Рассказала почему разработчики автотестов не нужны для автоматизации тестирования. https://habrahabr.ru/company/alfa/blog/352312/

спасибо за статью, я примерно сейчас с этим тоже столкнулся.

такое ощущение что статья очень задела автотестеров

задела, как же иначе

у нас похожий подход и вроде норм все довольны

Статья могла задеть только того, кто читал ее по диагонали и вырывает фразы из контекста

у подхода с выделенной командой автоматизаторов есть очевидные плюсы и минусы

на мой взгляд минусов больше