У нас на проекте не планируется внедрение автотестов UI. Сам я ручник, помаленьку в авто вкатываюсь. Сейчас пишу автотесты на апи(питон). Предлагают в будущем начать писать юнит-тесты.

Как считаете, в плане развития как автотестеру - это однозначно хорошо?

это хорошо, только я не понимаю, зачем AQA специалисту писать юнит-тесты

если речь о юнит-тестах чужого кода, то это должны делать Dev инженеры

если о тестах своего кода - мне задача видистя бессмысленной

Ага. Но не делают по каким-то причинам. Скорее всего ресурсов не хватает.

С т.з. личного развития идея кажется не такой уж и плохой

Мне кажется, чем больше тестов, тем проще локализовать проблему.

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

Уверен, что меня поводят за руку

не пишут потому, что процессы поставлены плохо
а про юнит-тесты я хочу сказать, что QA ин;енеру это нужно попробовать, но ен нужно тратить на это много времени, так как основная работа заключается всё же в проведении функциональных тестов (и написании средств для их выполнения)

а я не QA...

Я тестер

Запилили фичу- я протестил.

макака, короче

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

тестер - разве не частный случай QA инженера?

Как говорится, да начнется эта легендарная битва по области и зоне ответственности QA/QC/Tester )

более частый чем QC

не начнётся) У нас не развит отдел тестирования

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