View
215
Download
0
Category
Preview:
Citation preview
contato@qualister.com.br
(48) 3285-5615
twitter.com/qualister
facebook.com/qualister
linkedin.com/company/qualister
Mini-Curso Agile TestingComo funciona na prática?
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
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
Filosofia do Desenvolvimento ÁgilNeste tópico falaremos da base do desenvolvimento ágil, que é o ponto de partido para teste ágil.
Manifesto Ágil - Valores
Estamos descobrindo maneiras melhores de desenvolversoftware, 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/
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
Como guiar do desenvolvimentoNeste tópico falaremos sobre mecanismos que podemos utilizar para guiar o desenvolvimento de software com uma linguagem comum ao time
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
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
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
Linguagem Ubíqua
ERRADO
String string = new StringBuffer();
public class listDAO() {
public List<User> allData() {
try {
// codigo aqui
} catch (Exception e) {
e.printStackTrace();
}
}
}
Linguagem Ubíqua
CERTO
String usuario = new StringBuffer();
public class listaConsultasDia() {
public List<Medico> retornaTodosDados() {
try {
// codigo aqui
} catch (NaoHaConsultultasException e) {
e.printStackTrace();
}
}
}
Linguagem Ubíqua
Podemos aplicar a Linguagem Ubíqua em qualquer ponto do projeto:
• Requisitos (User Stories)
• Documentos
• E-mails
• Reuniões
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
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
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.htmhttp://xprogramming.com/articles/expcardconversationconfirmation/
Fontes para consulta:
User Story
Quem?
O que?
Porque?
Papéis
Personas
Ações
Rotinas
Estratégia no negócio
Efeito no produto
User Story - Modelo
Como um
<PAPEL>
eu posso/gostaria/devo
<FUNÇÃO>
para/de
<RESULTADO para o NEGÓCIO>
User Story - Exemplos
Como um aluno do de pós graduação EADeu gostaria de visualizar as notas de todas as disciplinas
Para saber se eu posso obter meu certificado
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>
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
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 disciplinaQuando eu clicar no link “Visualizar notas das disciplinas”Então eu visualizo cada disciplina cursada e a respectiva nota
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
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
Agile TestingNeste tópico falaremos o que é Agile Testing, a transição/transformação de um time ágil x tradicionais e nosso posicionamento nesta abordagem
O que é Agile Testing?
Agile Testing é uma prática de Teste
de Software que segue os princípios
do desenvolvimento ágil
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
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?
Quem é o Agile Tester
Conhecimento em testesCertificações
TécnicasFerramentas
Conhecimento no negócioRegras/Leis
Processos/WorkflowsRealidade do usuário
Conhecimento em computaçãoProgramação
Banco de dadosSistemas operacionais
Redes
Habilidades interpessoaisComunicaçãoVisão crítica
Respeito
Premissas: Equipe auto-gerenciável e multifuncional
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
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
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
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
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
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
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
Foco em Automação de TestesNeste 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.
Automação de Teste
Desenvolvimento Testes
Desenvolvimento Testes
TRADICIONAL
ÁGIL – TESTE CONTÍNUO E AUTOMATIZADO
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
• 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)
• 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:
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
• Unidades• Componentes• Sub-sistemas• API / WEB Services• Hardware• Banco de dados
Serviços
Integração Bottom-Up (Caixa Branca)
• 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
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
• Cenários de uso• End-to-End• Transações de negócio• Workflows
UI
Integração Top-Down (Caixa Preta) via Interface Gráfica
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/
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
• 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
• Ad-hoc• Baseado em Sessão
Manual
Testes Exploratórios
Teste baseado em roteiros Ad-hoc
Baseado em sessões
Mui
to fo
rmal
Mui
to in
form
al
• 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
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/
Recommended