Quando minha equipe implementou o teste automatizado de UI, muitas coisas boas aconteceram.
Primeiro, a equipe de controle de qualidade se tornou muito mais eficiente no teste do aplicativo e também mais proficiente com o aplicativo. O líder do controle de qualidade disse que conseguiu atualizar rapidamente os novos membros, apresentando-os aos conjuntos de testes da interface do usuário.
Segundo, a qualidade dos tickets de controle de qualidade que retornaram à equipe de desenvolvimento era melhor. Em vez de "A página quebrou quando eu cliquei no botão Enviar", obtivemos o caso exato que falhou, para que pudéssemos ver o que foi inserido no formulário. A equipe de controle de qualidade também deu um passo adiante, verificando todos os casos que falharam e testaram outros cenários nessa página para nos dar uma melhor visão do que aconteceu.
Terceiro, a equipe de controle de qualidade teve mais tempo. Com esse tempo extra, eles puderam participar de mais reuniões de design. Isso, por sua vez, permitiu que eles escrevessem os novos casos do conjunto de testes ao mesmo tempo em que os Devs estavam codificando esses novos recursos.
Além disso, o teste de estresse utilizado na suíte de testes valia seu peso em ouro. Sinceramente, me ajudou a dormir melhor à noite, sabendo que nosso aplicativo podia suportar praticamente qualquer coisa lançada nele. Encontramos algumas páginas que resistiram à pressão que conseguimos corrigir antes de ir ao ar. Simplesmente perfeito.
A última coisa que descobrimos foi que, com alguns ajustes da equipe de controle de qualidade, também poderíamos fazer alguns testes de injeção de SQL em nosso aplicativo. Encontramos algumas vulnerabilidades que conseguimos corrigir rapidamente.
A configuração do conjunto de testes da interface do usuário levou um bom tempo. Mas, uma vez lá, tornou-se uma parte central do nosso processo de desenvolvimento.