diff --git a/_includes/rodape.html b/_includes/rodape.html
index 2fedcb7..358d396 100644
--- a/_includes/rodape.html
+++ b/_includes/rodape.html
@@ -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>
@@ -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>
diff --git a/assets/images/atdd.png b/assets/images/atdd.png
new file mode 100644
index 0000000..a7a4e8c
Binary files /dev/null and b/assets/images/atdd.png differ
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-4-1.md b/collections/_ctfl_resumo/capitulo-4/indice-4-4-1.md
new file mode 100644
index 0000000..e82ca9b
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-4-1.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-4-2.md b/collections/_ctfl_resumo/capitulo-4/indice-4-4-2.md
new file mode 100644
index 0000000..7eccec3
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-4-2.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-4-3.md b/collections/_ctfl_resumo/capitulo-4/indice-4-4-3.md
new file mode 100644
index 0000000..72cf01c
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-4-3.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-4.md b/collections/_ctfl_resumo/capitulo-4/indice-4-4.md
new file mode 100644
index 0000000..181fbbc
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-4.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-5-1.md b/collections/_ctfl_resumo/capitulo-4/indice-4-5-1.md
new file mode 100644
index 0000000..07c7655
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-5-1.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-5-2.md b/collections/_ctfl_resumo/capitulo-4/indice-4-5-2.md
new file mode 100644
index 0000000..5d21e07
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-5-2.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-5-3.md b/collections/_ctfl_resumo/capitulo-4/indice-4-5-3.md
new file mode 100644
index 0000000..36e5510
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-5-3.md
@@ -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>
diff --git a/collections/_ctfl_resumo/capitulo-4/indice-4-5.md b/collections/_ctfl_resumo/capitulo-4/indice-4-5.md
new file mode 100644
index 0000000..bb41ba5
--- /dev/null
+++ b/collections/_ctfl_resumo/capitulo-4/indice-4-5.md
@@ -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>