Atribuições de uma analista de testes unitários

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.

Puxa vida @javaflex, eu só queria saber como funciona na prática no mercado de trabalho.

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!

A questão é que nem todo gestor aceita dialogar. Ainda mais quando está errado (e você prova isso).

Sim, nesse caso não tem muito o que fazer. Ainda mais se o cara é o dono do negócio ou muito peixe do dono.

Eu falo com base em minhas experiências. Em geral, todos já possuem uma fórmula mágica (ou nem tanto assim).
Eu tive experiências em pequenas, médias e grandes empresas, com todo tipo de gestor.
Poucos foram os casos em que tive liberdade para chegar para o gestor e dizer que ele estava indo para um caminho incorreto. Mesmo com todas as provas de que a metodologia X era melhor que Y ou que modificar o processo nos pontos A, B e C daria resultados melhores.
Por fim, você acaba entendendo que o que manda é você estar em paz consigo mesmo.
Aliás, o sabor do “eu avisei” é o melhor que você vai conseguir desfrutar.

Pra você vê como a gente não pode cravar nada apenas com base em nossas próprias observações… Eu, pelo contrário vivi os 2 mundos. Tive chefe e tive líderes.

Consegui em muitos lugares expor minhas ideias e ser ouvido e já teve lugar que não precisei ser ouvido porque a equipe era absurdamente mais experiente que eu e aprendi muito com todos.

Porém recentemente eu tenho caído muito em lugares onde eu sou ouvido.

Sim, é bom, mas se parar pra pensar, quando engole, o sabor fica um pouco amargo no final, pois é muito melhor você ser ouvido e ter seu ambiente melhorado, pois se chegou ao ponto de você dizer eu avisei, é porque deu ruim…

Massageia o ego, concordo, mas eu pelo menos não desfruto tanto assim e tenho cada vez menos dito essa frase.

Cara, eu vivi os dois mundos. Mas, eu entendo que, no fim, o trabalho é só um meio para pagar minhas contas e me dar o conforto que eu quero, para mim e minha família.
Se você pretende fazer algo realmente inovador, DIY - faça você mesmo.
Abre uma empresa, mostre como se faz.

Sim, não se discutiu isso aqui ou se tirou o mérito de seu trabalho ser a forma que você usa pra pagar suas contas e não a razão da sua vida. Inclusive, exatamente por concordar com isso que hoje eu me esforço ao máximo para que esse ambiente seja o mais saudável possível. Luto para implantar as melhores práticas para que depois problemas em produção não venham tomar o meu tempo com as minhas filhas ou dos meu hobbies.

A menos que você diga que quando seu trabalho ou o trabalho da sua equipe quebra algo em produção você não está nem aí já que não está no horário de trabalho e que só vai olhar pra isso no outro dia ou na segunda-feira quando chegar na empresa. Aí ok. Eu já não consigo fazer isso. Querer que o meu trabalho não gere prejuízos para o estabelecimento que paga o salário que paga as minhas contas é muito meu. Por isso minha insistência com uso de testes automatizados, pois quanto menor a chance de colocar bugs em produção, mais tempo eu tenho pra minha família.

E exatamente por não conflitar com o que discutimos, quero que meu trabalho seja o mais fluido possível e insisto pra manter meu ambiente saudável, afinal esse papo de separar vida pessoal de profissional está cada vez mais caindo por terra, já que é muito difícil para o ser humano conseguir ser tão robotizado assim.

Abrir uma empresa é MUITO mais do que parece man… Sim, eu tenho atualmente 2 empresas em 2 modelos diferentes, sendo apenas um com CNPJ e atualmente voltei para o mercado CLT por Ns motivos.

Abrir uma empresa envolve muito mais do que apenas método de trabalho e para a maioria das pessoas pode realmente ser inviável alcançar isso e aí por essa filosofia, essas pessoas não teriam como inovar nunca. Porém não é bem assim, é muito comum pessoas empreenderem e inovarem em suas empregadoras. Pessoas brilhantes que se destacam, conseguem expressar e embasar suas opiniões e uma hora ou outra são ouvidas. Acontece muitas vezes dessas apanharem por isso, mas também é comum que algumas vezes essas pessoas se dêem bem e cresçam profissionalmente.

Sim, o mercado é uma merda e a chance de você ser martelado por se expor é grande, mas eu nunca conheci nenhum profissional que se destacou e foi contratado pelas maiores sem se expor.

O tema é bem complexo e tinha que ser resolvido na mesa de um bar, eu realmente entendo o seu ponto, mas hoje eu vejo as minhas opções muito mais complexa do que 0 ou 1, mesmo podendo viver de forma binária assim…

Abraços e valeu pela boa conversa

A questão de abrir uma empresa, no meu modo de ver e ignorando todas as burocracias existentes, é para que você faça do jeito que quer fazer, entendeu?
Defina os objetivos, a visão, missão e valores e vai atrás.
Sei que é muito mais que isso, ams, aí você pode determinar o que quer que tua empresa seja ou represente.

Sim, entendi sim

É uma das formas possíveis, mas longe de ser a única. Perceba que no post lá em cima o amigo pergunta sobre a nossa opinião em fazer testes unitários ser uma responsabilidade dele e ele ainda ter que corrigir os bugs encontrados durante o teste de outros desenvolvedores.

Como eu não concordo com isso, eu:

• Saio da empresa e abro minha própria empresa onde os devs serão obrigados a fazer os testes automatizados? Ou

• Mostro para o meu time a possibilidade de mudança e tento aplicar o que eu acredito que pode melhorar nossas entregas

