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 ÁgilO 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 DEDESENVOLVIMENTO

[!]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çãoEscrever scripts (mesmo simples)Noções de BD e WebservicesBuilds 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 vaziofluxo não encerradoperda de referênciacomparaçã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 DesignComentáriosDuplicação de CódigoPadrão de CodificaçãoTestesComplexidade CiclomáticaBugs em Potencial

*/

/* resultado de um análise completo – apresentado em dashboard */

Especificações VivasSerá 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

/*JbehaveRbehave >> 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!