5 Boas práticas para se aplicar em testes de aceitação

Neste post eu comento algumas boas práticas para se aplicar em testes de aceitação: http://shipit.resultadosdigitais.com.br/blog/5-boas-praticas-para-se-aplicar-em-testes-de-aceitacao/

Críticas e sugestões são muito bem vindas.

Lindomar, desculpe o trocadilho mas teu post está lindo!!! :)

Muito bem escrito, com ótimas dicas e com pitadas que todo testador que quer desenvolver testes de aceitação/funcional deve saber: agile testing, clean code, arquitetura de teste.

Escreva mais post! Ele está bem didátivo, parabéns!

Ótimo post!!! Parabéns!

Samy

@Elias-Nogueira Lhe respondi no Ship It!

Muito obrigado pelo feedback, ainda mais de uma das maiores referências em testes no país.

@Samanta-Cicilia Muito obrigado.

Legal @Lindomar-Reitz , muito bom ter você na nossa equipe! :)

Bárbara Cabral

@lindomar_reitz eu li mas esqueci de comentar… achei bem bacana :) congratz… continue postando!

@Leonardo-Galani Muito obrigado. Mais posts virão, pode deixar.

Muito boas as dicas!

Comecei a automatizar testes com TestComplete semana passada, e uma das coisas que você pontuou é o mesmo que meu atual líder diz: Nós não temos que validar se as regras, os valores, resultados, estão corretos, pois isto é responsabilidade dos testes de unidade e integração. Temos é que garantir que nenhuma funcionalidade importante, que funcionava, parou de funcionar após a aplicação de um release.

As vezes acho que a automação precisa sim validar valores… tipo… se a função for uma conta ou uma alteração de email… mas testar se a mensagem “email alterado com sucesso” foi exibida é meio ruim… fiz um post sobre isso a um tempin atras… (http://keeptesting.com.br/2015/01/05/teste-a-funcionalidade-e-nao-o-texto/)

:)

Atualmente já existe uma boa quantidade de testes automatizados, feitos por este atual líder. Alguns valores está sendo testado, mas a maioria não, devido à complexidade das regras. Por exemplo, existe alguns testes para faturamento de contas, mas o teste não verifica se os valores, lançamentos, classes gerenciais, classes contábeis, etc estão corretos. O teste simplesmente verifica se foi gerada uma fatura corretamente, sem apresentar “falha”. Isto porque seria muito trabalhoso realizar todos os testes. Não quer dizer que futuramente não podemos começar a detalhar mais os testes, mas que no momento estamos automatizando o geral, o mais utilizado, para depois ir especializando os testes. Querer automatizar tudo é complicado, e um dos motivos de projetos de automação falharem.

Concordo com o Leonardo.
O teste apenas verificar se não quebrou nada na visual não vai garantir que funcione corretamente.
Se um campo passar a aceitar um valor ou um tipo de dado que antes não aceitava certamente vai gerar uma inconformidade.
Acredito que já que vai testar se está gravando com sucesso, validar os campos logo pode evitar um retrabalho no futuro, dependendo do tamanho da aplicação. :D

@Bruno-Fernandes
Oi Bruno. Esse pensamento de automação não é errado, e chamamos ele muitas vezes de Smoke Tests. Ou seja, aqueles testes que irão dizer que o mais crítico da tua aplicação continua funcionando (como no teu caso da fatura).
Agora, e quando há algo errado no meio do processo? Como a aplicação de uma taxa maior do que esperado ou algo do gênero.

A automação serve pra isso mesmo!
Na minha opinião e o que eu tenho visto no mercado, com amigos e com clientes é que um dos motivos dos projetos de automação falharem é falta de pessoal qualificado e mentalidades como a que o teu líder tem, e não automatizar algo que seja trabalhoso.
Automação dá trabalho, e dá muito trabalho, mas é para justamente garantir que as partes mais críticas de sistema e regras estejam funcionando a cada regressão, ainda mais se foram as mais difíceis, pois tu só terá trabalho uma vez ;)

Abraço!

