Preparamos para você a tradução de um artigo de Dmitry Yarygin, engenheiro de controle de qualidade com experiência em grandes projetos do mundo há mais de 8 anos, professor do curso de engenheiro de controle de qualidade móvel da OTUS. É interessante desenvolver nessa direção? Convidamos você a fazer uma "Introdução gratuita e intensiva de dois dias à testes de aplicativos móveis no Selenium e Appium" .

Teste de qualidade. Quem é responsável por isso? Por muitos anos, a única resposta para essa pergunta estava na minha cabeça. Claro, um engenheiro de controle de qualidade! Afinal, eu próprio pertenço aos engenheiros de controle de qualidade.

Sei com certeza o quanto é importante testar a qualidade de um produto de software que está planejado para ser lançado no mercado. No entanto, notei alguns padrões que ocorrem durante o teste. Eles me fizeram pensar sobre o processo de teste como um todo e como ele poderia ser melhorado.

Os desenvolvedores devem testar seu código?

Obrigado por perguntar. Se você é um desenvolvedor, conhece todas as sutilezas e armadilhas do seu código ou, pelo menos, sabe mais sobre ele do que um engenheiro de controle de qualidade. Você conhece seu código amplamente e entende onde o problema pode surgir.

Se você souber onde a área do problema pode estar, informe o engenheiro de controle de qualidade. Sim, ele mesmo o encontrará em algum momento específico, mas você ainda conhece melhor a arquitetura do aplicativo. Os testadores ficarão gratos se você lhes disser onde esperar problemas.

Somos engenheiros de controle de qualidade, vamos nos concentrar nele e cobri-lo com testes para que você fique menos preocupado. Qualquer informação adicional que os desenvolvedores possam fornecer é claramente benéfica.

Os testes de unidade são definitivamente algo que os desenvolvedores devem fazer, essa é sua área de responsabilidade. Os testes de unidade ajudarão a evitar erros desnecessários e relatórios desnecessários sobre eles. Melhor evitar o erro antes que o código chegue à equipe de testadores, certo?

Algumas palavras sobre como testar seu próprio código. Eu acredito que os desenvolvedores devem pelo menos fazer testes de fumaça de seu código. Nenhum teste extensivo é necessário. Apenas verifique se o código funciona em algum conjunto de dados de entrada e entregue-o à equipe do testador para que eles já trabalhem nele.

Se o código ainda não funcionar nesse estágio, por que entregá-lo ao controle de qualidade? Você receberá dezenas de mensagens de erro, apesar de já saber que existem problemas - isso apenas atrasará o processo de desenvolvimento.

Perdemos o bug. Os testadores são os culpados?

Sim e não Toda vez que um erro é detectado, especialmente na produção, você e sua equipe têm algo a discutir. Há várias razões pelas quais o erro apareceu apenas nesta fase:

1. O local onde o erro apareceu nunca foi uma prioridade para os testadores. Muitas vezes, ninguém pensava no erro que aparecia na produção. Este é o resultado de uma falta de comunicação entre desenvolvedores e testadores. Não foi alcançado entendimento mútuo sobre a importância de verificar uma área. Exemplos clássicos dessa negligência são problemas de desempenho e segurança. Se você souber que essas áreas são críticas para o seu aplicativo, informe a equipe.
2. O controle de qualidade não possui o conhecimento necessário na área testada. Este também é um problema comum. Os desenvolvedores escreveram a função e assumiram automaticamente que o controle de qualidade entende como funciona de e para. Bem, fazer suposições nunca foi uma boa estratégia para analisar a qualidade de um projeto sério. Se você observar algum aspecto importante, verifique se o engenheiro principal de controle de qualidade e sua equipe também o veem e entendem. Não há como contornar esta etapa.
3. Os desenvolvedores realmente não se importam. Somos todos humanos. E todos nós temos uma vida fora do trabalho. Alguns desenvolvedores trabalham duro para criar um produto de alta qualidade, conversam com testadores, informam sobre possíveis problemas e coisas do gênero. E há desenvolvedores que não se importam. Eles não usam este produto todos os dias e não entendem sua importância. Para eles, essa é apenas uma tarefa paralela que precisa ser concluída e esquecida. Simplificando, eles não se importam que o produto final seja de qualidade inadequada.
4. Os engenheiros de controle de qualidade não se importam. Aqui está o outro lado da moeda. Nem todos os testadores se preocupam com o projeto. Alguns só precisam terminar os testes, fazer um relatório bonito e esquecê-lo. A cobertura de teste de alta qualidade não os incomoda, eles não querem se comunicar com os desenvolvedores. Você pode discutir bugs, mas esses testadores podem simplesmente não considerá-los importantes ou até mesmo se registrar.
5. Os testadores não são qualificados o suficiente. Outro problema pode estar no fato de que os testadores simplesmente não são qualificados o suficiente para testar seu aplicativo. Por exemplo, você precisa realizar testes de penetração e tudo o que está à sua disposição é uma equipe de testadores que pode realizar apenas testes manuais. Nesse caso, eles simplesmente não saberão como abordá-lo. Aqui você precisa contar com os desenvolvedores ou selecionar mais
   Engenheiros de controle de qualidade qualificados que saberão exatamente como testar esta área específica.
