а какую проблему вы этой штукой решить пытаетесь?

Привет!
Уже который день одолевают меня мысли о двух подходах:
1. Тестировщик в команде, или
2. Команда тестировщиков

Вижу плюсы как одного, так и другого подхода и тема, возможно, холиварная. Понимаю, что это может зависеть от разных факторов, но как правильно выбирать подход пока не разберусь никак.
Расскажите, как у вас? Какие плюсы, минусы 1 и 2 подхода?
Может быть кто-то знает от чего отталкиваться, чтобы делать выбор в пользу одного из них

А может команда тестировщиков из которых внедряешь агентов в команды разработки ? 😁

Ну сейчас же у всех agile все модные, и хотят в команда иметь своего qa) но с другой стороны есть подход где отдел тестирования занимается задачами всех команд
Вот взвешиваю за и против и как-то пока никуда не перевешивает

Минусы тестировщика в команде:  высокие требования к компетенции, сдвиг в мышлении в сторону разработки, этические вопросы. Минусы в 2ом: хуже коммуникации => медленнее решаются вопросы, дольше погружение в технические детали. Работал и так и так

И как по личному опыту? Что показалось более эффективным?

В команде

С точки зрения продукта точно эффективнее.

Я работала автотестером в команде автотестеров. Сейчас работаю конкретно а команде продукта.
В команде продукта мне лучше

А в плане долгосрочной перспективы? Если тестировщик один, он заболеет, уйдёт в отпуск, уволится.
Любой онбординг не быстрая вещь, и будет просадка по качеству или скорости 🤔

А что именно лучше? Погружение в продукт, коммуникации?

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

Это по моему мнению

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

То есть в команде автотестеров нужно было идти искать мануала, который отвечает за часть продукта, который упал, он уже решал баг это или нет. Если команда дала из Китая это затягивалось очень.
Сейчас я отличное знаю, как должно работать и то, что работа этого места не должна была изменяться, а значит решение принимается быстрее

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

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

Большое спасибо за развёрнутый ответ! С интересом ознакомилась с вашим опытом)

Про шаринг да, тоже согласна. Упирается в процессы и возможно даже в зрелость команды

Поделитесь ещё, нет ли у вас как у qa проблемы развития, когда вы внутри команды?

Если вы в отделе тестирования у вас есть какой-то лид/руководитель, который может вас направлять, прокачивать. А когда ты один, найти правильный путь не так легко