Eu trabalho na área de desenvolvimento em Java, porém a minha equipe de desenvolvimento me colocaram para desenvolver testes unitários com Junit, eu informei para o Analista de requisitos e para a minha equipe que eu não iria corrigir bugs, e que iria somente criar os testes unitários, e que os testes unitários costumam identificar bugs, as demandas irão ser muito grande, pois terei que criar testes unitários de três projetos muito grandes, mas o analista de requisitos me informou que se eu tiver que implementar teste unitários e caso encontre bugs, eu mesmo terei que corrigir, eu informei para o analista de requisitos que seria um absurdo eu ter que implementar teste unitários e caso encontre um bug eu tenha que corrigir-los. Fui contratado como programador, mas ao ficar focado em criar testes unitários é como eu estivesse no setor de qualidade, era para somente eu implementar os teste unitários e caso encontre bugs é para o desenvolvedor que implementou o recurso corrigir-los, mas eu gostaria de mais opiniões, o que vocês acham?
Corrigir erro também é tarefa de programador.
Eu sei disso, mas se o Analisa de requisitos me colocar para implementar testes unitários será que teria obrigação de também corrigir os bugs sendo eu que estaria implementando os testes unitários?
Eu acho que talvez vá depender da empresa, na minha opinião deve ficar pesado ter que implementar os testes unitários e ao mesmo tempo corrigir os bugs. Eu não tenho opinião formada em relação a isso, gostaria de saber como funciona na prática no mercado de trabalho.
Você não é obrigado a nada, pode ir pra outra empresa que a organização seja diferente.
Cada empresa funciona de uma forma diferente. Antigamente analista de teste nem programava, depois foi evoluindo pra programar testes funcionais e também ajudar a equipe no que for possível.
Então é isso mesmo! 
Tenho um colega de trabalho que me deu algumas dicas, e gostaria de postar aqui; Observem.
"Conheço uma empresa que irá designar uma única pessoa para implementar testes unitários para todos os projetos da empresa, e além de dessa pessoa ter que implementar testes unitários ela terá que também corrigir os bugs de todos os projetos.
Eu achei a ideia excessivamente desafiadora para o rapaz que implementará os testes unitários, e com isso irei expor minha opinião e gostaria de saber o que vocês acham!
Não existe uma regra cravada na pedra, mas… é algo que precisa ser negociado com o analista de requisito sobre como eles podem resolver como time.
A prática de testes unitários e testes automatizados como um todo é para que a equipe incorpore o costume de desenvolver com testes, se for se tornar “o cara dos testes” na empresa, isso vai ser ruim no geral pro time, se o rapaz ficar responsável por fazer os testes e corrigir os bugs dos devs, não tem porque ter testes automatizados, estará sendo feito um trabalho inútil, e o resto do time ficará defasado por não ter o conhecimento de fazer-los também.
Para o rapaz individualmente vai ser bom… O rapaz passaria a rapidamente conhecer todos os pontos de negócio da empresa… porém, só será bom se isso não lhe sobrecarregar e minar o trabalho do rapaz dos testes unitários…
Se o time estiver pensando assim, é importante chamar-los atenção para revisar a estratégia, pois os testes automatizados não vão cumprir o seu papel… Código de testes é do time e dos desenvolvedores também.
Concluindo:
Não é uma boa prática para uma única pessoa da empresa criar testes unitários, e o certo seria todos da equipe criar habito de criar também os testes unitários.
O rapaz pode dar o pontapé inicial para que o time todo comece a absorver a prática e se tornar o ponto focal do time, mas o custo de separar um time só pra escrever testes é muito alto.
Testes automatizados serve para que o time se torne dono e tome conta do próprio código, para evitar inserção de bugs no futuro em regras que estão sendo escritas agora…Ter o time todo comprometido com isso é de muito maior ganho para empresa.
Como eu tinha dito antes, não é regra gravada na pedra, mas é extremamente aconselhado.
Uma frase pra refletir: “Todo mundo quer ter o faturamento da Google, mas nem todo mundo que fazer o que o Google faz” 
As empresas querem resultado de Google sem mudar seus mindsets na hora de aplicar as práticas…
Dói e é caro mudar a filosofia de um time de software, mas vale cada centavo o preço a ser pago"
O que vocês acham?
Isso é decisão de cada equipe de acordo com as necessidades. Aqui por exemplo nao temos a necessidade de testes unitários, funcionais sim.
Isso não deve atrapalhar quem está focado em desenvolver a funcionalidade, por isso o especialista em testes.
Você foi contratado para executar um trabalho que consiste em várias coisas, se não está satisfeito, peça demissão e procure outro no qual você consiga fazer o que quer.
O mercado deve funcionar assim: se você não está satisfeito:
- É o empregador: demite
- É o empregado: se demite
Pagando meu salário podia me colocar até pra lavar banheiro.
hahahahaha 
Eu respeito sua opinião, mas é importante relembra que na maioria das vezes sua opinião não ofensivas, é importante ter opiniões diferentes como a sua, mas quando eu leio o que escreveu me leva a entender que você não parou para ler tudo que está nessa postagem, porque em nenhum momento eu levei a dar entender no que escrevi logo acima que estaria insatisfeito com que fui designado para fazer, faço de bom grado com toda satisfação porque gosto da minha profissão.
Com todo carinho e respeito que tenho a você, o que quis dizer é que em uma empresa não é uma boa prática que os testes unitários fiquem na responsabilidade de uma única pessoa, para mim vai ser excelente porque irei aprender muito, porém para a equipe como um todo não é vantagem, diferente de como você entendeu o que escrevi, eu estou pensando no meu time e não pensando somente em mim mesmo.
Quando eu comecei essa postagem eu tinha dúvidas, mas eu pesquisei mais um pouco e mostrei essa postagens para alguns colegas meus que estão no meu linkedin e que são também colaboradores desse fórum e me afirmaram o seguinte…
Não é uma boa prática colocar a responsabilidade de testes automatizados na responsabilidade de uma única pessoa, é importante que cada um crie os testes automatizados das suas implementações, pois isso faz com que cada um fiquei responsável pelo seu código, isso faz o time crescer tecnicamente.
A maioria das empresas tem o preconceito de implementar testes automatizados, porque na visão dos gestores isso faz atrasar as demandas de entregas das Sprints, não sabendo eles que não é atrasado de demanda e sim ganho de tempo, pois quando se dar mais importância para tempo de entrega tem um grande risco de entregar projetos com erros, mas quando se dar mais importância para os testes automatizados se tem mais velocidades nas entregas porque são fortemente minimizados os bugs de projetos, fazendo assim ter mais ganho de entregas nas demandas, porque se fosse junta o tempo de entrega mais os tempo de correções de bugs, os testes automatizados é levando mais em conta.
Então resumidamente era isso que eu quis dizer, não quero que se sinta repreendido pelo que escrevi, eu li outras respostas que você tem dado aqui no fórum, você é uma pessoa muito inteligente, e quero acredita que você escreveu essas coisas aqui no fórum para me testar, para saber se realmente sei o que estou dizendo, não vou levar pelo lado pessoal.
Eu só entrei na postagem pela zueira mano, tranquilo. Estamos aí
Logo, não entendi isso:
Nem isso:
No meu ponto de vista, toda negativa advém de insatisfação, ou seja, você está se contradizendo. Nunca vi ninguém reclamar que ganha demais, que o chefe é super gente boa, incentivador e que só passa tarefas boas e bacanas, com desafios graduais e que te farão ser um melhor profissional a cada entrega.
Aí, de novo, voltamos ao cerne da questão: você é o “chefe”, “the boss”? Se não, não tem boas práticas, nem nada, o que se tem é o que o cara que manda manda fazer e quem tem juízo, obedece. Ou pede para sair. Não tem meio termo, nem discussão.
Boas práticas são coisas a serem aplicadas em ambientes onde ideias não são ameaças. Ideias não são ameaças em ambientes onde os gestores são líderes e não chefes. Toda empresa vai ter coisas ruins. Mesmo amazon e google as tem. Assim como as consultorias de três letrinhas.
Como eu disse, cabe a você escolher ficar numa empresa onde o gestor determina que vocẽ siga uma má prática ou não. E se escolher o não, precisa ter em mente que em todas as 10 empresas que você mandar currículo, você vai ter 10 lugares onde existem coisas boas e coisas ruins.
Aí eu te digo: abra a tua própria empresa e faça do teu jeito.
Empresas como instituição não possuem preconceitos referentes a tecnologias e/ou metodologias, o preconceito é com a não resolução dos problemas dos clientes e, consequentemente, perda de market share, ou em portuguẽs claro: perda de dinheiro.
Sendo bem franco, isso me parece balela de professor universitário que se acha o sabichão.
Como eu sempre digo: não existe bala de prata. O que funciona para A não necessariamente funciona para B. A empresa X pode ter cases de sucesso com XP e isso não significa que a empresa Y terá. Cultura não se muda com um manual, muda-se continuamente, partindo da mudança de pensamento de cada um, fazendo com que cada pequena engrenagem entenda sua importância no todo. Ou, em outras palavras, se não mudarmos o processo individual, para que seja feito adequadamente, não adianta nada.
E é aí que eu volto ao que eu disse:
Se está insatisfeito, pede demissão e vai ser feliz. Se não está, trabalhe.
Agora, especificamente sobre unit tests: isso não é uma coisa nova. E, sendo bem sincero (e parafraseando o próprio @javaflex) não são efetivos. Testes integrados cobrem muito mais aspectos negociais (afinal, o teste visa identificar coerência entre o negócio e o sistema, não?).
Porém, eu ressalto que é importante realizar testes unitários. Senão, como o desenvolvedor vai saber que está funcionando aquele trecho específico de código que ele criou?
Se está certo ou não o que o gestor está exigindo de você, não sei. O que eu sei é que ele não vai mudar e, nesse jogo de força, ele é o que sempre vai sair ganhando.
hahahaha.
Agora eu entendi
Eu gostaria de mais opiniões!
Ué, mas se não tem as boas práticas eu como profissional buscando evoluir o meu próprio ambiente de trabalho não posso levantar os pontos de melhoria? Eu só posso obedecer calado por ser ajuizado?
Exato, mas como farei isso ou pelo menos tentarei se lá atrás eu tive que ser ajuizado e só obedecer?
A menos que possamos evoluir esse diálogo para algo mais próximo do que você está afirmando acima.
Pode ou não pode tentar mudar a cultura da empresa através do diálogo?
Porque se não são efetivos?
E a mudança de cultura?
Pra deixar claro, entendi boa parte do que você disse e aprendi que buscar equilibrar a balaça sempre é o caminho. Equilíbrio perfeito e cirúrgico aprendi que é muito difícil alcançar de forma que nesse jogo de funcionário x empresa tem uma miríades de combinações possíveis onde perfis profissionais se encaixam melhor em determinadas culturas empresariais… Isso dá um post bem grande pra explicar as diversas combinações possíveis que não pretendo me alongar aqui.
Porém algo que eu aprendi (que requer tempo e maturidade profissional) é que você sempre deve tomar algumas atitudes quando chega nessas encruzilhadas do tipo “penso que o caminho que estamos tomando como equipe não é o melhor” e o que eu faria:
- Comunicaria meu gestor sobre minha insatisfação/desconfiança em relação ao processo
- Faria, afinal apenas dizer que não é bom e se recusar a fazer não é o caminho.
- Avaliaria a jornada tendo feito e alavancaria os pontos fortes, fracos e como eu acho que poderia ficar mais efetivo. Ou entenderia, de repente, que aquele caminho tomado pela minha liderança realmente é o melhor pelo momento do projeto/empresa.
- Passaria a levantar essa bandeira sempre afinal quero que as coisas melhorem.
- Revisaria minhas opiniões contnuamente sobre a luz de vários fatos novos ou não enxergados anteriormente, afinal eu que poderia estar errado antes e não ter percebido.
- Se depois de algum tempo nada rolasse e eu percebesse que apenas eu estava ansiando por melhorias, pediria pra sair.
Simples assim, embora eu saiba que esse caminho não é viável e possível para todos e que muita gente realmente precisa daquele emprego que está alí.
Minha opinião pra você (além da que eu já dei no privado) é, espalhe a cultura de testes na equipe de desenvolvimento. Tente levantar as vantagens e argumente com seu time e liderança sobre a importância da equipe de dev ser dona dos testes automatizados. Pode ser de integração, unitário, BDD/TDD ou não, não importa, testar seu software de forma automatizada antes dele ir pra produção é redução de custos para o seu negócio. Claro que seus testes devem ser precisos e programados para proteger o que realmente importa para o negócio e não apenas testar por testar, que é onde ele gera apenas ônus. Saber avaliar também isso é primordial. A menos que você tenha uma base de usuários apaixonada pelo seu software e que lhe reportem bugs em produção por amor, geralmente bugs em produção são estressantes e tem custo monetário, portanto, teste, de preferência que o dev seja o dono de cobrir seu código-fonte com testes.
Como lhe disse, porém avalie seu cenário, não tem nada escrito em pedra e avaliar o cenário que você está inserido pode requerer algum esforço pra você conquistar um avanço nesse sentido. Não vai ser simples e no final das contas, vai ser um puta aprendizado.
Não fique com esse sentimento de a cada degrau do caminho já querer mudar de trampo, que isso não leva a lugar nenhum, sempre faça o exercício de buscar soluções de como mudar seu ambiente atual para melhor, isso vai lhe elevar como profissional.
Sair do emprego pessoal é a solução quando você já está sem energia depois de ter usado toda ela tentando mudar seu ambiente e nada se moveu ou se moveu em uma direção contrária, aí, com certeza é o lugar mesmo que não quer mudar e provavelmente os seus objetivos não combinam mais com o ambiente. Isso não necessariamente é certo ou errado, apenas seus objetivos não se encaixam mais com aquele ambiente.
Posso dar alguns muitos exemplos pessoais disso, sendo que já troquei algumas muitas vezes de trabalho e sei dizer exatamente porque em cada um deles, mas 2 em especial foram um grande aprendizado e tenho muito carinho pelo que deixei pra trás.
Enfim jovem, leia nossas opiniões, pondere, discorde ou concorde, mas ache seu próprio caminho, nossas verdades são as nossas, encontre a sua sempre pegando feedback de seus pares, superiores e da vida como um todo.
Abraços
A questão é que nem todo gestor aceita dialogar. Ainda mais quando está errado (e você prova isso).