Este documento fornece informações sobre um mini-curso sobre teste ágil, incluindo contatos do instrutor e da empresa organizadora, Qualister. O curso abordará como o teste ágil funciona na prática e os princípios do desenvolvimento ágil.

1. contato@qualister.com.br
(48) 3285-5615
twitter.com/qualister
facebook.com/qualister
linkedin.com/company/qualister
Mini-Curso Agile Testing
Como funciona na prática?

2. Instrutor
Elias Nogueira <elias.nogueira@qualister.com.br>
Especialista em Automação de Teste de Software.
Professor convidado na Unisinos/RS e Uniasselvi/SC nas
disciplinas de automação de teste.
qualister.com.br
eliasnogueira
br.linkedin.com/in/eliasnogueira
github.com/eliasnogueira

3. Qualister
• Fundada em 2007
• Mais de 1.000 clientes em todo o Brasil
• Mais de 50 cursos sobre teste de software
• Mais de 3.000 alunos formados
• Áreas de atuação:
• Consultoria na área de teste qualidade de software
• Cursos
• Revenda de ferramentas

4. Mais de 1.000 clientes

5. Parcerias internacionais

6. Filosofia do Desenvolvimento Ágil
Neste tópico falaremos da base do desenvolvimento ágil,
que é o ponto de partido para teste ágil.

7. Título do slide

8. Manifesto Ágil - Valores
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações 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
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
Fonte: http://agilemanifesto.org/iso/ptbr/

9. Manifesto Ágil - Valores
• Todos esses valores e princípios influenciam e
guiam a forma, o método, as ferramentas e a
postura do “testador ágil”
• O ponto é consegui desenvolver software
seguinte estes valores para que possamos
entregar valor em um curto período de tempo

10. Como guiar do desenvolvimento
Neste tópico falaremos sobre mecanismos que podemos
utilizar para guiar o desenvolvimento de software com
uma linguagem comum ao time

11. Linguagem Ubíqua
Temos um grande problema no desenvolvimento
de um software dentro de uma equipe:
• Os Desenvolvedores utilizam palavras técnicas
• Os Analistas utilizam terminologias específicas de
sua área
• O Computador entende uma linguagem de
programação

12. Linguagem Ubíqua
Linguagem Ubíqua é uma linguagem estruturada
sobre o modelo de domínio e utilizada por todos
(cliente, desenvolvedores, analistas e testadores)
para conectar todas as atividades do time com o
software.
Mas isso está muito difícil... Preciso de exemplos

13. Linguagem Ubíqua
ERRADO
O usuário efetua o login com usuário e senha válido
e visualiza a tela com diversos campos
CERTO
O médico efetua o login com usuário e senha válido e
visualiza a a lista de consultas agendadas para o dia

14. Linguagem Ubíqua
ERRADO
String string = new StringBuffer();
public class listDAO() {
public List<User> allData() {
try {
// codigo aqui
} catch (Exception e) {
e.printStackTrace();
}
}
}

15. Linguagem Ubíqua
CERTO
String usuario = new StringBuffer();
public class listaConsultasDia() {
public List<Medico> retornaTodosDados() {
try {
// codigo aqui
} catch (NaoHaConsultultasException e) {
e.printStackTrace();
}
}
}

16. Linguagem Ubíqua
Podemos aplicar a Linguagem Ubíqua em qualquer
ponto do projeto:
• Requisitos (User Stories)
• Documentos
• E-mails
• Reuniões

17. Linguagem Ubíqua
Vantagens de utilização
• Menos risco de falta de entendimento
• Comunicação mais rápida e direta
• Conhecimento do domínio por todos
• Entendimento/clarificação de código

18. User Story
• Uma User Story representa funcionalidades que devem
fornecer valor para o negócio (projeto)
• Representa os requisitos (desejos), mais do que
documentá-los
• Fornece um flash para comunicação
• Sua definição de pronto orienta os testes necessários
para a estória

19. User Story
Um requisito é muito mais do que uma história para poder descrever
a necessidade do usuário.
Método 3C proposto por Ron Jeffries
• Card
• Conversation
• Confirmation
Estória Conversa Exemplos Requisito
http://www.agilemodeling.com/artifacts/userStory.htm
http://xprogramming.com/articles/expcardconversationconfirmation/
Fontes para
consulta:

