mini-curso agile testing -...

63
[email protected] (48) 3285-5615 twitter.com/qualister facebook.com/qualister linkedin.com/company/qualister Mini-Curso Agile Testing Como funciona na prática?

Upload: truongthuy

Post on 08-Nov-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

[email protected]

(48) 3285-5615

twitter.com/qualister

facebook.com/qualister

linkedin.com/company/qualister

Mini-Curso Agile TestingComo funciona na prática?

Instrutor

Elias Nogueira <[email protected]>

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

Mais de 1.000 clientes

Parcerias internacionais

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

Título do slide

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

O que mais é importante saber?

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>

User Story

O que mais é importante saber?

Como testar!!!

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

Paradigma

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

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

Desenvolvedor Usuário

Testador

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

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

Estratégia

BaixoNível

AltoNível

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

Pirâmide de 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/

[email protected]

(48) 3285-5615

twitter.com/qualister

facebook.com/qualister

linkedin.com/company/qualister