Nessa palestra, a intenção é fazer uma descrição temporal da evolução do teste de software até chegarmos no conceito de Agile Testing.
Além disso, apresenta-se as características esperadas de um agile tester, bem como ferramentas e metodologias para o aprimoramento da Qualidade na entrega de produtos de software.
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
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
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
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
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
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
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?.