😳 Рисковый он однако. опять же @oneumyvakin расскажи тогда ещё пожалуйста о преимущества и недостатках Go на твой взгляд. Для создания каких продуктов он хорошо подходит, как ты думаешь?

@kami_nary тестировщиками тестируем, автоматизируем и кажется где-то девопсим, Саша вот например девопсит в свобоное от работы нерабочее время

«свободное от работы нерабочее время» звучит как будто есть несвободное от работы нерабочее время 😐

Хорошо писать сервисы и CLI утилиты(особоенно если утилита должна быть кроссплатформенная Win/Linux/Mac).
Хорошо подходит если нужно написать простой надежный и понятный для других код.
Хорошо подходит если нужно написать сервис эффективный по памяти(лучше Python/PHP,NodeJS) и по latency.
Хорошо подходит если нужно быстро(!) разобраться как работают вещи в ОС на низком уровне, потому что в Go нет барьера в виде С/C++ как в Php/Python/NodeJS.

Работа с БД может быть сложной, в смысле если нужны сложные связи типа many-to-many-over-intermediate-entity, такие вещи придется писать руками, т.к. сейчас в Go нет ORM уровня какой есть например в Django или Laravel.
Практически ничего нет для написания UI.
Не очень подходит, если нужно работать с данными структуру которых вы не знаете, и вам эти данные нужно как-то процессить, будет очень сложно.

Если тестировщик в команде один то он всегда немножко менеджер разработчиков.

хм. Я тоже один🧐. Только мне не кажется, что я разврабов менеджерю. Может быть на самом деле менеджерю, а может просто не знаю что так можно было. Поделись конкретикой пожалуйста.)

@ArtProfitRoll давай я подумаю

👍🏻

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

@le0lka ну есть такое время 😊 я видел людей у которых оно есть, вот у @alfemy есть например

Хороший ответ. Спасибо:) Но может в ответе пропущена "не". А то как то странно звучит "достаточно важная чтобы на нее забить". Я то сам себе её додумал, но может не в том месте.

Да, точно

Полностью согласна!

@kami_nary у нас еще наблюдается тренд смещения QA эффортов ближе к требованиям, что еще должно захватывать дизайн / UX , где как раз тест-анализ сильно помогает, но в свою очередь это требует от QA инженера кроме знаний/навыков еще и желания этим заниматься, не все любят/хотят тестировать требования, я например не сильно это люблю, а вот например @operevozkina любит и умеет, а я переодически прошу её о помощи 😊

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

@kami_nary да, причем полючается так что в больших системах на большой скорости уже не получается эффективно тестировать руками, тем более так как мы это любим ad-hoc'ом, по наитию, "третьим незамыленым глазом"

@oneumyvakin, спасибо, что подтвердил мои ощущения!

Правда, тогда напрашивается вывод, что надо либо заниматься программированием (чтобы писать автотесты), либо бизнес-аналитикой (чтобы эффективно работать с требованиями)

Может заниматься всем по чуть-чуть?

Тогда не понятно будешь ли ты эффективен, а соответственно, нужен компании