ABOUT ME !
Kamilla Queiróz (MihQueiróz)
• Cearense adotada pelo Rio Grande do Sul
• Analista de Testes @NeoGrid
• Tecnóloga em Análise e Desenvolvimento de Sistemas
• Pós-Graduando Teste e Qualidade de Software
• Mantedora do Blog MihQueiroz.com.br
• En.tu.si.as.ta e hóspede do Mundo
Contato:
• Email: q.kamilla@gmail.com
• Blog: mihqueiroz.com.br
• Twitter: twitter.com/MihQueiroz
• Facebook: facebook.com/kamilla.queiroz
• LinkedIn: linkedin.com/kamilla.queiroz
• SlideShare: slideshare.net/kamilla.queirz
AGENDA
- Qual futuro no cenário Ágil
- DevQA um futuro para Analistas de Testes [?]
- Testar Testes Unitários [!][?]
- Qualidade de Código
- Especificações Vivas
Qual futuro no cenário Ágil
O que percebi:
em abril de 2015 AgileTrends – após
palestra Testador Ágil 3.0 de Daniel
Amorim
/*
ninguém sabia ao certo qual era o papel
do testador no contexto ágil
*/
‘todo mundo’
/*
os principais profissionais que eu
conhecia
*/
tinham em mente que ser ágil era APENAS
automatizar testes
os testes continuavam sendo deixados
para “trás”
/*
salvem-se quem puder e testar o que der
*/
ou seja cenário “ágil” para o
desenvolvimento e waterfall / cascata
para testes
IN – JUS – TI - ÇA!
Mas [1] ainda se falava sobre:
- QA DevOps
- QA Técnico
- Analista Automatizador
E o que esses ‘cristões’ fazem de tão
diferente que precisam ser / ter
atividades distintas dos Analistas de
Testes / Testadores [??]
Mas [2] temos e precisamos enxergar o
Analista de Testes como:
[!]
PARTE INTEGRANTE E
ATUANTE DE UMA EQUIPE DE
DESENVOLVIMENTO
[!]
O CARA
que dissemina a qualidade por
todo os processo de
desenvolvimento
[!]
O CARA
que trabalha para evitar
inconformidades
DevQA
- Mudança de Paradigma [?]
- [tchau tchau] zona de conforto [!] [!]
- reinventar atividades [comuns]
- auxiliar sua equipe [por completo][!]
/*
Skills ampliadas (analítico & crítico)
Lógica de programação
Escrever scripts (mesmo simples)
Noções de BD e Webservices
Builds e Integração Contínua
*/
- Skills ampliadas
/*
além do conhecimento do negócio
conhecimento técnico
*/
- Lógica de programação &
- Escrever Scripts
/*
for
if / else
*/
- Banco de Dados & Webservices
/*
validar dados
validar conexões
*/
- Builds e Integração Contínua
/*
autonomia para gerar versões
autonomia para execução de testes
*/
Testar Testes de Unidade
- Validar se:
- Estão escritos corretamente
- Estão sendo efetivos
- A cobertura está gerando valor
Mutation Testing
/*
altera-se uma parte do código para
induzir falhas simples
por meio do Bebuging
*/
- Mutações possíveis:
Intra – method
Inter – method
Intra – class
Inter - class
MuJava
/*
Ferramenta para
Java
Ajuda na mutação
de operadores
*/
*
Tipo de mutações em código:
/*
Exclusão de declarações
Duplicação ou inserção de declarações
Negação de sub-expressões boleanas
Substituições
*/
Em resumo:
revelam o quão adequados estão os testes
unitários ou seus dados de teste
Em resumo [2]:
- Ajuda na criação de suítes efetivas
- mostra o quão confiável pode ser uma
suíte de testes
- valida se alguma implementação está
realmente bem testada
Qualidade de Código
/*
medir e garantir a qualidade do código
>> duplicidade de código
>> complexidade ciclomática
>> presença de testes de unidade
*?
Análise Estática de Código (AEC)
/*
reduzir erros de programação
bloco catch vazio
fluxo não encerrado
perda de referência
comparação de objetos comuns
*/
- Verificação de Regras de Estilo
- Style Checker
- Verificação de Erro
- Bug Checker
Métricas:
- Número de linhas de código (LOC, KLOC)
- Complexidade Ciclomática (CC)
- Falta de coesão em métodos (LCOM)
SonarQube
/* ferramenta eficiente para realizar o cálculo das métricas */
Principais categorias de cobertura:
/*
Arquitetura e Design
Comentários
Duplicação de Código
Padrão de Codificação
Testes
Complexidade Ciclomática
Bugs em Potencial
*/
/* resultado de um análise completo – apresentado em dashboard */
Especificações Vivas
Será possível [?]
- documentação formal para ser base ao
desenvolvedor
- documentação consistente com o código
e entregável
/*
BDD
Specification by Example
*/
- testes de BDD são compostos,
basicamente, por arquivos que
especificam as funcionalidades – features
- arquivos com as funcionalidades são
compostos por cenários, que
exemplificam uma ou mais regras de
negócio do sistema
Cada cenário segue o padrão:
1. Colocam o sistema em um determinado
estado;
2. Fazem alguma ação sobre o sistema
(provocação);
3. Examinam o novo estado.
/* Exemplo de um arquivo de funcionalidade com fluxo simples de login */
Frameworks pra BDD
/*
Jbehave
Rbehave >> Rspec
Gherkin
*/
Considerações Finais
- Ágil Testers vai além de automatizar
- Não precisa ser expert em programação
- Pedir ajuda sempre que precisar
- Aprender além do esperado
Thanks!