Na opção 1 eu tenho o risco de ser empreendedor no Brasil, que é alto e caro, além de ter um propósito que logo logo pode se comprovar errado quando um dos meus funcionários me mostrar que podemos ir para outro caminho.

Na opção 2, testo uma alteração e vejo se encaixa para o meu time e descubro o quanto antes se podemos melhorar o processo ou abandoná-lo porque não se encaixa no nosso cenário. O que você acha que é mais simples?

Sempre tem a opção 3, que discutimos exaustivamente no post, do meu patrão não aceitar as mudanças e dizer “aqui quem manda sou eu”, que permite que você desligue seu modo proativo e vá ao mercado buscar novas oportunidades, nesse caso, você fica naquele lugar, trabalhando da forma que o dono quer, entregando seu trabalho com responsabilidade (enquanto recarrega suas energias para quando encontrar o próximo desafio) e vida que segue.

Isso aí é a vida, para nossa sorte, em TI temos muitas oportunidades fervendo pra tudo que é lado e temos essa possibilidade ainda, temos que aproveitá-la de forma saudável.

Por isso é cada vez mais comuns que candidatos em nossa área também comecem a entrevistar as empresas, afinal temos um pouco de poder em nossas mãos também, então antes de entrar na próxima empresa que vai me pagar 500 contos a mais que a anterior, eu sempre entrevisto meu entrevistador para saber até onde eu posso atuar dentro de onde estou me metendo e vejo, de acordo com a resposta dele, se eu embarco no projeto ou não.

Pelos casos que passei isso foi verdade, um esforço que não vale a pena. Imagina fazer teste unitário até de js. De nada adianta testar a parte do back se uma linha de js der pau.

Concordo que é útil pra quem desenvolve frameworks, mas testes funcionais são bem mais efetivos para sistemas de informação, testando regras diretamente no resultado real da aplicação, cobrindo todas as camadas de uma vez. O que chamam de integração também é útil em alguns casos.

Todos da equipe de qualidade. Se só tem você complica mesmo. Mas pra quem desenvolve funcionalidade o ideal é focar em resultados para produção, nao perder tempo programando teste.

Bom, vou te dar uma visão do que já vi acontecer ao aplicar testes unitários.

Você começa a se preocupar com a separação de responsabilidades e clareza do seus métodos/funções, facilitando e muito para depois conseguir separar em serviços pequenos e isolados.

Normalmente quando você me diz que testes unitários não agregam valor a um determinado projeto, eu só consigo enxergar um projeto de acoplamento fortíssimo, totalmente colado na cama dos dados e a uma arquitetura engessada que só evolui “jogando tudo fora e refazendo”.

Testes de integração são necessários para testar todas as partes juntas e numa arquitetura desacoplada normalmente são caros, porque é custoso unir todas as partes em testes únicos e simular os ambientes dos dados. Testes unitários garantem validação em partes granulares do seu código.

Claro que sempre aparecem os aloprados que testam métodos de retorno simples, mas aí é a extrapolação da técnica.

E no fim como já vi que agrega à evolução de arquiteturas meu conselho é que sempre o dono dos testes automatizados (pelo menos os unitários) sejam os próprios desenvolvedores, já que a ideia de evoluir a arquitetura depois parte dos mesmos.

Mas… Todavia… Entretanto… Se você está em uma empresa mais engessada e corporativa, tudo que falei acima é uma evolução em pequenos passos e é muito melhor ter uma equipe construindo testes do que teste nenhum. Cenário esse que eu já vi muito e tive que implantar 1 vez.

Bom expor essa experiência. Aqui nao dependemos do esforço de programar testes unitários pra ter separação de responsabilidades, clareza, etc.

Não é questão de dependência, mas de garantia. Depender de esforço humano para validar pedaços de software escritos por terceiros pode não ser uma boa.

Se sua equipe consegue, perfeito, você que deveria expor pra nós como funciona sem gerar conflitos de interesses, afinal é um case bem legal.

Normalmente deixar isso nas mãos de terceiros gera desencontro de informações e confusão de fluxo por quem não entende do código. Se você tem pessoas que não escrevem os códigos mas escrevem todos os testes e isso funciona redondinho, realmente vocês que deveriam virar case, pois são muito exceção da regra…

Compartilha aí o lugar onde trabalha também, deve ser um lugar foda de trabalhar onde tudo funciona perfeitamente bem

Teste unitário também nao garante nada, se a equipe for ruim podem fazer um produto ruim de manter mesmo com testes unitários.

De que esforço humano está falando?

• Código bonito e bem escrito também não.
• Usar a melhor tecnologia/framework pra resolver um problema também não.
• Atualizar Sistemas em tecnologias e versões mais novas também não.
• Pagar qualificações e certificações para seu time também não.
• etc… também não.

Nada que você faz pra melhorar seu ambiente garante nada… Você pode ter tudo isso e ainda fazer a solução errada. Porém você ainda faz pra tentar dirimir os riscos e não é certeza de acertar 100%.

é, acho que me expressei bem mal aí. Quis dizer mais no sentido de depender de uma pessoa entrando manualmente no sistema tendo que clicar em todas as combinações possíveis de inputs para testar seu software manualmente, ou seja, o que chamamos de teste caixa preta.

Concordo, acho que ninguém aqui está defendendo testes manuais. Só coloquei minha opinião que testes funcionais sao mais efetivos para sistemas de informacao. Já tive essa experiência com testes unitários, mas com os funcionais jogamos fora os unitários.