Mini-Curso Agile Testing

Transcrição

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

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

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

4 Mais de 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:

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 Analistasutilizam terminologias específicas de sua área O Computadorentende 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árioefetua 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 consultasagendadas 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 s 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 Fontes para consulta:

20 User Story Quem? Papéis Personas O que? Ações Rotinas Porque? 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 Thenque conheceremos logo mais. Gerkin:

27 Critério de Aceite 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 Este mesmo documento pode ser utilizado por todos para: O desenvolvimento da aplicação Teste da aplicação Aceitação da aplicação

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:

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

37 Planejamento 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 Ênfase no planejamento, processos e roteiros detalhados Teste Tradicional Teste Ágil Ênfase nas pessoas

38 Planejamento 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)

39 Estratégia 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)

40 Estratégia

41 Quadrante 1 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.

42 Quadrante 2 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.

43 Quadrante 3 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!).

44 Quadrante 4 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.

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 TRADICIONAL Desenvolvimento Testes ÁGIL TESTE CONTÍNUO E AUTOMATIZADO Desenvolvimento Testes

48 Automação de Teste 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

49 Pirâmide de Automação de Teste

50 Unitário Os desenvolvedores testam sob a perspectiva do código (método por método) 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.

51 Benefícios: Unitário 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

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

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

54 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 Driver Componente A Mock Componente B Mock

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

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

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:

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

59 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

60 Manual Testes Exploratórios Ad-hoc Baseado em Sessão Teste baseado em roteiros Baseado em sessões Ad-hoc Muito formal Muito informal

61 Manual Testes Exploratórios Baseado em Sessão Charter Descrição e objetivo Tempo Área de Concentração Setup Observações Bugs 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:

63 (48) twitter.com/qualister facebook.com/qualister linkedin.com/company/qualister