20. User Story
Quem?
O que?
Porque?
Papéis
Personas
Ações
Rotinas
Estratégia no negócio
Efeito no produto

21. User Story - Modelo
Como um
<PAPEL>
eu posso/gostaria/devo
<FUNÇÃO>
para/de
<RESULTADO para o NEGÓCIO>

22. User Story - Exemplos
Como um aluno do de pós graduação EAD
eu gostaria de visualizar as notas de todas as disciplinas
Para saber se eu posso obter meu certificado

23. User Story
O que mais é importante saber?

24. User Story
Funcionalidade: <nome da funcionalidade>
Como um <papel/persona>
Eu quero/posso/gostaria <meta a ser alcançada>
De modo que <a razão para alcançar a meta>
NARRATIVA
-<Listar itens óbvios>
-<Listar itens que tenham relevância no software>
FORA DE ESCOPO
- <Listar o que o cliente não quer que seja desenvolvido>

25. User Story
O que mais é importante saber?
Como testar!!!

26. Critério de Aceite
• Um Critério de Aceitação é onde expressamos como
iremos garantir que um requisito (user story) será, além
de testável, validado e entendido pelo cliente e qualquer
pessoa do time.
• Ele utiliza a notação Gerkin Given – When – Then que
conheceremos logo mais.
Gerkin: https://github.com/cucumber/cucumber/wiki/Gherkin

27. Critério de Aceite
Este mesmo documento pode ser utilizado por todos para:
• O desenvolvimento da aplicação
• Teste da aplicação
• Aceitação da aplicação
Cenário: <descrição do teste>
Dado <pré-condição>
Quando <ação>
Então <resultado esperado>
Cenário: <descrição do teste>
Dado que eu estou na página da disciplina
Quando eu clicar no link “Visualizar notas das disciplinas”
Então eu visualizo cada disciplina cursada e a respectiva nota

28. Interação 1
Desenvolver somente um esboço (seu entendimento)
sobre o desejo do seu futuro usuário:
Eu sou um professor de matemática
Meus alunos não sabem os tipos de triângulos
Eu preciso de sistema para apresentar os tipos de
triângulos

29. Interação 2
Entreviste o usuário sobre o que ele precisa.
Você precisa desenvolver:
• User Story
• Critério de Aceitação
Dicas para acelerar e focar a extração de dados do usuário:
• Quem | O que? | Por que
• Narrativa (tudo que é óbvio/funcionalidade)
• Fora de escopo

30. Agile Testing
Neste tópico falaremos o que é Agile Testing, a
transição/transformação de um time ágil x tradicionais e
nosso posicionamento nesta abordagem

31. O que é Agile Testing?
Agile Testing é uma prática de Teste
de Software que segue os princípios
do desenvolvimento ágil

32. Paradigma
Fonte: http://www.slideshare.net/dwhelan/agile-testing-and-the-role-of-the-agile-tester

33. Quem é o Agile Tester
“Nós definimos o Agile Tester nesta forma: um profissional
de teste que abraça as mudanças, colabora bem com
pessoas técnicas de de negócios e entende o conceito de
utilizar testes para documentar os requisitos e guiar o
desenvolvimento“
Lisa Crispin e Janet Gregory
Fonte: Livro Agile Testing a Pratical Guide for Testers an Agile Team

34. Quem é o Agile Tester
Desenvolvedor Usuário
Testador

35. Quem é o Agile Tester
Mudanças de paradigmas
• Qual é o meu papel e as minhas responsabilidades?
• Como eu posso atuar mais próximo do desenvolvedor?
• O que devo fazer manualmente ou automaticamente?
• Eu tenho que programar?
• Como posso testar em ciclos curtos de desenvolvimento?
• Como posso testar em um ambiente onde a mudança é constante?
• Como posso testar sem requisitos detalhados?

