O documento descreve a estratégia de testes adotada pelo CESAR, conhecida como "Pirâmide de Testes Invertida", com foco em testes de interface do usuário e integração. A estratégia trouxe benefícios como detecção precoce de bugs e documentação, porém enfrentou desafios como tempo de execução longo e manutenção custosa. Melhorias futuras incluem reduzir testes manuais e end-to-end e fortalecer testes de unidade e integração.

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
- Instituto privado de inovação;
- Clientes de diversos ramos;
- Mais de 500 colaboradores;
- Sede no Recife;
- Filiais em Manaus, Sorocaba e
Curitiba;

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 portfolio. "
Martin Fowler
Autor
Alister Scott
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 Testing. Feito por QA manual
durante a sprint de features.
Integration & Unit:
Feitos por devs. QAs não tinha
contato, nem sabiam o que estava
sendo testado.
End to End:
Automatizados usando PHP behat
durante a sprint de automação.
Cone de Sorvete

15. Lições Aprendidas
3

16. Facilidade em identificar 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 automatizados, 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-times
O time 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 automatizada
Em dois projetos a execução durava mais de 12
horas.
Custosa análise do output da execução
Devido a quantidade 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 time participa do brainstorming e/ou
classificação dos testes em níveis.
Investir em outros níveis de testes
Estudos e provas de conceito sobre testes de
aceitação, componentes, API e contrato.
Entender as particularidades de cada projeto
Cada projeto devido as suas particularidades 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 participa 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
twitter.com/lari_lsls
linkedin.com/in/larissasls
karla.silva@cesar.org.br
twitter.com/karlambsilva
linkedin.com/in/karlambsilva
Larissa SoaresKarla Silva