@Elias-Nogueira, muito obrigado por comentar! Poderia também me ajudar com mais algumas dúvidas?
Quando vemos a pirâmide de testes, igual foi colocado no artigo acima, a parte de valores não deveriam ser testados nos testes de unidade e integração?

piramide

Aqui temos uma sequência de pouco mais de 200 testes no testComplete e que demoram mais de duas horas para rodar. Quando digo que é complicado testar todas as opções, é porque são várias mesmo. Não tenho a informação exata, mas creio que exista pelo menos uma centena de parâmetros que influenciam em um faturamento, pois trabalho com um sistema ERP que está em uns 30 clientes diferentes, ou seja, cada cliente pode usar uma parametrização diferente.
Neste caso, testar cada valor, cada parâmetro possível, seria mesmo viável?
Eu faria todas estas alterações de parâmetros em um mesmo ambiente de teste (durante o teste) ou teria que ter uma base para cada cliente já parametrizada?
Se for uma base para cada cliente, o teste não teria que ser escrito uma vez para cada base, já que os dados também são diferentes? Uma maneira que enxergo de não precisar fazer um teste para cada cliente é caso exista uma certa “inteligência” no teste, por exemplo, fazendo selects para prever o resultado do teste, mas assim estaríamos reescrevendo os selects do sistema…

Resumindo, acho que algumas coisas mais simples até dá para verificar em um teste de UI, por exemplo, se um email está no formato de email, pois isso nunca muda. Mas realizar testes de valor limite, classes de equivalência, etc, acho que é responsabilidade dos testes de unidade… O que você acha?

@Bruno-Fernandes
A interpretação da Pirâmide de Automação de Testes é que os testes que devem ser dado o maior enfoque são da base da pirâmide, no sentido vertical. Logo testes de unidade pois são a base real de todo o código seguido de testes de integração de diferentes tipos (integração entre classes, banco, agentes externos, etc…) e depois de interface gráfica.
Eu desconheço na literatura (inclusive no livro do Succeeding with Agile do Mike Cohn [1] e nos principais posts sobre o assunto [2][3]) o foco em valores na parte unit e integration da pirâmida

[1] http://www.amazon.com/gp/product/0321579364
[2] https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
[3] http://martinfowler.com/bliki/TestPyramid.html

Talves alguém tenha feito a tradução errada de Value (que é para ser lido como valores/ganhos, para valor em termos de dados).

Testar cada parâmetro seria viável sim se isso é crítico, mas temos algumas técnicas para minimizar os testes e aumentar a cobertura. Um deles, clássico para esse cenário é o PairWise [4]
O que também tu podes fazer é adotar os testes frente aos parâmetros dos clientes que mais utilizam a aplciação ou passam pelos caminhos que estão parametrizados.
Também em teoria, se há um parâmetro, ele dificilmente é alterado e o valor será o mesmo. Se for diferente do que está no parâmetro versus o resultado do teu teste frente ao patâmetro certo é porque algum problema no código existe.
Ou mesmo, no momento de validar os valores que são influenciados por parâmetros, pode gerar funções que consultem o determinado parâmetro para aquele cliente e efetue o cálculo de determinado valor, comparando com o que há na tela. Isso te ajuda a aumentar a cobertura e deixa o teu teste com menos manutenção.

[4] http://www.pairwise.org

Isso seria a “inteligência do teste” (e quem disse que o teste não pode ter essa “inteligência”).
Também não vejo problema em “reescrever os selects”, já que isso pode ser facilmente alterado… E na verdade tu pode aproveitar o mesmo select já criado no código-fonte, tu já tem isso pronto! ;)

E não concordo contigo sobre o teu último parâgrafo…
Validar se um campo e-mail está no formato, verificar se o campo que só aceita números está aceitando letras, etc… é subutilizar a automação!
O que tu acha que é o contrário é o que deveria ser automatizado… a aplicação das técnicas de teste, a execução em cenários mais complexos… Isso vai te trazer ganho.
Obviamente tu pode ter isso no teste de unidade e vai ter, mas ele valida a unidade, não todo o exercício de um fluxo entre diferentes camadas na arquitetura de um software como temos via interface gráfica.

Tu tem o entendimento de automação que eu também tenho, só que ao contrário :P