6. Falta de pesquisa do usuário. Os desenvolvedores sabem como criar um aplicativo e os engenheiros de controle de qualidade como quebrá-lo. E os usuários? Usuários são pessoas reais que usarão seu aplicativo no mundo real. Eles não vão quebrar isso. Só que eles são todos diferentes e têm objetivos diferentes, mas todos desejam alcançá-los usando seu aplicativo. Os engenheiros de controle de qualidade podem se acostumar com o erro e perceber que isso ocorre com pouca frequência; portanto, isso não importa muito. O usuário não vai tolerar isso. Se seu aplicativo falhar, a próxima etapa é removê-lo e, em seguida, procure uma alternativa. Essa é a realidade. Pesquisando uma audiência de usuários e / ou tendo um grupo de usuários de teste são duas coisas estrategicamente importantes.
7. Má organização do processo de comunicação. Idealmente, você precisa de um processo simples para classificar os erros que permitiria avaliar erros de controle de qualidade (ou pelo menos classificá-los corretamente) e repassá-los aos desenvolvedores para que eles entendessem sua carga de trabalho. Quando houver algum mal-entendido, o testador e o desenvolvedor sempre devem poder se aproximar e resolver esse problema em alguns minutos ou horas. Se esse processo não for estabelecido e os dois lados não tiverem pressa de procurar a causa do mal-entendido, nada de bom resultará disso. Ambos os lados imitarão as atividades, mas, na verdade, estarão em um beco sem saída e aguardarão alguém terceiro que possa vir e resolver magicamente a situação. Esta é fundamentalmente a abordagem errada.
8. Testadores insuficientes. Um aplicativo pode ser complexo e pode exigir testes em várias plataformas e navegadores. Apenas alguns engenheiros de controle de qualidade para esta tarefa podem não ser suficientes. Considere contratar mais pessoas ou redistribuir os recursos que você possui para aumentar a ênfase nos testes.
9. Os desenvolvedores estão sobrecarregados. Ao seu redor, podem ser especialistas ideais e altamente qualificados, mas eles trabalham em constante estresse e ninguém pode ajudá-los. Sim, eles estão sob pressão e não têm tempo para conversar com a equipe de controle de qualidade. Esse é um problema muito comum e é uma das principais razões pelas quais o software é de baixa qualidade.
10. Qualidade não está no centro das atenções. Considere esse cenário também. Aqui e havia alguns bugs menores. Nenhum deles é crítico. No entanto, os usuários não gostam do aplicativo. Comentários são ruins. O UX está abaixo da média. E porque Sim, porque ninguém pensou em criar um produto de qualidade. Os desenvolvedores fizeram seu trabalho, os testadores fizeram seus próprios, mas ninguém seguiu o processo de controle de qualidade. O desenvolvimento de aplicativos deve combinar equipes, tornando-as um todo. Se o coletivo não tem esse humor, ninguém se importa com a qualidade.

Conclusão

Hoje, os aplicativos estão ficando cada vez mais difíceis. Se você quiser descobrir quem é o culpado pelo fracasso do projeto, é fácil. A culpa pode ser de engenheiros de controle de qualidade, desenvolvedores e executivos. Ou todos juntos. A principal questão é por que devemos procurar culpar aqueles em vez de assumir a responsabilidade pela qualidade do projeto? Quem não percebeu a importância de testar uma função específica pode estar no lugar do culpado.

A única pergunta deve ser: "Estamos fazendo um produto realmente bom?" . Se a resposta a essa pergunta for afirmativa, não haverá dúvida de que todas as equipes estão fazendo uma grande coisa.

Ninguém terá que culpar e todos ficarão felizes, porque garantia de qualidade é uma tarefa comum!