DevQA | Da zona de conforto ao comprometimento com a qualidade

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

3. 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

4. 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
*/

5. ‘todo mundo’
/*
os principais profissionais que eu
conhecia
*/
tinham em mente que ser ágil era APENAS
automatizar testes

6. os testes continuavam sendo 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] 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 [??]

9. Mas [2] temos e precisamos enxergar o
Analista de Testes como:
[!]
PARTE INTEGRANTE E
ATUANTE DE UMA EQUIPE DE
DESENVOLVIMENTO

10. [!]
O CARA
que dissemina a qualidade por
todo os processo de
desenvolvimento

11. [!]
O CARA
que trabalha para evitar
inconformidades

12. DevQA
- Mudança de Paradigma [?]
- [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ém do conhecimento do negócio
conhecimento técnico
*/

15. - Lógica de programação &
- Escrever Scripts
/*
for
if / else
*/

16. - Banco de Dados & Webservices
/*
validar dados
validar conexões
*/

17. - Builds e Integração Contínua
/*
autonomia para gerar versões
autonomia para execução de testes
*/

18. Testar Testes de Unidade
- Validar se:
- Estão escritos corretamente
- Estão sendo efetivos
- A cobertura está gerando valor

19. Mutation Testing
/*
altera-se uma parte 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 na mutação
de operadores
*/
*

22. 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
*/

23. Em resumo:
revelam o quã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
/*
medir e garantir a qualidade do código
>> duplicidade de código
>> complexidade ciclomática
>> presença de testes de unidade
*?

26. 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
*/

27. - Verificação de Regras de Estilo
- Style Checker
- Verificação de Erro
- Bug Checker

28. Métricas:
- Número de linhas de código (LOC, KLOC)
- Complexidade Ciclomática (CC)
- Falta de coesão em métodos (LCOM)

29. SonarQube
/* ferramenta eficiente para realizar o cálculo das métricas */

30. 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
*/

31. /* resultado de um 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. /*
BDD
Specification by Example
*/

34. - 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

35. 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.

36. /* Exemplo de um arquivo de funcionalidade com fluxo simples de login */

37. Frameworks pra BDD
/*
Jbehave
Rbehave >> Rspec
Gherkin
*/

38. 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

39. Thanks!