DevQA | Da zona de conforto ao comprometimento com a qualidade

  • 2.
    ABOUT ME ! KamillaQueiróz (MihQueiróz) • Cearense adotada pelo Rio Grande do Sul • Analista de Testes @NeoGrid • Tecnóloga em Análise e Desenvolvimento de Sistemas • Pós-Graduando Teste e Qualidade de Software • Mantedora do Blog MihQueiroz.com.br • En.tu.si.as.ta e hóspede do Mundo Contato: • Email: q.kamilla@gmail.com • Blog: mihqueiroz.com.br • Twitter: twitter.com/MihQueiroz • Facebook: facebook.com/kamilla.queiroz • LinkedIn: linkedin.com/kamilla.queiroz • SlideShare: slideshare.net/kamilla.queirz
  • 3.
    AGENDA - Qual futurono cenário Ágil - DevQA um futuro para Analistas de Testes [?] - Testar Testes Unitários [!][?] - Qualidade de Código - Especificações Vivas
  • 4.
    Qual futuro nocenário Ágil O que percebi: em abril de 2015 AgileTrends – após palestra Testador Ágil 3.0 de Daniel Amorim /* ninguém sabia ao certo qual era o papel do testador no contexto ágil */
  • 5.
    ‘todo mundo’ /* os principaisprofissionais que eu conhecia */ tinham em mente que ser ágil era APENAS automatizar testes
  • 6.
    os testes continuavamsendo deixados para “trás” /* salvem-se quem puder e testar o que der */
  • 7.
    ou seja cenário“ágil” para o desenvolvimento e waterfall / cascata para testes IN – JUS – TI - ÇA!
  • 8.
    Mas [1] aindase falava sobre: - QA DevOps - QA Técnico - Analista Automatizador E o que esses ‘cristões’ fazem de tão diferente que precisam ser / ter atividades distintas dos Analistas de Testes / Testadores [??]
  • 9.
    Mas [2] temose precisamos enxergar o Analista de Testes como: [!] PARTE INTEGRANTE E ATUANTE DE UMA EQUIPE DE DESENVOLVIMENTO
  • 10.
    [!] O CARA que disseminaa qualidade por todo os processo de desenvolvimento
  • 11.
    [!] O CARA que trabalhapara evitar inconformidades
  • 12.
    DevQA - Mudança deParadigma [?] - [tchau tchau] zona de conforto [!] [!] - reinventar atividades [comuns] - auxiliar sua equipe [por completo][!]
  • 13.
    /* Skills ampliadas (analítico& crítico) Lógica de programação Escrever scripts (mesmo simples) Noções de BD e Webservices Builds e Integração Contínua */
  • 14.
    - Skills ampliadas /* alémdo conhecimento do negócio conhecimento técnico */
  • 15.
    - Lógica deprogramação & - Escrever Scripts /* for if / else */
  • 16.
    - Banco deDados & Webservices /* validar dados validar conexões */
  • 17.
    - Builds eIntegração Contínua /* autonomia para gerar versões autonomia para execução de testes */
  • 18.
    Testar Testes deUnidade - Validar se: - Estão escritos corretamente - Estão sendo efetivos - A cobertura está gerando valor
  • 19.
    Mutation Testing /* altera-se umaparte do código para induzir falhas simples por meio do Bebuging */
  • 20.
    - Mutações possíveis: Intra– method Inter – method Intra – class Inter - class
  • 21.
    MuJava /* Ferramenta para Java Ajuda namutação de operadores */ *
  • 22.
    Tipo de mutaçõesem código: /* Exclusão de declarações Duplicação ou inserção de declarações Negação de sub-expressões boleanas Substituições */
  • 23.
    Em resumo: revelam oquão adequados estão os testes unitários ou seus dados de teste
  • 24.
    Em resumo [2]: -Ajuda na criação de suítes efetivas - mostra o quão confiável pode ser uma suíte de testes - valida se alguma implementação está realmente bem testada
  • 25.
    Qualidade de Código /* medire garantir a qualidade do código >> duplicidade de código >> complexidade ciclomática >> presença de testes de unidade *?
  • 26.
    Análise Estática deCódigo (AEC) /* reduzir erros de programação bloco catch vazio fluxo não encerrado perda de referência comparação de objetos comuns */
  • 27.
    - Verificação deRegras de Estilo - Style Checker - Verificação de Erro - Bug Checker
  • 28.
    Métricas: - Número delinhas de código (LOC, KLOC) - Complexidade Ciclomática (CC) - Falta de coesão em métodos (LCOM)
  • 29.
    SonarQube /* ferramenta eficientepara realizar o cálculo das métricas */
  • 30.
    Principais categorias decobertura: /* Arquitetura e Design Comentários Duplicação de Código Padrão de Codificação Testes Complexidade Ciclomática Bugs em Potencial */
  • 31.
    /* resultado deum análise completo – apresentado em dashboard */
  • 32.
    Especificações Vivas Será possível[?] - documentação formal para ser base ao desenvolvedor - documentação consistente com o código e entregável
  • 33.
  • 34.
    - testes deBDD são compostos, basicamente, por arquivos que especificam as funcionalidades – features - arquivos com as funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio do sistema
  • 35.
    Cada cenário segueo padrão: 1. Colocam o sistema em um determinado estado; 2. Fazem alguma ação sobre o sistema (provocação); 3. Examinam o novo estado.
  • 36.
    /* Exemplo deum arquivo de funcionalidade com fluxo simples de login */
  • 37.
  • 38.
    Considerações Finais - ÁgilTesters vai além de automatizar - Não precisa ser expert em programação - Pedir ajuda sempre que precisar - Aprender além do esperado
  • 39.