O documento discute a importância da qualidade no desenvolvimento ágil de software e como os testes são fundamentais para garantir a satisfação do cliente e reduzir custos. Ele aborda a transição do modelo waterfall para práticas ágeis, enfatizando a colaboração e a qualidade compartilhada entre todos os membros da equipe. Além disso, menciona o Behavior Driven Development (BDD) como uma abordagem para alinhar o desenvolvimento com as expectativas dos stakeholders.

1. Agile Testing
A Qualidade de Software no Desenvolvimento Agile
C a r o l i n a B o r i m

2. Agenda
 Quem sou eu?
 O que é Qualidade?
 Por que Testar?
 Uma perspectiva - Waterfall
 O Manifesto Ágil
 Uma Nova Perspectiva – Agile Tester
 O Que Mudou Na Minha Vida? E o Software Livre?
 Contatos
2

3. 3
Quem sou eu?

4. 4

5. O QUE É QUALIDADE?
5
Se tratando de Software

6. O que é qualidade?
●Qualidade de um produto é dada pela diferença entre as
características observadas e as características que foram
especifcadas.
● Pontos de vista diferentes != diferentes requisitos
●Qualidade não pode ser uma entidade abstrata
●Objetivo concreto
● Conhecer com precisão o objetivo que se pretende alcançar
6

7. O que é qualidade?
Satisfazer o cliente

8. Mas basicamente
●Número e severidade de defeitos residuais do processo de
testes é aceitável
●O software é entregue dentro do prazo e custos
● Atende às expectativas
● Foi construído de maneira que possa ser mantido de forma
efciente

9. 9
Por que testar?
Testar software é simples?

10. Por que testar?
90% dos sistemas são liberados com defeito
Módulos não operam corretamente quando combinados
Programas tão difíceis de usar, que são descartados
Programas que simplesmente param de funcionar
10

11. O que é testar?
Testar – executar de forma controlada e avaliar o
comportamento baseado no especifcado
Quando testes são realizados dentro das melhores
práticas, contribui-se também para a melhoria da qualidade
e redução de custos
11

12. Por que testar?
Importância de se investir em testes:
– Reduzir custos
– Ao investir em testes, investimos na prevenção de
defeitos
–Validamos se a aplicação está em conformidade com as
necessidades e expectativas do cliente
12

13. Quais as consequências disso?
Maior satisfação do usuário
Maior redução das incertezas que cercam o software
Redução no custo de manutenção em produção
Mais confança no produto
Mais conhecimento do negócio
13

14. UMA PERSPECTIVA
1
4
O processo de desenvolvimento tradicional - Waterfall

15. O Modelo Cascata (Waterfall)
15

16. 16

17. 17
O manifesto ágil
Suas principais características

18. O Manifesto
“Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste
trabalho, passamos a valorizar:”
■ Indivíduos e interação entre eles mais que processos e
ferramentas
■ Software em funcionamento mais que documentação
abrangente
■ Colaboração com o cliente mais que negociação de contratos
■ Responder a mudanças mais que seguir um plano
18

19. O Manifesto
■ Implementar mudanças de forma mais efciente – documentação
viva;
■ Produtos com qualidade elevada – expectativas claras;
■ Menos retrabalho – colaboração;
■ Melhor alinhamento das atividades dos diferentes papéis no
projeto – fuxo mais regular.
19

20. collaboration
20

21. 21
Uma nova perspectiva
Agile Tester

22. Testador Ágil
Testadores ágeis são muitas vezes conhecidos como
analistas de qualidade (QAs), engenheiros de software em
testes, engenheiros de testes, lideres de qualidade, entre
outras varianças.
22

23. Uma ideia
“Desenvolvimento de software não é uma atividade
altamente previsível nem repetitiva, mas sim uma atividade
empírica. Agile enfatiza o controle do processo empírico.” –
Paulo Caroli.
23

24. Como trabalham?
Defensor do cliente
Defensor do produto
– Kick – of & Desck check
Trocando sempre de função
Intolerante a falhas
Constante interação com usuário
24

25. Habilidades
Desenvolvimento de Software – o que e quando
automatizar
Senso Crítico – Identifcar o atual nível de qualidade
Foco no usuário – identifcar causas de problemas
Clara comunicação – trabalhar em conjunto com todos os
membros do time
Generalista – observar o que testar e quando testar
25

26. Habilidades
Responsabilidades compartilhadas
Sem papél específco
Foco na entrega de valor
26

27. Responsabilidade
Não devem ser responsáveis apenas por aferir a qualidade,
mas também por ensinar aos demais membros do time
sobre a cultura de qualidade e garantir entregas
Lembre-se: qualidade não é algo fabricado ou criado após
algumas linhas de código
Lembrar também: Did the right thing & did the thing right?
27

28. Mas e o tal BDD?
BDD Behaviour Driven Development – reframming do TDD
É implementar uma aplicação a partir da descrição do seu
comportamento sob a perspectiva do Stakeholder
Entender o mundo do stakeholder
Escrever software que interessa – que tem valor!
28

29. Princípios
Enough is enough – o sufciente, adivinhe? É sufciente!
Entregar valor ao stakeholder
Tudo é comportamento – podemos usar sempre o mesmo
pensamento e a mesma construção de linguagem para
descrever o comportamento. Tanto em nivel de código
quanto em nível de aplicação
29

30. Princípios
“ BDD stories and scenarios are specifcally designed to
support this model of working and in particular to be both
easy to automate and clearly understandable by their
stakeholders “ The R-Spec Book
30

31. 31
O que mudou na
minha vida?
E o Software Livre?.

32. Ferramentas & Tecnologias
32
Cucumber
Junit
Rspec
Selenium WebDriver
Jmetter

33. Divirta-se!!
33

34. 34
Missões ambiciosas
Exigem ideias disruptivas

35. Obrigada!
Carolina Borim
cborim@thoughtworks.com
Skype: carolinaborim
Facebook: Carolina Borim
Twitter: @CarolinaBorim