36. Quem é o Agile Tester
Conhecimento em testes
Certificações
Técnicas
Ferramentas
Conhecimento no negócio
Regras/Leis
Processos/Workflows
Realidade do usuário
Conhecimento em computação
Programação
Banco de dados
Sistemas operacionais
Redes
Habilidades interpessoais
Comunicação
Visão crítica
Respeito
Premissas: Equipe auto-gerenciável e multifuncional

37. Planejamento de testes ágeis
• O mínimo necessário
• Guias e diretrizes (foco na intenção do que vai ser testado)
• Planilhas
• Checklists
• Conversa cara a cara
Planejamento
Teste
Tradicional
Ênfase no planejamento,
processos e roteiros
detalhados
Ênfase nas pessoas
Teste Ágil

38. Casos de testes ágeis (Mapas mentais, testes de aceitação, etc)
O foco é na exploração e automação de testes ao invés de casos de
testes tradicionais com roteiros (scripted)
Planejamento

39. Testes Ágeis x Testes Tradicionais
• Os objetivos são os mesmos
• Para confirmar se o software faz o que ele deve fazer
• Para confirmar se o software não faz o que ele não deveria fazer
• Para aferir o atendimento a um atributo de qualidade (implícito e
explícito)
• Encontrar defeitos
• A diferença é a abordagem (mais leve, mais rápida, mais cedo)
Estratégia

40. Estratégia

41. Testes que focam na arquitetura e suportam o time: São os testes de
unidade e de componentes. Estes são realizados e são de
responsabilidade dos próprios desenvolvedores. O papel do analista
de testes nesse quadrante é o de apoiar, suportar e mentorizar os
desenvolvedores sempre que necessário. De preferência isso é feito
através do "pairing" com o desenvolvedor no momento de elaborar
os testes unitários automatizados.
Quadrante 1

42. Testes que focam no negócio e suportam o time: São testes
funcionais diferenciados, que idealmente utilizam a técnica de
Behaviour-Driven Development e Acceptance Test-Driven
Development. Isto é, são testes e cenários de exemplo realizados
pelos testadores em conjunto com os clientes, usuários e analistas
de negócio. Com base nesses exemplos e cenários os
desenvolvedores terão melhores condições de desenvolver e
entender os requisitos. Além disso, utilizam-se de ferramentas
adequadas (como o Fitnesse ou o Concordion, por exemplo), uma
parte desses testes serão automatizados antes ou em paralelo com o
desenvolvimento do cenário. Portanto, o foco desses testes não é
encontrar o maior número de defeitos e sim ajudar clientes e
desenvolvedores a terem um melhor entendimento.
Quadrante 2

43. Testes que focam no negócio e criticam o produto: Esses são o que
chamamos de testes "clássicos". Os testes de aceitação feitos na
homologação do produto ou de suas partes, testes beta e testes
exploratórios. Estes são feitos não com o objetivo de dizer que o
software funciona mas, pelo contrário, de encontrar defeitos. Essa
categoria as vezes é negligenciada por alguns agilistas mais radicais.
Mas a verdade é que bons analistas de testes possuem técnicas para
encontrar defeitos que poucos desenvolvedores conhecem (até
porque o papel do desenvolvedor é construir e o do testador, neste
quadrante, é o de destruir!).
Quadrante 3

44. Testes que focam na arquitetura e criticam o produto: São os testes
de performance, de carga e de segurança. Estes são de
responsabilidade dos analistas de testes e costumam ser feitos
quando pedaços da aplicação já estão prontas e, especialmente,
antes da entrada de um release em produção.
Quadrante 4

45. Estratégia
Baixo
Nível
Alto
Nível

46. Foco em Automação de Testes
Neste tópico falaremos porque é tão importante focar em
automação de teste em um time ágil e o papel do testador
nesta automação.

47. Automação de Teste
Desenvolvimento Testes
Desenvolvimento Testes
TRADICIONAL
ÁGIL – TESTE CONTÍNUO E AUTOMATIZADO

48. Por que é dado um grande enfoque em automação de testes?
• A automação viabiliza ciclos curtos de entrega
• A automação pode fazer parte de um ciclo de integração contínua
fornecendo feedback contínuo
• A automação oferece uma rede de segurança por meio de regressões
completas
• A automação permite a implementação do conceito DRY (Don’t Repeat
Yourself) e libera as pessoas para realizarem tarefas mais criativas ao invés
de terem que executar testes manuais, enfadonhos e repetitivo
Automação de Teste

