O documento discute a estratégia de testes utilizando a "Pirâmide de Testes Invertida" em quatro projetos de um instituto de inovação. Foi utilizado o framework Behat para criar cenários de testes em linguagem natural que foram automatizados. Lições aprendidas incluem facilidade em identificar bugs, mas também alto tempo de execução e manutenção dos testes. Ações futuras incluem definir estratégia de testes em conjunto e investir em outros níveis de testes.

1. Lições Aprendidas:
Pirâmide de Testes Invertida
Agile Brasil, 2018
Karla Silva & Larissa Soares

2. Karla Silva
Engenheira de Testes
Larissa Soares
Engenheira de Testes

3. O CESAR
www.cesar.org.br
- Ins0tuto privado de inovação;
- Clientes de diversos ramos;
- Mais de 500 colaboradores;
- Sede no Recife;
- Filiais em Manaus, Sorocaba e
Curi0ba;

4. 1
Motivação

5. “The test pyramid is a way of thinking about different kinds of automated tests
should be used to create a balanced porHolio. "
Mar1n Fowler
Autor
Alister Sco8
Eng. Qualidade
“ 100,000 end-to-end selenium tests and success in the same sentence? WTF?
Sounds like a nightmare to me!"

6. E a sua pirâmide de testes?
(Ou outra forma geométrica)

7. Nível A
Nível B
Nível C
Draft

8. Contexto
2

9. Tecnologias
- Uso do behat (BDD framework
para PHP )
- Cenários de testes escritos em
linguagem natural (Gherkin)
- Criação de um framework para
end-to-end testes
UX
UI
DEV
QA
4 Projetos
Cliente
Internacional

10. codebase
Scope
I do the following on the <> table
I do the following on the <> area
I do the following on the page
Interaction
I click on the <>
I click and fill the <> field with the <> value
I hover over the <>
Assert
I am on the <> page
The <> text is <visible/hidden>
The <> is <enabled/disabled>

11. Processo de desenvolvimento
(plano original)
Sprint de UX
UX cria o .feature
2º dia da sprint
Dev usa os cenários
para o desenvolvimento
e codificação dos
testes.
Refinement
UX adiciona e revisa
os critérios de
aceitação
Planning
UX apresenta
o .feature que
contém a story como
escopo candidato
2º dia da sprint
QAs “explodem" os critérios de
aceitação em cenários
Story é entregue
QA usa o .feature
como script para o
test
Sprint de automação
QA Auto revisa as frases
do .feature, implementa as
funções necessárias

12. Feature: Login on the application
As a user
I want to be able to login on the application
so that I can I can successfully log in with my account
Scenario: Login on the app
Given I access the “login" page
When I fill in “login" field with “joao.silva”
And I fill in “password" field with “123@abc”
Then I should be on “home" page
Scenario: Sign out of the app
…
Login.feature

13. Processo de desenvolvimento
(plano original)
Sprint de UX
UX cria o .feature
2º dia da sprint
Dev usa os cenários
para o desenvolvimento
e codificação dos
testes.
Refinement
UX adiciona e revisa
os critérios de
aceitação
Planning
UX apresenta
o .feature que
contém a story como
escopo candidato
2º dia da sprint
QAs “explodem" os critérios de
aceitação em cenários
Story é entregue
QA usa o .feature
como script para o
test
Sprint de automação
QA Auto revisa as frases
do .feature, implementa as
funções necessárias

14. Manual:
Scripted Tes0ng. Feito por QA manual
durante a sprint de features.
Integra1on & Unit:
Feitos por devs. QAs não 0nha
contato, nem sabiam o que estava
sendo testado.
End to End:
Automa0zados usando PHP behat
durante a sprint de automação.
Cone de Sorvete

15. Lições Aprendidas
3

16. Facilidade em iden1ficar bugs que afetariam o
usuário final
Cobrimos um número considerável de fluxos de
experiência de um usuário real;
Cenários como documentação
Cenários de testes automa0zados, mas
escritos em linguagem natural (Gherkin);
1
Went Well
2
3
4
Facilidade para "rotacionar" pessoas
Quatro projetos usavam o mesmo codebase.
Diminuição do tempo de regressão manual
Em alguns projetos, a regressão levava 5 dias.
Com a suíte de testes e2e esses testes
passaram a ser executados em um tempo bem
menor.

17. Went Wrong
Falta de integração entre sub-1mes
O 0me de UX/Negócios optou por não seguir o
processo nas primeiras sprints.
Estratégia de Testes idealizada exclusivamente
por QAs
QA era responsável pelo brainstorming e design
dos testes da sprint
1
2

18. Went Wrong
3
4
Alto tempo de execução da suíte automa1zada
Em dois projetos a execução durava mais de 12
horas.
Custosa análise do output da execução
Devido a quan0dade de cenários, o output da
execução era muito extenso e trabalhoso de ser
analisado, mesmo com o auxilio de ferramentas.
Custos excessivos com manutenção
Testes End to End são conhecidos por serem
frágeis. Mudanças na estrutura das página/
componentes eram comuns e quebravam os
testes.
5

19. 1
Action Items
2
3
Definir a estratégia de Testes em conjunto
O 0me par0cipa do brainstorming e/ou
classificação dos testes em níveis.
Inves1r em outros níveis de testes
Estudos e provas de conceito sobre testes de
aceitação, componentes, API e contrato.
Entender as par1cularidades de cada projeto
Cada projeto devido as suas par0cularidades pode
ter necessidades de pirâmides diferentes.

20. Action Items
Minimizar os testes E2E de cada projeto
Ter uma suíte de testes e2e reduzida focada em
cenários de sanidade.
Analisar os testes unitários
QAs par0cipa na revisões do código dos testes
Adicionar diferentes níveis de testes no CI
Adição de testes de componente, aceitação e
API ao CI.
4
5
6

21. 4
Futuro

22. Onde queremos chegar?
Manual:
Testes exploratórios feitos por QA
UI:
Testes de aceitação (front-end) e testes end-
to-end feitos por QAs/devs.
Integração
Testes de API, componente, e integração.
Feitos por QAs/Devs.
Unitários:
Fundação sólida. Feitos por devs com a ajuda
de QAs.

23. Contato
lsls@cesar.org.br
twioer.com/lari_lsls
linkedin.com/in/larissasls
karla.silva@cesar.org.br
twioer.com/karlambsilva
linkedin.com/in/karlambsilva
Larissa SoaresKarla Silva