Teste de software é a pior carreira do planeta
Se você pensa que teste de software não exige habilidades técnicas, que é uma carreira para quem não quer aprender a programar ou que basta ter uma visão crítica do ponto de vista do negócio para ser um bom testador, creio que então será uma péssima escolha optar por esta carreira. Neste contexto, você terá que fazer um trabalho chato e repetitivo (no sentido de ter que testar a mesma aplicação em vários sistemas operacionais e browsers, e ainda em resoluções diferentes); você provavelmente estará trabalhando em um modelo de silos, com equipes de desenvolvimento e teste separadas, prejudicando questões relacionadas a confiança e qualidade dos entregáveis (visto que cada time “olha só para seu próprio umbigo”); logo após uma longa e cansativa bateria de testes manuais, seu trabalho pode não ser mais válido, devido a uma nova release recém entregue; horas extras passarão de excessão à regra em muitos casos, devido a falhas de estimativas, dependências entre projetos e atrasos; quando problemas forem encontrados em produção, poderão dizer que você não fez seu trabalho direito; suas possibilidades de crescimento estarão restritas a evoluir para um especialista em automação de testes ou um gestor de um time de testes (ambos considerados não tão importantes quanto os especialistas e gerentes dos times de desenvolvimento, em empresas tradicionais); além de trabalhar sabendo que o software sempre terá bugs, baixando sua auto-estima, pois por melhor que você teste, sempre haverá um novo bug, ou mesmo um antigo que voltou a ocorrer.
Sob a perspectiva de um dos revisores deste post, amigo e colega de profissão, Ramses Saccol de Almeida, tem também aquele monte de reuniões que duram horas, e ao final tudo muda e é executado diferente do planejado, e na pressa; existem também os problemas de massa de dados, muitas vezes diferentes em diferentes ambientes, causando dificuldades de debug e reprodução de problemas, além de falsos negativos; e os incontáveis relatórios (burocracias de projeto), que no fim das contas ninguém lê, ou simplesmente usam como métrica de vaidade.
Teste de software é a melhor carreira do planeta
Já se você acredita que teste de software é parte do desenvolvimento, se você não gosta de fazer trabalhos repetitivos e considera que o teste é de responsabilidade do time como um todo, então você escolheu a carreira certa.
Algumas empresas já perceberam os benefícios do teste de software como parte do cliclo de desenvolvimento de software desde seu início, com a prática de TDD (Test-driven development) e BDD (Behavior-driven development), ambas, técnicas em que o teste ocorre antes mesmo do desenvolvimento da funcionalidade. Neste contexto, o especialista em uma só área (neste caso o testador de software) nem sempre é necessário, mas sim um profissional generalista especialista (desenvolvedor que se preocupa também com o teste e questões de negócio), sendo todos desenvolvedores e testadores ao mesmo tempo. É claro, conforme comentou o revisor e também amigo, Moisés Ramirez, ainda não é tão fácil encontrar profissionais com este perfil, mas creio que seja uma meta a ser seguida.
Ainda neste contexto, o teste de software, diferente dos modelos tradicionais, é uma forma de previnir defeitos, não obrigatoriamente de encontrá-los, pois quando desenvolvemos o teste antes, já sabemos que na primeira execução ele irá falhar, mas com o tempo, vamos construindo uma arquitetura blindada contra falhas e que atende aos critérios de aceitação para o sistema chegar em produção.
Fora a automação dos testes, existem também as facilidades de automação de processos, tais como execução de programas que verificam padrões de código e sintaxe, e ferramentas que ajudam na integração contínua do código, notificando rapidamente o time quando algo quebrou, sendo fácil de identificar o que causou a falha para então atuar nela. Nestes casos, de preferencia um novo teste é criado para cobrir tal situação.
Quando novas funcionalidades tem que ser implementas em um sistema que é auto testável, o risco de introdução de bugs é menor, o retrabalho é menor e os envolvidos conseguem focar no que agrega mais valor ao negócio, conseguindo fazer entregas a tempo de trazer vantagem competitiva aos clientes/usuários do sistema.
Obviamente, é necessária uma visão do ponto de vista de negócio, mas a cada dia é mais nítido que isso não é mais habilidade só de quem trabalha com análise de negócios ou teste de software. Na “onda” da agilidade, habilidades técnicas + entendimento da perspectiva de negócio são questões compreendidas por quem entende os princípios ágeis e não é mais diferencial de pessoal que não vem do desenvolvimento.
E por fim (ao menos por hoje), o trabalho no desenvolvimento de softwares de alta qualidade (software desenvolvido com testes automatizados em todas as camadas, com bom nível de cobertura de código, com processos automatizados e com padrões e boas práticas de desenvolvimento de sistemas) é muito recompensador, pois construímos sistemas que facilitam a vida das pessoas, que tornam seus dias mais produtivos e que resolvem problemas reais.
TRADUÇÃO/ADAPTAÇÃO DE PRIDE AND PARADE, DE ALISTER SCOTT
Semana que vem o assunto é: Existe benefício em atender conferências de teste de software?
P.S.: Obrigado pela ajuda dos revisores: Clarissa Rodrigues, Gabriel Oliveira, Moisés Ramirez e Ramses Saccol
TALKING ABOUT TESTING 
Show! Perspectiva correta com atitudes correspondentes trazem satisfação.
Excelente texto.
Adorei seu artigo!
Resume bem a vida dos profissionais da área de testes!
Ou seja, sua perspectiva é que não exista mais profissionais de teste de software, mas programadores com foco na qualidade do software. Isto mesmo?
É mais ou menos por aí.
Na minha opinião a garantia da qualidade deve ser responsabilidade do desenvolvimento de software e existem técnicas de eXtreme programming, por exemplo, que viabilizam o desenvolvimento de software sem a necessidade de uma figura específica para o teste do software.
Outro ponto que tenho percebido na prática é que o “antigo” QA passa a agir como um coach, no sentido de guiar o time na utilização de práticas que dispensam o seu papel como uma parte separada do processo.
Hoje em dia me considero um desenvolvedor de software e não mais só um tester e meu foco é sempre na busca de me tornar um profissional melhor, buscando aprimorar as habilidades que já possuo, estudando e aprendendo habilidades que me são necessárias neste contexto e trabalhando de forma colaborativa em busca do melhor para o todo.
Olá Amigo.
Sou uma forte entusiasta do modelo ágil e acho a técnica de XP uma das melhores já aplicadas ao desenvolvimento de software.
Porém, lendo seu texto, sinto um fanatismo pela metodologia que pode vir a deturpar a figura da área de QA dentro de uma equipe de desenvolvimento. Deixo explicito aqui que equipe de desenvolvimento não se limita aos desenvolvedores, mas a todas as pessoas que de algum modo estão envolvidas nos projetos, sejam analistas de requisitos, analistas de testes, P.O’s. e inclusive os stakeholders.
Na minha visão, (TDD/BDD) testes realizados pelos desenvolvedores é essencialmente diferente dos testes realizados pelo analista de testes.
O TDD garante, ou pelo menos deveria garantir, por exemplo, que um sistema/aplicativo de leitura de livros chegue para testes, na área de QA, abrindo um livro, passando as paginas e possibilitando concluir com sucesso o seu objetivo que é realizar a leitura de X autor, descrevendo grosseiramente.
Mas o papel do analista de testes vai muito além de evitar falhas em uma determinada funcionalidade de um sistema. O analista é responsável por questões de usabilidade, de segurança, desempenho, requisitos não funcionais que os testes voltados para desenvolvimento não capazes de cobrir.
Sobre uma coisa não há o que contestar, testes unitários não funcionam como o raciocínio do usuário a cada clique. O teste unitário não garante que o usuário terá a melhor experiencia ao utilizar a aplicação. Não garante que porque funciona no seu AndroidStudio usando lolipop vai funcionar corretamente no Android 3.x. Não garante que sua resolução HD vai ser replicada para devices com resoluções inferiores. Ou que a memória ilimitada de sua IDE não vai estourar ao rodar a aplicação em um dispositivo real.
Nem garante por exemplo que seu sistema passaria em um teste de stress, com vários usuários usando ao mesmo tempo, ou que em um teste de carga o servidor se comportaria corretamente e processaria toda a demanda em um período de tempo que seja viável para o usuário final.
Você citou acima alguns exemplos de como a área de testes pode ser a pior do mundo, e sinceramente, se você não está disposto, por exemplo, a passar pelo trabalho de testar uma aplicação em diferentes web browsers que possuem arquitetura completamente distintas e posteriormente automatizar estes testes de forma funcional e não somente construindo uma serie de classes que validam estruturas de códigos e clausulas de IF/ELSE, você não possui perfil para atuar na área de qualidade.
Já vi equipes de desenvolvimento que aplicavam de forma muito eficiente a cultura de testes unitários e ainda assim serem encontradas diversas falhas em aplicações em evoluções e funcionalidades recém implementadas, e o motivo não era uma equipe de desenvolvimento baseada em TDD ineficaz, era pelo simples fato de que os testes unitários não cobrem todos os cenários possíveis, realizados por usuários comuns. São enfoques diferentes, que garantem coberturas diferentes.
A área de QA mudou ao longo dos anos e está mudando ainda mais com o movimento agile, nem de longe é a mesma de 5 ou 10 anos atras, mas o movimento não vem extinguir esse trabalho dos analistas, muito pelo contrario, ele faz com que a área de qualidade evolua, se molde e trabalhe junto com o restante da equipe de forma mais eficiente, para que ao final do prazo, entregue não somente um produto que funcione, mas um produto que tenha usabilidade, que seja resistente a falhas de segurança e suporte um alto nível de processamento, falhas de conexão ou tempo de resposta de aplicativos online, coisas que não poderiam ser garantidas em um ambiente que não fosse pelo menos próximo do real.. (Entre outros exemplo que citei anteriormente).
Teste de software vai muito além de clicar em um botão e fazer a funcionalidade quebrar, e se com todo seu conhecimento em agile, esta ainda é a visão que você mantém para o futuro de QA, aconselho que alguns conceitos sejam revistos.
Abraços.
Obrigado pela contribuição, Daiane, mas só lembrando que isso é somente uma tradução de um capítulo do livro Pride and Paradev, de Alister Scott, e não minha opinião pessoal. Ou seja, concordo com o que o Alister fala, mas também concordo com sua visão.
Daiane Macedo,
Meus parabéns pelo seu comentário, foi o melhor argumento que li até hoje.
De fato, a área de desenvolvimento não cobrirá todas as técnicas citadas acima. No máximo, no máximo um teste unitário ( Frameworks exigem uma cobertura mínima), e olhe lá !
O testador (analista e executor), além de ter seu conhecimento técnico, não pode esquecer de sua criatividade e seu alto nível investigativo, características fundamentais para o cargo. A boa comunicação nos diversos níveis durante todo o desenvolvimento de um sistema, precisa ser a meta entre todos os envolvidos – isso eu vejo mais vivo no ‘agile’. Automatizar pode engessar os testes SE o desenvolvedor não tiver as habilidades que julgo específicas de um bom analista de teste. Gostei muito dos argumentos, abraços. Adriano Barreto.
Eu diria de um bom engenheiro de software, independentemente se mais focado em testes, back-end, front-end ou o que for. 👍🏼
Relendo o comentário da Daiane, hoje eu diria que um desenvolvedor pode fazer tudo o que foi citado. Ou seja, você não precisa ser um analista de testes para se preocupar com usabilidade, testes funcionais, testes não funcionais como de performance e carga, e tudo mais. Isso é uma questão de profissionalismo, independente do seu papel.
E por fim, testes de unidade são sim, na minha opinião, uma das melhores garantias de sistemas de alta qualidade, se forem bem feitos, usando técnicas de TDD e BDD, e se tivermos uma alta cobertura (de 90% pra cima), mas não dá pra se iludir que serão uma bala de prata. Além disso TDD ajuda a escrever aplicações com um design mais bem pensado, mais simples, mais fácil de manter, e por consequência mais fácil de não introduzir bug.
E vc, o que acha?
Hoje me enquadro na parte de desenvolvimento, mas querendo me aventurar em cursos para testes de software, eu tendo esse conhecimento em desenvolvimento, serei um profissional na área de teste com algum diferente por ser saber programar? ou hoje em dia já é comum que o desenvolvedor migre para a área de teste?
Olá Thiago,
Não creio que seja tão comum desenvolvedores migrarem para testes (posso estar errado), mas tem sido comum que profissionais trabalhando com testes sejam mais técnicos e tenham conhecimento em desenvolvimento de software.
Creio que você pode se beneficar na área de testes, caso trate código de testes tão seriamente quando código de producão.
Qual seu background? Back-end, front-end, fullstack?