Skip to content

Commit

Permalink
adicionando resumo dos indices 4.4, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.5.2…
Browse files Browse the repository at this point in the history
…, 4.5.3, 4.5
  • Loading branch information
feroline committed Sep 17, 2024
1 parent fc5d635 commit 320e417
Show file tree
Hide file tree
Showing 10 changed files with 191 additions and 1 deletion.
4 changes: 3 additions & 1 deletion _includes/rodape.html
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
<!-- TODO: diminuir o tamanho do rodapé fixo, deixando visivel apenas as redes -->

<nav class="navbar fixed-bottom bg-body-tertiary" id="rodape">
<div class="container justify-content-center">
<footer>
Expand All @@ -9,7 +11,7 @@
{% include {{ contato.svgPath }} %}
</a>
</li>

{% endfor %}
</ul>
<p class="text-center text-muted">© 2024 QA Bentevi por Ana Rocha. Todos os direitos reservados </p>
Expand Down
Binary file added assets/images/atdd.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
17 changes: 17 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-4-1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
---
capitulo: 4
indice: 4.4.1
order: 13
subcapitulo: true
title: Suposição de Erro
---

<p>Técnica usada para prever a ocorrência de erros, defeitos e falhas com base no conhecimento do testador, podem estar relacionados a entrada, saída, lógica, cálculo, interface e dados. A experiência inclui:</p>

<ul>
<li>Como o aplicativo funcionou no passado.</li>
<li>Os tipos de erros e seus defeitos que os desenvolvedores tendem a cometer.</li>
<li>Tipos de falhas que ocorrem em outros aplicativos semelhantes.</li>
</ul>

<p>O <b>Ataque de Falhas</b> é uma abordagem da Suposição de Erro no qual garante que o testador crie uma lista de possíveis erros, defeitos e falhas e então modele os testes para capturá-los.</p>
20 changes: 20 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-4-2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
capitulo: 4
indice: 4.4.2
order: 14
subcapitulo: true
title: Testes Exploratórios
---

<p>Tem o objetivo de aprendizagem sobre o objeto de teste. Os testes são modelados, executados e analisados simultaneamente para o aprendizado.</p>

<p>O teste é baseado em sessões, onde cada sessão tem :</p>

<ul>
<li>Um período de tempo definido</li>
<li>Uma carta de teste que contém os objetivos do teste</li>
<li>Uma reunião depois da sessão onde é discutido os resultados do teste</li>
<li>Os itens de cobertuiria são identificados durante a sessão de teste</li>
</ul>

<p>São muito úteis quando há pouca especificação ou quando ela é inadequada, ou quando há uma significativa pressão de tempo. Complementa técnicas mais formais, como a de particionamento de equivalência. É mais eficaz com um testador experiênte, com domínio e habilidades anlíticas, curiosidade e criatividade.</p>
15 changes: 15 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-4-3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
---
capitulo: 4
indice: 4.4.3
order: 15
subcapitulo: true
title: Testes Baseado em Lista de Verificação (Checklist)
---

<p> O testador modela, executa e implementa os testes baseado em uma lista de verificação, também chamado de Checklist. Essa lista pode ser baseada na experiência do testador, no conhecimento do que é importante para o usuário ou em como o software costuma falhar.</p>

<p>Geralmente é feita em forma de perguntas, deve verificar cada item separadamente e podem ser criadas para dar suporte a vários tipos de teste, incluindo funcionais e não funcionais, como por exemplo de teste não funcional as 10 heurísticas para teste de usabilidade de Nielsen. </p>

<p>Não deve conter itens que possam ser: Avaliados automaticamente, itens com critérios de entrada/saída ou itens muito gerais.</p>

<p>É necessário atualizar a lista constantemente, pois os mesmos erros podem não ser mais cometidos. Na ausencia de casos de teste detalhados é uma boa prática, aumentando a cobertura e tendo menos repetibilidade.</p>
15 changes: 15 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-4.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
---
capitulo: 4
indice: 4.4
order: 12
subcapitulo: false
title: Técnicas de Teste Baseadas na Experiência
---

<p>As técnicas mais usadas que serão discutidas aqui são:</p>

<ul>
<li><b>Suposição de Erro</b></li>
<li><b>Teste Exploratório</b></li>
<li><b>Teste baseado em lista de verificação</b></li>
</ul>
29 changes: 29 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-5-1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
capitulo: 4
indice: 4.5.1
order: 17
subcapitulo: true
title: Escrita colaborativa de histórias de Usuário
---

<p> <b>História de Usuário</b> é um recurso valioso para o usuário/comprador do software. Tem 3 aspectos críticos chamados de '3C', são eles:

