A automação de testes no desenvolvimento de dispositivos móveis deve ser feita pela equipe do Scrum; não crie equipes de automação de testes separadas, disse Nadya Denisenko na European Testing Conference. Ela aconselhou a obedecer à pirâmide de testes para testes móveis e envolver testadores desde o início. Os testadores são desenvolvedores orientados a qualidade que podem orientar e auxiliar outros desenvolvedores a fornecer software de alta qualidade; e completa dizendo que testes manuais desaparecerão no futuro.
O desenvolvimento para dispositivos móveis é vendor lock. Existem dois grandes fornecedores em um mercado que determinam como o sistema operacional, os aplicativos, o desenvolvimento e os testes devem ocorrer, disse Denisenko. Além disso, a maioria das empresas está procurando por unicórnios de automação de testes que possam desenvolver testes automatizados em ambas as plataformas. Isso significa que engenheiros de automação em dispositivos móveis devem saber pelo menos Kotlin, Swift, Java e Objective-C e como o iOS e Android funcionam, e esperam que o engenheiro de automação possa testar manualmente o aplicativo, o que não é o caso, disse Denisenko.
Os aplicativos móveis são conhecidos pelo rápido desenvolvimento e, na maioria dos casos, o controle de qualidade está envolvido nos últimos estágios do processo, quando o produto está no mercado há algum tempo, disse Denisenko. Isso traz uma tonelada de desafios com a criação de processos de testes em uma equipe que se acostumou a trabalhar por um longo tempo sem um testador. Seu conselho seria começar devagar; em conjunto com os desenvolvedores, inicialmente criar uma estrutura de automação de testes, automatizar os recursos executados na sprint e montar um cenário de regressão.
Os projetos para dispositivos móveis são muito pequenos em comparação com a web ou backend; Não faz sentido ter uma equipe de automação separada para as tarefas que podem e devem ser atendidas pela equipe do Scrum, disse Denisenko.
Denisenko mencionou que o papel do testador é orientar e auxiliar os desenvolvedores na entrega de software de alta qualidade. Ela declarou: "Acredito firmemente que um testador é um desenvolvedor orientado a qualidade e que os testes manuais desaparecerão ou se transformarão no futuro".
Mais e mais empresas querem que os desenvolvedores cuidem dos testes, desenvolvendo códigos testáveis e modelos de testes, disse Denisenko. Ela fala de sua carreira de ser uma testadora manual para se tornar uma engenheira de automação de testes, acreditando que o papel dos testadores está se transformando em desenvolvedores de software focados em testes ou ainda desenvolvedores focados na qualidade.
O InfoQ está cobrindo a European Testing Conference 2019 e conversou com Nadya Denisenko após sua palestra sobre maneiras de fracassar na automação de testes de dispositivos móveis e como evitá-la.
InfoQ: Você afirmou em sua palestra que equipes de automação separadas são um desperdício de dinheiro. Poderia nos dizer por quê?
Nadya Denisenko: Um dos principais motivos é o design dos testes. A maioria usa a pirâmide de teste com 70% de testes unitários, 20% de testes de integração e 10% de testes E2E automatizados ao tomar decisões sobre cobertura de testes. É muito comum no mundo dos dispositivos móveis desobedecer à pirâmide de testes e acabar testando a coisas desnecessárias. Na maioria dos casos, ter uma equipe de automação separada significa que o foco principal de tal equipe é automatizar os testes E2E, portanto, faz mais sentido distribuir recursos de acordo com o design dos testes.
InfoQ: A pirâmide de testes se aplica melhor ou uma ampulheta ou cone de sorvete se encaixaria melhor?
Denisenko: Sim. A pirâmide de testes oferece melhor controle sobre o que está acontecendo no aplicativo e economiza tempo na depuração de um problema.
InfoQ: Por que os testadores de dispositivos móveis desobedecem à pirâmide de testes?
Denisenko: Existem várias razões e tudo depende da situação:
Silver Bullet. O gerenciamento e alguns desenvolvedores (especialmente os de backend) acham que, com testes da interface do usuário E2E, a execução contra o ambiente real em todas as situações da vida real pode ser coberta. Além disso, eles acham que esses testes cobrirão a ausência de testes de API, backend e testes de integração do cliente, o que está errado. Há tantas coisas que não podem ser testadas em dispositivos móveis por causa das limitações da plataforma. Um exemplo simples seria um link profundo de / para aplicativos externos e notificações push. As pessoas também tendem a esquecer que há muitas camadas entre o backend e a interface do aplicativo, onde tudo pode dar errado e não há estruturas que eu conheça que forneçam informações detalhadas de onde exatamente o problema aconteceu: terceiros, back-end, rede, implementação de rede no aplicativo, UI. Como resultado, os projetos acabam com testes inatingíveis e decepção na automação de testes.
Timing. Novos projetos móveis sempre começam como um MVP e depois se tornam algo grande. Sempre começa sem pensar na capacidade de testes do aplicativo, o que significa que o aplicativo não foi projetado para nada além de testes unitários e E2E. No momento em que os desenvolvedores veem a necessidade de testes detalhados, é muito caro fazer alterações e então as equipes apenas ignoram.
Expertise. Às vezes é apenas uma questão de especialização. O teste de integração é uma nova onda em testes móveis e nem todo desenvolvedor tem conhecimento e compreensão suficientes sobre o que é e como deve ser feito. Alguns nem têm vontade de aprender.
InfoQ: O que você aprendeu quando se trata de automatizar testes de dispositivos móveis?
Denisenko: Eu aprendi várias coisas:
- Nunca vacile quando entrar em um projeto sem automação;
- Ao desenvolver uma estrutura de automação de testes, tente usar, se possível, a estrutura de testes do fornecedor. As soluções de código aberto tendem a liberar suporte para as versões mais recentes do sistema operacional seis meses após o lançamento (o que significa que nenhum dos testes automatizados funcionará no novo sistema operacional) e também tendem a ser descontinuadas;
- Nunca tente adaptar testes que foram desenvolvidos para outro projeto. Acabei com a integração contínua de testes e correção de testes em todo o sprint, em vez de me concentrar no desenvolvimento e manutenção de meus próprios testes;
- Use linguagens nativas. Desenvolvedores são preguiçosos; eles nunca aprenderão ruby ou python apenas para fins de teste;
- Qualidade é uma responsabilidade compartilhada e cada membro da equipe deve contribuir para isso.
InfoQ: Quais diretrizes de teste a Apple e a Google fornecem e como podemos usá-las?
Denisenko: As diretrizes de teste são:
O Google sugere fazer testes em diferentes níveis: unidade, integração (integração entre componentes), teste de interface do usuário, teste funcional de interface do usuário, teste E2E. O Google tenta desenvolver uma geração de desenvolvedores que sabem testar seu código em diferentes níveis, de preferência com automação de testes. Eles criaram muitos tutoriais sobre isso e a comunidade de testes do Google é bastante vocal e ativa.
A Apple, no entanto, incentiva os desenvolvedores a desenvolver testes unitários e testes E2E. Eles sugerem que os desenvolvedores automatizem um aplicativo, pois usuários reais o utilizam e cobrem os testes E2E com automação.
Na minha opinião, os fornecedores não devem influenciar desenvolvedores e testadores, e permitir que eles decidam qual estratégia é melhor. Ao adicionar regras e estabelecer limites, eles realmente reduzem a possibilidade de que algo novo, melhor e inovador seja criado.