1. manual
2. Material produzido por @priscila.caimi
3. Siglas utilizadas
3.1. Utilizada para prática colaborativa em extreme programming
3.1.1. STDD
3.1.1.1. Storytest driver development
3.1.1.2. A história deve gerar entendimento e alinhamento entre todos
3.1.1.3. Requisito, história de usuário, código e responsabilidade de todos do time
3.1.2. ATDD
3.1.2.1. Aceptance tests driven development
3.1.2.1.1. E a prática da escrita dos testes automatizados
3.1.2.2. Fusão entre TDD e BDD
3.2. Desenvolvimento aplicado a teste
3.2.1. TDD
3.2.1.1. Test drive developer
3.2.1.2. Realiza o desenvolvimento baseado no teste criado
3.2.1.3. Cria o teste unitário primeiro e depois desenvolve o software para passar no teste
3.2.2. BDD
3.2.2.1. Behaviour driven development
3.2.2.2. Desenvolvimento orientado ao comportamento
3.2.2.3. Testar de forma automatizada as regras de negócios
3.2.2.3.1. Unitário
3.2.2.3.2. Funcionais
3.2.2.4. Deve ser constantemente atualizadas
3.2.3. DDD
3.2.3.1. Domain driven design
3.2.3.2. Desenvolver a arquitetura do sistema
3.2.4. EDD
3.2.5. FDD
3.2.5.1. Feature driven development
3.2.5.2. Feature e desdobrada em
3.2.5.2.1. Funcionalidade
3.2.5.2.2. Detalhamento
3.2.5.2.3. Execução orientado a funcionalidade
4. Estratégia de Teste
4.1. Funcionais
4.1.1. testa requisitos funcionais do sistema
4.1.2. valida se a aplicação está funcionando conforme critério de aceite
4.1.3. "simular o fluxo do cliente"
4.1.4. formas de executar
4.1.4.1. automatizado
4.1.5. técnicas utilizadas
4.2. Não funcionais
4.2.1. técnicas utilizadas
4.2.1.1. testes de desempenho
4.2.1.2. carga
4.2.1.3. usabilidade
4.2.2. verifica
4.2.2.1. verificar a execução correta do sistema em relação a casos inválidos ou inesperados
4.2.2.2. elementos não relacionados a funcionalidade
4.2.2.3. ela pode "criticar" o produto, mostrando os pontos de melhoria
5. quadrante de teste ágil
5.1. Q1
5.1.1. unitário
5.1.2. componente
5.2. Q2
5.2.1. teste baseado na história de usuário
5.2.2. protótipo
5.2.3. simulações
5.3. Q3
5.3.1. testes de ..
5.3.1.1. usabilidade
5.3.1.2. alfa
5.3.1.3. aceitação
5.3.1.4. exploratórios
5.4. Q4
5.4.1. Performance e Carga
5.4.2. Seguraça
5.4.3. ilidade
6. Pirâmide de teste
6.1. TOP
6.1.1. UI
6.1.2. acessibilidade
6.1.3. usabilidade
6.1.4. performance
6.1.4.1. carga
6.1.4.2. pico
6.2. INTERMEDIARIO
6.2.1. integração
6.2.2. serviço
6.3. BASE
6.3.1. unitário
6.3.2. componente
7. compara com o resultado esperado
8. Técnicas de Teste
8.1. caixa branca
8.1.1. valida o comportamento interno do software
8.1.1.1. direto no código fonte
8.1.1.2. testes especificos
8.1.1.2.1. condição
8.1.1.2.2. fluxo de dados
8.1.1.2.3. testes de ciclo
8.1.1.2.4. teste de caminhos lógicos
8.2. caixa preta
8.2.1. não considera o comportamento interno do sistema
8.2.2. dados entram
8.2.2.1. teste é executado
8.2.2.1.1. resultado é obtido
8.2.3. pode ser testado
8.2.3.1. método
8.2.3.2. função interna
8.2.3.3. programa
8.2.3.4. componente
8.2.3.5. conjunto de programas e/ou componente
8.2.3.6. funcionalidade
8.3. caixa cinza
8.3.1. o testador entende da estrutura interna do sistema
8.3.1.1. depurar o aplicativo
8.3.1.2. entrando dados pelo front
8.3.1.2.1. validando os dados no back
8.3.1.3. podemos dizer que o teste E2E é um teste de caixa cinza
8.3.2. ele reflete o ponto de vista do usuário final
8.3.2.1. porém do ponto de vista da engenharia
8.3.2.1.1. validando as entradas/saidas do sistema
8.3.3. escrita dos testes
8.3.3.1. histórias de usuário
8.3.3.2. diagrama de arquitetura
8.3.3.3. especificações funcionais