<ul>
<li><b>Cartão:</b> meio que se descreve uma história de usuário</li>
<li><b>Conversação:</b> explicação de como o software será utilizado</li>
<li><b>Confirmação:</b> os critérios de aceite</li>
</ul>

</p>

<p>
O formato mais comum é:
<br>
<b>Como</b> [ator ou persona] <b>eu quero</b> [meta a ser cumprida] <b>para que eu possa</b> [valor de negócio resultante da função]
</p>

<p>
Pode ser usuado brainstorming e mapeamento mental para escrita colaborativa, o que permite a visão compartilhada do que deve ser entregue, levando em consideração: negócios, desenvolvimento e testes.
</p>

<p> Boas histórias de usuários devem ser: Independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis. Se um stakeholder não souber testar a história de usuário provavelmente ela deve ser revisada novamente.</p>
35 changes: 35 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-5-2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
---
capitulo: 4
indice: 4.5.2
order: 18
subcapitulo: true
title: Critérios de Aceite
---

<p>
Geralmente são resultados da escrita colaborativa. São condições que uma história de usuário deve atender para ser aceita pelos stakeholders e serem executadas pelos testes.
</p>

<p>São usadas para:

<ul>
<li>Definir o escopo da história de usuário</li>
<li>Chegar a um consenso entre os stakeholders</li>
<li>Descrever os cenários positivos e negativos</li>
<li>Servir como base para o teste de aceite da história de usuário</li>
<li>Permitir planejamento e estimativas precisas</li>
</ul>

</p>

<p>
Os formatos mais comuns de escrever critérios de aceite para histórias de usuário são:

<ul>
<li>Orientado a Cenário (Ex.: BDD) </li>
<li>Orientado por Regras (Ex.: lista de pontos de verificação)</li>
</ul>

Eles devem ser bem definidos e não ambíguos.

</p>
42 changes: 42 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-5-3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
capitulo: 4
indice: 4.5.3
order: 19
subcapitulo: true
title: Desenvolvimento Orientado por Teste de Aceite (ATDD)
---

<p>É uma abordagem que prioriza os testes.</p>

<p>Os casos de teste são criados antes da implementação da história de usuário. Podem ser executados de forma manual ou automatizada. </p>

<p>
As etapas são :
<ol>
<li>
ª etapa: A história de usuário (se definida) e seus critérios de aceite são analisados, discutidos e escritos pelos membros da equipe. Lacunas, ambiguidades e defeitos são corrigidos nesta etapa.
</li>
<li>
ª etapa: Criação dos casos de teste, no qual são baseados nos critérios de aceite e podem ser visto como exemplo de como o software funciona. Ajudando a equipe a implementar corretamente a história de usuário.
</li>
</ol>
</p>

<p>
Durante o projeto de teste, as técnicas de teste Caixa-preta, Caixa-branca e Baseada na Experiência podem ser utilizadas.
</p>

<p>
No passo a passo, os primeiros casos de teste são positivos, confirmando o comportamento correto. Em seguida, a equipe deve realizar os testes negativos. Depois a equipe deve cobrir as características de qualidade não funcional.
<div class="text-center">
<!-- TODO corrigir /feroline.qa-bentevi/ para usar relative_url -->
<img class="img-fluid" src="/feroline.qa-bentevi/assets/images/atdd.png">
</div>
</p>

<ul>
<li>A linguagem utilizada normalmente é natural, para compreesão dos stakeholders.</li>
<li>Abrange todas as características das histórias de usuários, não indo além delas, mas podendo expor seus problemas.</li>
<li>Dois casos de teste não devem descrever as mesmas características.</li>
<li>Na automação os desenvolvedores escrevem o código de suporte a medida que implementam o recurso, tornando os testes requisitos executáveis.</li>
</ul>
15 changes: 15 additions & 0 deletions collections/_ctfl_resumo/capitulo-4/indice-4-5.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
---
capitulo: 4
indice: 4.5
order: 16
subcapitulo: false
title: Abordagens de Teste Baseadas na Colaboração
---

<p>As técnicas de teste Caixa-preta, Caixa-branca e Baseadas na Experiência visam detectar defeitos, já a abordagem de teste baseada na colaboração visa e <b>evitar defeitos</b> por meio da colaboração e comunicação. Algumas delas são: </p>

<ul>
<li><b>Escrita colaborativa de histórias de usuário</b></li>
<li><b>Critérios de Aceite</b></li>
<li><b>Desenvolvimento Orientado opr Teste de Aceite</b></li>
</ul>

0 comments on commit 320e417

Please sign in to comment.