49. Pirâmide de Automação de Teste

50. • Enquanto nas metodologias tradicionais o desenvolvedor apenas escreve
código, nas metodologias ágeis o desenvolvedor também é responsável
pelos testes. No entanto, os testes do desenvolvedor tem o objetivo de
prevenir e detectar defeitos na perspectiva do código.
• Ou seja, o desenvolvedor deve garantir a qualidade de cada unidade do
código individualmente. Unidade, neste contexto, deve ser entendida como
o menor trecho de código de um software que pode ser testado, podendo
ser uma função ou procedimento em linguagens de programação
procedurais ou métodos de classes em linguagens orientadas a objetos.
Unitário
Os desenvolvedores testam sob a perspectiva do código (método
por método)

51. • Testes unitários fornece feedback imediato ao desenvolvedor quando ele
comete um erro
• Testes unitários fornece um rede de segurança que identifica regressões
• Testes unitários ajudam na identificação e isolamento de defeitos
• Testes unitários em conjunto com profilers de cobertura fornece uma
visualização das áreas do software cobertas por testes
• Testes unitários fornece um exemplo executável de como funciona o código
Unitário
Benefícios:

52. Interação 3
Iremos melhorar os testes unitários do desenvolvedor
Faremos uma sessão de pair para descobrir quais os testes
unitários implementados e quais podemos adicionar

53. • Unidades
• Componentes
• Sub-sistemas
• API / WEB Services
• Hardware
• Banco de dados
Serviços
Integração Bottom-Up (Caixa Branca)

54. • Teste de baixo nível dos componentes e API’s internas do sistema sem acesso a
interface gráfica
Serviços
Integração Bottom-Up (Caixa Branca)
Componente A
Componente B
Driver
MockMock

55. Interação 4
Criaremos a “casca” da automação de serviços baseados
no critério de aceite
Faremos uma sessão de pair com o desenvolvedor para
automatizar o critério de aceite no nível de serviço

56. • Cenários de uso
• End-to-End
• Transações de negócio
• Workflows
UI
Integração Top-Down (Caixa Preta) via Interface Gráfica

57. Interação 5
Criaremos a automação funcional/aceitação para o
sistema web
Iremos automatizar o sistema web com uma ferramenta
para garantir a aceitação do usuário
Link: http://triangulos-3.herokuapp.com/

58. Simultâneamente ....
... aprender sobre o software
... desenvolver mais testes
... executar testes
Usando o feedback do último teste para executar o próximo!
Manual
Testes Exploratórios

59. • Os testes não são criados com antecedência
• Não segue um roteiro rígido (segue guias e diretrizes)
• É baseado em pensamento estruturado e exploração livre
• É adaptativo e flexível
• Enfoca o aprendizado em paralelo
• A execução do teste é guiada/aprimorada com base em execuções
anteriores
• Exige profissionais experientes
• Expande o escopo dos testes tradicionais baseados em roteiros
(Injeta/introduz variação aos casos de testes)
• Fluxo imediato de feedback (e correção de curso)
• Amplifica a cobertura dos testes
Manual
Testes Exploratórios

60. • Ad-hoc
• Baseado em Sessão
Manual
Testes Exploratórios
Teste baseado
em roteiros Ad-hoc
Baseado em
sessões
Muitoformal
Muitoinformal

61. • Charter
• Descrição e objetivo
• Tempo
• Área de Concentração
• Setup
• Observações
• Bugs
Manual
Testes Exploratórios Baseado em Sessão
Explorar áreas/features [com recursos, condições , restrições] para
descobrir informação
Explorar o site em diversos browsers e configurações para descobrir
riscos relacionados a configurações não suportadas

62. Interação 6
Executaremos um teste manual (exploratório) para as
mudanças no sistema web
Crie um charter e explore novamente a aplicação
• Tempo: 15 min
• Link: http://triangulos-3.herokuapp.com/

63. contato@qualister.com.br
(48) 3285-5615
twitter.com/qualister
facebook.com/qualister
linkedin.com/company/qualister