As abordagens de desenvolvimento nos últimos dez anos sofreram grandes mudanças, os requisitos para testadores (controle de qualidade, controle de qualidade, engenheiros de qualidade) também foram alterados. Mas nem todos os testadores estão prontos para entrar em um nível totalmente novo. Ontem foi possível sair da rua para entrar na profissão. Para se tornar um especialista procurado hoje, você precisa ser um engenheiro.
Ao iniciar uma carreira, foi apresentada uma apresentação nos cursos, comprovando a necessidade de testes. A assinatura do slide dizia: "Quanto mais cedo você encontrar um bug no ciclo de vida do produto, mais barato será corrigi-lo". As taxas de testes são mais baixas do que para os programadores. Contratamos testadores → garantimos a qualidade e economizamos no desenvolvimento. Lucro!
Os testadores eram caçadores de insetos. Os programadores escrevem recursos, um release está sendo preparado, o release passa pelo estágio de controle de qualidade. Naquele momento, o testador "vestiu o chapéu" de um usuário real e começou a executar cenários típicos. Acreditava-se que uma pessoa sem formação técnica seria adequada para essa posição.
A velocidade do desenvolvimento de projetos modernos aumentou. O conceito de CI / CD apareceu. Ninguém é surpreendido pelos projetos de liberação diária. As empresas perceberam que as verificações manuais não são escaláveis. Os testadores estavam envolvidos na automação dos testes de aceitação usando Selenium ou estruturas semelhantes. A mudança no interior está oculta, se apenas o front-end permanecer com os localizadores necessários.
E assim foi. Para os gerentes, a automação de testes está associada a uma habilidade: trabalhar com o Selenium. Em busca de uma bala de prata, eles viram nele a resposta para todas as perguntas. O mercado se ajustou à demanda.
Procuramos a automação do controle de qualidade para testar serviços da web há muito tempo. Examinei algumas centenas de currículos e realizei dezenas de entrevistas. Para resumir as impressões, três problemas principais podem ser distinguidos, o que geralmente impede a contratação de uma pessoa.
1. Os testadores não têm idéia da arquitetura do projeto
Aqui, por arquitetura, quero dizer uma descrição de alto nível das interações dos componentes do sistema. Convencionalmente, através do qual "canaliza" os dados, onde eles são armazenados e como são usados.
Durante a entrevista, o candidato pode se opor, dizem eles, que não precisamos de conhecimento de arquitetura. Trabalhamos com uma caixa preta. Por que cuidar da estrutura interna?
Não acredito que, com essa abordagem, o engenheiro venha com todos os cenários de teste possíveis. Se você conhece a estrutura interna do produto e lê o código, pode evitar a duplicação de testes em altos níveis da pirâmide de testes.
Variante da pirâmide por Martin Fowler
Nos testes da caixa preta, existe a mesma armadilha que na segurança através da obscuridade . Você não pode confiar apenas nesse tipo de teste. O produto pode atender aos requisitos estabelecidos, incluindo um grande número de bugs ocultos. Então, por analogia com a segurança através da obscuridade, a única garantia de qualidade será a nossa ignorância de como o sistema é organizado por dentro.
A vantagem do teste de caixa preta é que os testes são independentes da implementação. Uau. Mas essa restrição artificial não deve interferir na compreensão do interior. Quando o testador sabe como o produto funciona:
- Diante de um bug, ele é capaz de localizar o problema e não construir hipóteses.
- Na discussão de um novo recurso, ele está pronto para dar feedback, porque entende como o novo recurso se integra aos componentes existentes.
Malevich agita para testar a caixa preta
Provavelmente o mesmo amor pela caixa preta levou ao segundo problema.
2. Os testadores não entendem o que está acontecendo dentro do navegador
Muitas vezes, há uma situação em que um candidato cujo Selenium é indicado como a principal ferramenta no currículo não entende como o navegador e o protocolo HTTP funcionam. Testar para esses fabricantes de automóveis é principalmente a criação de scripts com ações do usuário. Uma abordagem superficial que cria restrições desnecessárias.
A maioria dos candidatos cita exemplos de códigos HTTP e tipos de solicitações HTTP. A próxima pergunta é muitas vezes desconcertante.
Existe uma página de login. O usuário digita os dados corretos para autorização e clica no botão de login. O que está acontecendo no navegador neste momento? Por que as ações subseqüentes com o site não exigem nova autorização?
Se o testador não respondeu a essas perguntas, surge uma dúvida sobre sua competência. Isso sugere que o candidato:
- não pode testar um produto sem uma interface do usuário;
- Não sabe como usar as Ferramentas do desenvolvedor em um navegador;
- Não estou acostumado a descobrir a causa do bug (front-end ou back-end).
Será mais fácil para o desenvolvedor corrigir o erro se for descrito com detalhes técnicos.
3. Atitude negligente em relação ao código do teste
"Meu código não entra em produção, por que se importar com a qualidade?"
Eu vejo isso como uma tentativa de dividir as caixas de areia. Deixe os desenvolvedores cuidarem da limpeza do código, mas nós podemos.
Lembre-se, no modelo em cascata após o desenvolvimento, houve um estágio de verificação? Durante o tempo da metodologia Waterfall, a responsabilidade pela qualidade foi transferida para o departamento de testes. Não levou a nada de bom. Os programadores não pensaram na prontidão do recurso, esperando que o controle de qualidade relate problemas. O pingue-pongue entre os departamentos levou a uma desaceleração no desenvolvimento. Esse é o preço para compartilhar responsabilidades.
Com o advento do Agile, as equipes se consolidaram. Faltam "nós" e "eles". A equipe é responsável pelo resultado final. E como as práticas de engenharia se tornaram comuns, os requisitos para o código de teste devem ser apresentados da mesma forma que para o código do produto.
Para abandonar os candidatos, enviamos uma tarefa de teste sem prazo:
Java http://todomvc.com/examples/react/
Lista de erros comuns
Complicações extras
Uma pilha de abstrações, invólucros sobre classes e código padrão dentro dos testes.
Os métodos de teste são feitos da maneira mais curta possível. As funções auxiliares e a separação da configuração das ações em objetos e verificações ajudarão nisso.
Violação de convenções para nomear classes, métodos, variáveis
CamelCase misturado com sublinhados. Então eles não usam agora. As dicas de Linter e IDE são salvas.
Caminhos de assistência do código rígido
String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
O clássico "funciona na minha máquina".
Armazenamento de arquivos binários dentro do repositório
Há git-lfs para resolver esse problema.
Falta de consistência nos métodos
Em uma solução, o candidato descreveu métodos para excluir e marcar "concluído" como este:
public void DeleteTask(String task) ... public void CompleteTask(int taskno)
No primeiro método, o texto da tarefa é transmitido, no segundo, o índice na lista. Usar essa API é doloroso.
System.out.println() para log
Ele não fornece informações de suporte em qual classe o evento ocorreu.
Usando Thread.sleep
Para resolver esse problema, existe uma biblioteca de aguardabilidade . Ajuda a adicionar feedback à expectativa do cumprimento da condição necessária.
Exceções gerais em vez de asert
Exemplo: um teste adiciona vários itens à lista de tarefas e marca todos os itens como concluídos. A idéia é que, em caso de problemas, o método findElement retorne um NoSuchElementException e o teste NoSuchElementException . Se você mais tarde examinar os resultados da execução do teste, NoSuchElementException será enganoso: não está claro se o teste realmente travou ou o código da curva de teste. É necessário usar um asert com uma mensagem de erro clara em caso de falha no teste.
Abuso de Atos Bálticos
assertTrue ou assertFalse é usado para tudo em uma linha:
assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
É melhor usar assertEquals aqui para ter contexto quando o teste falha.
Não há parametrização para executar testes
Exemplo: o URL do site para teste é pregado no código.
Também devemos mencionar o trabalho com o git . Na maioria das vezes, a tarefa foi enviada em uma única confirmação. Escrever mensagens de confirmação compreensíveis e dividir uma grande tarefa em várias separadas é uma habilidade necessária, especialmente no trabalho em equipe.
Conclusões
Os problemas descritos acima são minha experiência pessoal e impressões após as entrevistas. Segundo as observações, a experiência do candidato não se correlaciona com o número de lacunas. Evite testadores homeopáticos, invista tempo em aumentar as habilidades técnicas dos funcionários. Os testadores têm algo a aprender com os desenvolvedores e vice-versa. Que a força venha com aqueles que constroem a cultura da engenharia e nadam contra a maré.
Ficarei feliz em estar enganado e feliz se tudo for diferente na sua empresa contratada.
UPD 11/02/20 : No webinar “Tester Portrait”, compartilho minha opinião sobre como vejo a profissão por dentro.
- Por que uma empresa precisa de testadores?
- O papel do testador na equipe
- Teste automatizado VS manual
- Aspectos atrativos da profissão e preço da experiência
- Habilidades duras / flexíveis necessárias
- Erros no currículo de profissionais iniciantes
- Devops no teste
- Crescimento na carreira