Abraço!

@Elias-Nogueira
Meu inglês não é muito bom, mas acho que este artigo 2 que você passou, diz exatamente o que eu tentei dizer. É redundante e muito custoso realizar muitos testes na interface com o usuário, por isto, eles devem ser minimizados.

Automated user interface testing is placed at the top of the test automation pyramid because we want to do as little of it as possible. Suppose we wish to test a very simple calculator that allows a user to enter two integers, click either a multiply or divide button, and then see the result of that operation. To test this through the user interface, we would script a series of tests to drive the user interface, type the appropriate values into the fields, press the multiply or divide button, and then compare expected and actual values. Testing in this manner would certainly work but would be brittle, expensive, and time consuming. Additionally, testing an application this way is partially redundant—think about how many times a suite of tests like this will test the user interface. Each test case will invoke the code that connects the multiply or divide button to the code in the guts of the application that does the math. Each test case will also test the code that displays results. And so on. Testing through the user interface like this is expensive and should be minimized. Although there are many test cases that need to be invoked, not all need to be run through the user interface. And this is where the service layer of the test automation pyramid comes in. Although I refer to the middle layer of the test automation pyramid as the service layer, I am not restricting us to using only a service-oriented architecture.

Na minha visão então está divergente dos teus últimos comentários.

We want to do as little of it as possible
E isso é quase uma lei. Tu não vai automatizar todo o teu sistema, mas vai automatizar o que é mais crítico. O quer for mais crítico, mesmo que existe testes em outras camadas (unit, integration) será automatizado.

Testing in this manner would certainly work but would be brittle, expensive, and time consuming. Additionally, testing an application this way is partially redundant
No exemplo que foi colocado é totalmente redundante sim, leva mais tempo automatizar para UI do que unit e integration também e podem ser frágeis, demorados e custosos. Hoje em dia, com diversas técnicas e aplicação correta das ferramentas de automação isso pode ser bem minimizado. Cada sistema é um sistema. O teu deve ter várias camadas, e não ser uma simples calculadora ;)

Testing through the user interface like this is expensive and should be minimised
Concordo em gênero, número e grau, mas não é isso que estamos discutindo, certo?

And this is where the service layer of the test automation pyramid comes in
Concordo. Testar a parte de integration é negligenciada por muitos mas totalmente importante. Mas testar “valor” em integration é a mesma coisa que estar “valor” em UI (voltando ao foco principal da discussão)?

O que eu vejo do teu pensamento, ou do pensamento onde tu trabalha é que os testes são complexos, logo a automação em UI também será, mas isso nem sempre é verdade!

Abraço!

@Elias-Nogueira disse:

O que eu vejo do teu pensamento, ou do pensamento onde tu trabalha é que os testes são complexos, logo a automação em UI também será, mas isso nem sempre é verdade!

Você está certo neste ponto, pois tenho este pensamento mesmo. Espero que tenha razão e não seja tão complicado quanto parece rs
Nosso sistema é grande (4 mil tabelas e 44 mil campos) e começamos a automatizar a pouco tempo, então existe muita coisa sem teste automatizado, e ainda o sistema continua sempre crescendo com as implementações solicitadas pelos clientes. Estamos pensando na regra de Pareto, em que 80% dos problemas se encontram em 20% das funcionalidades. Mas mesmo assim, 20% das funcionalidades é muita coisa para nós.
Quando falei de não testar valor, não foi no sentido de “caracteres aceitáveis no campo”, “quantidade de caracteres”, valores que posso inputar nos campos. Acho que estes são perfeitamente normais se testar. O mais complicado é testar resultados de alguns processos complexos. Como no exemplo que citei. Como você disse, o sistema faz coisas mais complexas do que calcular 1 + 2 = 3 , seria mais como calcular

integral

Mas esta discussão me fez pensar em alguns testes que posso realizar a mais, ao invés de verificar apenas o fluxo principal, o caminho feliz… Estou só começando com automação de testes, espero aprender bastante ainda! :)

Show @Bruno-Fernandes
O que precisar pede ajuda aqui no Agile Testers ;)

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.