diff --git a/Faculdade/Qualidade-e-Testes-de-Software/aula1.md b/Faculdade/Qualidade-e-Testes-de-Software/aula01.md
similarity index 100%
rename from Faculdade/Qualidade-e-Testes-de-Software/aula1.md
rename to Faculdade/Qualidade-e-Testes-de-Software/aula01.md
diff --git a/Faculdade/Qualidade-e-Testes-de-Software/aula2.md b/Faculdade/Qualidade-e-Testes-de-Software/aula02.md
similarity index 100%
rename from Faculdade/Qualidade-e-Testes-de-Software/aula2.md
rename to Faculdade/Qualidade-e-Testes-de-Software/aula02.md
diff --git a/Faculdade/Qualidade-e-Testes-de-Software/aula03.md b/Faculdade/Qualidade-e-Testes-de-Software/aula03.md
new file mode 100644
index 0000000..d04cd83
--- /dev/null
+++ b/Faculdade/Qualidade-e-Testes-de-Software/aula03.md
@@ -0,0 +1,175 @@
+# Aula 3 - Qualidade de teste de software
+
+
+## Histórico
+
+No início do desenvolvimento dos softwares, quando só existia a função de programador, que era exercida por poucos, não havia atividades de testes no processo do seu desenvolvimento. Na verdade, antes dos anos 1970, não havia nem processo definido de desenvolvimento de software.
+
+O que ocorria nessa época? 
+
+- Tendo em vista que os erros ocorriam, após o software estar pronto, o próprio programador percorria o código para solucionar possíveis erros;
+- Os testes eram feitos pelo próprio usuário.
+
+Já no final dos 1960 e início dos 1970, surgiu a "programação estruturada", que recomendava, basicamente, evitar o uso de **goto**, ou seja, desvio incondicional. Há um consenso entre os programadores que o desvio incondicional é um mau estilo de programação, que gera códigos com baixa qualidade. 
+
+Nessa época, surgiram, então, os primeiros conceitos de engenharia de software, adotados, principalmente, como modelo nos cursos de Exatas nas universidades em todo o mundo. Assim, os primeiros procedimentos de testes passaram a ser usados, porém de forma bastante tímida.
+
+Em 1979, Genford J. Myers, autor do livro The Art of Software Testing, apresentou um trabalho pioneiro e profundo sobre um processo de teste de software. Foi criador de termos muito usados como “caixa branca”, “caixa preta" e "caso de teste".
+
+Myers também ficou conhecido pela Regra de 10 de Myers, que mostra que **“quanto mais tarde os defeitos forem encontrados, tanto mais caro será corrigi-los”**.
+
+Entenda graficamente a regra de 10 de Myers:
+![Regra de 10 de Myers](../../media/qualidade-e-teste-de-software/aula03/img/img001.png)
+
+
+## Qualidade de software
+
+Nos anos 1980, surgiu o conceito de qualidade de software, processo fortemente relacionado à conformidade com requisitos e à satisfação do cliente, que envolve a delimitação do escopo de um sistema e a volatilidade dos requisitos, lugar-comum no desenvolvimento de software.
+
+Alguns fatores afetam o desenvolvimento do software e influenciam na avaliação do usuário, como:
+
+1. Tamanho e complexidade do software
+2. Número de pessoas envolvidas no projeto
+3. Métodos, técnicas e ferramentas utilizadas
+4. Relação custo x benefício do sistema
+5. Custos referentes à correção e remoção de erros
+
+Os testes aconteciam desde a fase inicial do projeto de software até a fase de encerramento e entrega do produto final. 
+
+Alguns padrões foram criados para a medição e avaliação do processo de desenvolvimento, e o modelo que ganhou maior credibilidade e importância para as empresas desenvolvedoras foi o Capability Maturity Model (CMM)1, apresentado pelo SEI.
+
+Capability Maturity Model (ou Modelo de Maturidade em Capacitação) para Software é um conjunto de processos desenvolvido pela SEI - Software Engineering Institute (www.sei.cmu.edu) em 1986 para melhorar o desenvolvimento de aplicações em organizações que trabalham com tecnologias de software. O processo é divido em cinco níveis de desenvolvimento: inicial, repetível, definido, gerenciado com métricas e otimizado.
+
+Nos anos 1990, surgiram algumas ferramentas de teste que proporcionaram alta produtividade e qualidade no processo.
+
+Assim, determinados tipos de testes, que antes não eram possíveis de serem executados, tornaram-se de fato uma realidade, proporcionando alta produtividade e qualidade no processo de teste e, consequentemente, na qualidade do software.
+
+
+## Cenário atual do desenvolvimento de software
+
+A era digital exigiu que os softwares fossem se adaptando à realidade. Hoje eles fazem parte do nosso cotidiano, estando presentes, por exemplo, nos aplicativos das mais diversas áreas das atividades humanas, como alimentação, transações bancárias, compra e aquisição de produtos, contratação de serviços etc.
+
+A Globalização é o processo que proporciona a integração entre diversas sociedades, países e comunidades em todo o mundo, aproximando pessoas, empresas e seus departamentos, clientes, fornecedores etc., seja no âmbito político, cultural, financeiro ou comercial.
+
+O destaque maior da Globalização está na integração de mercado existente entre os países.
+
+Assim, a exigência pela qualidade, funcionalidade, portabilidade e tantas outras características fizeram com que esses aplicativos atingissem um grau elevado de complexidade e integridade.
+
+Por outro lado, provavelmente você já teve experiência com algum software ou aplicativo que não funcionasse a contento.
+
+Softwares que apresentam bugs podem acarretar diversos problemas, como supressão de negócio, prejuízos financeiros, além de perda de tempo e, principalmente, queda na reputação das empresas.
+
+Assim sendo, os processos de gerenciamento de testes ganham cada vez mais importância no contexto do desenvolvimento do software, uma vez que vulnerabilidades ou falhas podem gerar riscos e causar perdas, em muitos casos, irrecuperáveis.
+
+Apesar disso, algumas empresas ainda resistem em investir na área de segurança e testes, por considerar seu custo alto e desnecessário.
+
+Essas empresas precisaram quebrar paradigmas e considerar que a implantação de um processo que garanta a qualidade do software é estratégico e vital para a continuidade dos negócios, em um mercado cada vez mais exigente e competitivo.
+
+Principais demandas de software atuais e a evolução do processo de qualidade e de teste, segundo Bartié (2002):
+
+
+| Características | 1960 | 1980 | 2000 |
+| --- | --- | --- | --- |
+| Tamanho do software | Pequeno | Médio | Muito Grande |
+| Complexidade do Software | Baixa | Média | Alta |
+| Tamanho da Equipe de Desenvolvimento | Pequeno | Médio | Grande |
+| Padrões de Metodologia de Desenvolvimento | Interno | Moderado | Sofisticado |
+| Padrões e Metodologias de Qualidade e Testes | Interno | Emergente | Sofisticado |
+| Organização de Qualidade e Testes | Bem poucas | Algumas | Muitas |
+| Reconhecimento da Importância da Qualidade | Pequeno | Algum | Significante |
+| Tamanho da Equipe de Qualidade e Testes | Pequeno | Pequeno | Grande |
+
+
+## Qual a realidade dos softwares atuais?
+
+As empresas desenvolvedoras estão percebendo que os processos de desenvolvimento são estratégicos e agregam valor aos seus negócios, valorizando seus produtos e serviços.
+
+Na realidade, a indústria de software não está preparada para atender às exigências do mercado em constante evolução porque não investe em seus processos internos.
+
+Um estudo feito recentemente nos EUA mostra o quanto a indústria de softwares está deficitária:
+
+![Indústria de softwares deficitária](../../media/qualidade-e-teste-de-software/aula03/img/img002.png)
+
+
+## A necessidade de testes no desenvolvimento de softwares
+
+A necessidade e a importância dos testes vão depender do tipo de uso que o software terá. São mais críticos aqueles que podem causar danos à vida humana ou levar a grandes perdas financeiras.
+
+Como vimos com Myers, quanto mais precoce a detecção de falhas ocorre, menores os gastos do projeto com reparos e replanejamento.
+
+**Por esse motivo, a utilização de ferramentas de suporte a testes tem se tornado uma regra no desenvolvimento de softwares.**
+
+A qualidade de um produto ou artefato reúne um conjunto de características e propriedades que devem ser satisfeitas segundo as exigências do usuário, de modo a atender a uma medida de conformidade com as especificações, como defeito zero nos componentes e no produto final, obtendo benefício com o alcance da qualidade.
+
+
+### Definição sobre qualidade de software
+
+Segundo Pressman (2016), em seu livro Engenharia de Software: "Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software desenvolvido por profissionais." Pressman, 2016.
+
+Esse processo visa garantir a uniformidade dos processos e produtos, eliminando defeitos e melhorando o desempenho de suas funcionalidades.
+
+Para desenvolver softwares de qualidade, é necessário investir em processos de gestão de qualidade, atuando em todas as fases do ciclo de vida.
+
+Alguns fatores internos e externos podem afetar a qualidade do software. Vejamos alguns exemplos:
+
+- **Fatores externos**: São percebidos tanto pelas pessoas que desenvolvem softwares quanto pelos usuários.
+- **Fatores internos**: São percebidos apenas pelas pessoas que desenvolvem softwares.
+
+São exemplos de Fatores externos: confiabilidade, eficiência e facilidade de uso.
+
+São exemplos de Fatores internos: modularidade e legibilidade.
+
+É importante notar que a garantia de qualidade de software (Software Quality Assurance) não é algo com que começamos a nos preocupar depois que o código foi gerado, e sim “**ao longo de todo o processo de engenharia de software**”.
+
+Todos os métodos, ferramentas e procedimentos definidos pela Engenharia de Software buscam um único objetivo: produzir softwares de alta qualidade.
+
+Segundo Philip Crosby (Quality is Free): “O problema do gerenciamento da qualidade não é o que as pessoas não sabem. **O problema é o que as pessoas acham que sabem**”.
+
+
+## Garantia de qualidade
+
+
+Os testes também fazem parte dos procedimentos seguidos para garantir a qualidade do processo de desenvolvimento de softwares, assegurada por certificações concedidas por organizações que avaliam o processo, considerando modelos de qualidade, como o CMMI (Capability Maturity Model Integration) e a ISO-12207.
+
+## Garantia de qualidade de software (SQA)
+
+Um grande desafio para qualquer programa de qualidade, considerado crítico, é possibilitar que qualquer pessoa faça revisões no trabalho de profissionais experientes.
+
+Os gerentes sempre querem os melhores profissionais para projetar o produto, mas geralmente o SQA não pode tê-los. É necessário concentrar esforços em métodos de SQA que permitam um desenvolvimento que possa ser revisado também por pessoas que não são desenvolvedores. Nesse caso, qual o papel do SQA?
+
+Monitorar os métodos e os padrões que os engenheiros de software usam e verificar se eles estão usando apropriadamente seus conhecimentos.
+
+**É importante compreender que as pessoas podem ser experientes em SQA sem, no entanto, serem experientes em projetos de software.**
+
+Software com qualidade => Investimentos em qualidade em todas as frases do processo de desenvolvimento.
+
+
+![Gráfico de pizza](../../media/qualidade-e-teste-de-software/aula03/img/img003.png)
+
+É impossível obter um software com qualidade com processos de desenvolvimento ineficientes.
+
+Nos processos de gestão de qualidade, o software deverá atender a todas as exigências do cliente/ usuário.
+
+Softwares mal testados causam prejuízos às empresas, como retrabalho, aumento de custo do projeto e informações inconsistentes que podem acarretar decisões equivocadas, além da insatisfação dos usuários.
+
+Temos a aplicação de qualidade em duas dimensões:
+
+- Qualidade do processo
+- Qualidade do produto
+
+
+## Qualidade do processo
+
+A preocupação com a qualidade deve estar presente em todas as fases do ciclo de desenvolvimento, inclusive no início e na fase de análise de requisitos do sistema.
+
+Quanto mais cedo os problemas forem detectados e corrigidos, mais rápido será o desenvolvimento e com menor custo.
+
+**Como medir?**
+
+Métricas de software são usadas para ajudar os desenvolvedores a criar softwares com qualidade reconhecida.
+
+Alguns garantem que o software é incomensurável, porém desconhecem que existem técnicas que colocam as métricas e medições como práticas fundamentais para a determinação do grau de maturidade dos processos de desenvolvimento, conforme definido nas plataformas CMMI e MPS-BR (melhoria do processo de software brasileiro).
+
+O software pode ser medido aplicando-se testes na documentação gerada em cada fase do ciclo de vida. São chamados testes de verificação.
+
+Além disso, existem outras técnicas de medição, como a **Análise de Pontos de Função - APF**, usada para a medição de projetos de software, seguindo alguns parâmetros de medida de tamanho, em **pontos de função - PF**, considerando a funcionalidade implementada, sob o ponto de vista do usuário.
diff --git a/Faculdade/Qualidade-e-Testes-de-Software/aula04.md b/Faculdade/Qualidade-e-Testes-de-Software/aula04.md
new file mode 100644
index 0000000..ff4a82b
--- /dev/null
+++ b/Faculdade/Qualidade-e-Testes-de-Software/aula04.md
@@ -0,0 +1,284 @@
+# Aula 4 - Principais Conceitos do Processo de Teste de Software
+
+## O que é testar?
+
+O teste de software visa garantir a qualidade, minimizando as incertezas e sistematizando os critérios de aceitação. Por meio dele, pode-se avaliar se o software está fazendo o que deveria fazer, de acordo com os seus requisitos, e se não está fazendo o que não deveria fazer.
+
+Ele ajuda a validar se:
+- As expectativas de todas as pessoas envolvidas estão sendo atendidas (e se estão alinhadas);
+- O software apresenta um bom funcionamento (parte disso está relacionada às expectativas implícitas – aquilo que é inerente ao produto).
+
+Algumas definições:
+- "Teste é uma parte inevitável de qualquer esforço necessário para desenvolver um sistema de software. " Howden, 1987.
+- "O teste de software é um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente. " PRESSMAN, 1985.
+- "Qualquer atividade que, a partir da avaliação de um atributo ou capacidade de um programa ou sistema, seja possível determinar se alcança os resultados desejados. " Hetzel, 1988.
+- "Processo de executar um programa ou sistema com a intenção de encontrar defeitos. "  Myers, 1979.
+
+O teste deve ser utilizado para confirmar a qualidade oriunda de aplicação de um processo de Engenharia de Software.  
+
+ 
+
+## Estratégia de teste
+
+Por que precisamos de uma estratégia de teste de software? O que ela deve incorporar? Essas perguntas são facilmente respondidas assim:
+
+A Engenharia de Software nos auxilia em muitas situações. Uma delas é a atividade de teste, que é um passo do processo de que visa encontrar ou corrigir erros durante toda a construção do software.
+
+Devemos incorporar dois tipos de testes:
+
+1. Teste de baixo nível: Utilizado para verificar um pequeno fragmento de código-fonte. Nesse caso, saberemos se ele foi implementado corretamente.
+2. Teste de alto nível: Tem a característica de validar as principais funções do sistema com base nos requisitos definidos pelo cliente.
+
+Os testes podem ser usados para descobrir a presença de erros nos softwares, mas infelizmente não mostram a sua ausência.
+
+Assim, conseguimos chegar à conclusão que “o teste de software é o processo de executar o software de uma maneira controlada, com o objetivo de descobrir diferenças entre o comportamento previsto e o comportamento observado”.
+
+
+## Processo de teste de software
+
+Não podemos ter um teste de software sem uma metodologia que seja favorável a esse processo de desenvolvimento, utilizando pessoal técnico qualificado, ambiente e, quando possível, todas as ferramentas adequadas.
+
+O documento básico para organizar a atividade de testar, aplicada no contexto da empresa, tem que ser uma metodologia de teste.
+
+Tanto o processo de desenvolvimento de software quanto o teste de software tem um ciclo de vida. Vejamos a seguir um exemplo de ciclo de vida para teste de software e a especificação de cada um deles.
+
+![Ciclo de vida para teste de software](../../media/qualidade-e-teste-de-software/aula04/img/img001.png)
+
+**Fases iniciais**:
+
+- **Planejamento**: é a parte inicial. Sem planejamento, não se deve realizar o teste. Nesta fase, é feita a elaboração e revisão da estratégia de teste e do plano de teste;
+
+- **Preparação**: paralelamente ao planejamento, precisamos fazer a preparação do ambiente de teste. Para tanto, precisamos incluir equipamentos, rede, pessoal, software e ferramentas.
+
+**Fases internas do ciclo**:
+
+Procedimentos iniciais: é nesta fase que efetivamente se faz a elaboração do documento. Nela, estabelece-se um acordo entre as partes envolvidas no projeto de teste (as partes envolvidas são usuários e técnicos). Esse acordo deve conter:
+
+- Objetivo do projeto de teste;
+- Pessoal a ser envolvido;
+- As responsabilidades de cada um;
+- O plano preliminar de trabalho;
+- A avaliação dos riscos;
+- Os níveis de serviços acordados.
+- **Especificação**: nessa fase, realizamos a elaboração e revisão dos seguintes itens: casos de teste, scripts (para o caso de ferramentas de automação de testes), roteiros de teste e execução dos testes de verificação da documentação do sistema (testes estáticos), (que veremos na próxima aula).
+- **Execução**: aqui executamos os testes planejados conforme os casos de teste; scripts; roteiros de teste com os correspondentes registros dos resultados obtidos.
+- **Entrega**: chegamos à última fase do processo. É aqui que fazemos a entrega do sistema para o ambiente de produção.
+
+
+## Como se da a interação entre os ciclos de vida?
+No nosso exemplo, seria assim:
+
+![Gerência de requisitos](../../media/qualidade-e-teste-de-software/aula04/img/img002.png)
+
+1. Teste das unidades individuais de programa
+2. Testes destinados a facilitar a integração de unidades
+3. Testes que usam o sistema concluído
+
+Algumas estratégias de teste:
+
+- **Teste de verificação:** Deve garantir a qualidade de todas as etapas do desenvolvimento de sistemas. Nesta etapa, são realizadas inspeções (auditorias com foco nas atividades) e revisões (com foco nas documentações) sobre os produtos gerados. 
+
+- **Testes unitários:** Cada programa ou componente é testado isoladamente para testar sua resposta aos requisitos definidos. Esses testes são realizados no estágio mais baixo da escala de testes e são aplicados nas menores componentes de códigos criados.
+
+Assim, é possível garantir que estes atendam às especificações, tanto de garantia quanto de funcionalidade.
+
+Por terem que verificar o funcionamento de um pedaço do sistema ou software isoladamente, normalmente são feitos pelos desenvolvedores.
+
+- **Testes de integração:** Os programas e componentes são integrados pouco a pouco para testar suas interfaces. São executados em uma combinação de componentes para verificar se eles funcionam corretamente juntos, conforme foram especificados, e também normalmente podem ser feitos pelos desenvolvedores.
+- **Testes de sistema:** Nesse momento, todos os programas e componentes estão totalmente integrados, formando um sistema. Esses testes visam à execução do sistema como um todo ou um subsistema (parte de um sistema), dentro de um ambiente operacional controlado, o mais próximo possível do ambiente de produção, para validar a exatidão e perfeição na execução de suas funções. Nesta fase, o teste deve simular a operação normal do sistema, pois serão testadas todas as suas funções da forma mais próxima possível do que irá ocorrer no ambiente de produção. Esses testes são de responsabilidade e feitos pela equipe de teste de software.
+- **Teste de aceitação:** O ambiente é o mesmo ou muito semelhante ao utilizado nos testes de sistema. São os testes finais de execução do sistema, realizados pelos usuários. Nesses testes é verificado se a solução atende aos objetivos do negócio e aos seus requisitos definidos inicialmente, no que diz respeito à funcionalidade e dentro da característica de usabilidade, preocupando-se também com a interação humano/ computador, antes da sua utilização no ambiente de produção.
+
+Quando a organização trata os testes como um processo bem estruturado e muitas vezes paralelo e integrado ao processo de desenvolvimento, os custos de manutenção com certeza são reduzidos.
+
+Quais os benefícios que cada um desses testes pode trazer?
+
+| Testes unitários | Podem remover entre 30% e 50% dos defeitos dos programas. |
+| --- | --- |
+| Testes de sistemas | Podem remover entre 30% e 50% dos defeitos remanescentes, mas mesmo assim, os sistemas podem ir para a produção ainda com aproximadamente 49% de defeitos.| 
+| Revisões de códigos | Podem reduzir entre 20% e 30% desses defeitos. |
+
+
+## Princípios de teste de software
+
+Pensando no teste como parte fundamental do **ciclo de vida de um software**, vamos mostrar os sete princípios fundamentais que envolvem o processo de teste que devem servir como um guia geral, tanto para testadores quanto para desenvolvedores.
+
+**Princípios de teste de software:**
+
+
+### 1º Princípio: teste demonstra a presença de defeitos
+
+Os testes conseguem identificar a existência de falhas, mas não podem garantir a ausência delas.
+
+Mesmo se nenhum erro for identificado em uma bateria de testes, não é possível afirmar que o software está livre de falhas.
+
+
+### 2º Princípio: teste exaustivo é impossível
+
+Deve-se calcular o esforço dos testes baseando-se nos riscos e prioridades.
+
+ 
+### 3º Princípio: teste antecipado
+
+Ao desenvolver um software, as atividades de teste devem começar o mais cedo possível no ciclo de vida do desenvolvimento do software. Assim diminuímos o custo das correções e possibilitamos que erros de design, requisitos e arquitetura sejam encontrados no momento ideal.
+
+Logo que os requisitos ou modelagem do sistema estiverem prontos, é possível começar o trabalho de modelagem do plano de testes.
+
+Quanto antes uma falha for identificada no ciclo de vida de um sistema, mais barata e mais simples será a correção.
+
+
+### 4º Princípio: agrupamento de defeitos
+
+A maioria das falhas encontradas durante a execução dos testes está concentrada em um número pequeno de módulos. Sempre existe uma área do software que é responsável pelo maior número de erros.
+
+
+### 5º Princípio: paradoxo do pesticida
+
+Um conjunto de testes, se executado várias vezes, pode não mais detectar novas falhas. Para contornar esse problema, os casos de teste devem ser frequentemente revisados e atualizados.
+
+Eles devem ser reformulados para abordar novas áreas do sistema e assim aumentar a chance de detectar novas falhas.
+
+Os testes precisam ser revisitados com frequência.
+
+
+### 6º Princípio: teste é dependente do contexto
+
+Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
+
+Por exemplo: um sistema bancário deve ser testado de maneira diferente de uma rede social. Há questões de segurança que devem ser mais precisamente abordadas no primeiro caso.
+
+Da mesma forma, testes web são elaborados com foco diferente dos testes de aplicações desktop.
+
+
+### 7º Princípio: a ilusão da ausência de defeitos
+
+Identificar e corrigir os problemas de um software não garante que ele está pronto.
+
+Questões a serem respondidas:
+
+- Os testes foram elaborados para identificar todas as possíveis falhas?
+- O sistema atende às necessidades e expectativas dos usuários?
+
+Ou seja, existem outros fatores que devem ser considerados para garantir a qualidade do sistema. 
+
+ 
+
+Não adianta o sistema ser correto funcionalmente, mas não atender à real necessidade do usuário.
+
+
+**Todos os princípios são importantes, porém entre os princípios listados, podemos citar que os números 3 e 7 representam os principais aspectos da atividade de teste.**
+
+**A busca por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que o sistema entregue atenda as reais necessidades do cliente, agregando valor ao seu negócio, é constante.**
+
+
+### Características das estratégias de teste
+
+- Para executar um teste eficaz, devem-se proceder revisões técnicas eficazes. Isto é necessário porque assim muitos erros são eliminados antes do começo do teste;
+- Para executar um teste eficaz, devem-se proceder revisões técnicas eficazes. Isto é necessário porque assim muitos erros são eliminados antes do começo do teste;
+- É importante que se usem diferentes técnicas de teste para diferentes abordagens e em diferentes momentos;
+- O teste deve ser feito pelo desenvolvedor e por um grupo independente de teste (se for um grande projeto);
+- Saiba que tanto o teste quanto a depuração são atividades diferentes, mas a depuração só acontece em consequência da existência de um teste.
+
+Com a atividade de teste, conseguimos executar um programa com a intenção principal de descobrir um erro.
+
+Para que um caso de teste seja considerado bom ou ótimo, ou seja, bem-sucedido, ele deve ter uma grande probabilidade de revelar um erro ainda não descoberto.
+
+
+### Diretrizes que devem ser levadas em conta para o teste
+
+- Quando o teste deve ser interrompido? - Deve ser determinado no planejamento;
+- Atribuir a responsabilidade do teste a um testador? - Deve ser atribuído também no planejamento;
+- Quais os resultados esperados para cada caso de teste? - Devem ser descritos antecipadamente;
+- Quais os resultados esperados para cada caso de teste? - Devem ser descritos antecipadamente;
+- Qual o resultado de cada teste por completo? - Cada um deles deve ser inspecionado depois de testado;
+- Quais programadores devem ser alocados para o teste? - Sempre os mais criativos.
+
+## A importância dos testes
+
+O processo de desenvolvimento de sistemas (PDS) requer uma série de atividades em que as oportunidades de inserção de falhas são muito grandes.
+
+Se os objetivos foram especificados erradamente, os erros podem começar a aparecer logo no início do processo, podendo também aparecer erros em fases de projeto e desenvolvimento posteriores.
+
+Como as informações para o projeto são determinadas pelo usuário/cliente, e o desenvolvimento é feito por técnicos especializados (programadores, analistas, gerentes etc.), muitas vezes pode haver falhas na comunicação.
+
+Nesse momento, é importante que o desenvolvimento seja acompanhado de **garantia de qualidade**, em função de não haver essa habilidade de realizar e de se comunicar com perfeição.
+
+Vemos então que a atividade de teste de software passa a ser um **elemento crítico** da garantia de qualidade. Esta passa a ser a última revisão de especificação, projeto e codificação.
+
+![Custo de preparo](../../media/qualidade-e-teste-de-software/aula04/img/img003.png)
+
+**Exemplo – Projetos de controle de voo:**
+
+Como vimos, é possível que os gastos fiquem entre 30% e 40% do esforço total do projeto no teste de software.
+
+Considere, por exemplo, os projetos de controle de voo, monitoramento de reatores nucleares etc.
+
+Esses projetos são considerados críticos para testes, pois sua falha pode resultar em significativos prejuízos econômicos, humanos ou ambientais, e por isso podem custar de três a cinco vezes mais do que todos os outros passos de engenharia de software combinados.
+
+
+![Índice de falhas](../../media/qualidade-e-teste-de-software/aula04/img/img004.png)
+
+Devem-se utilizar as principais estratégias de teste de software, de forma a **promover uma abordagem de teste personalizada** e de diferentes níveis, visando atingir todas as fases do ciclo de desenvolvimento do software.
+
+O uso de uma equipe independente no processo de teste de software cria um ambiente de teste e torna a aplicação de teste unitário pelo desenvolvedor.
+
+A aplicação de estratégias que integrem técnicas de projeto de casos de teste, numa série bem definida de passos, produz um mapa que descreve os passos a serem dados como parte da atividade de teste.
+
+Essa estratégia deve incorporar o planejamento de teste, o projeto de casos de testes, a execução e a resultante coleta e avaliação.
+
+Deve-se também responder às seguintes perguntas:
+- Como conduzir os testes de software?
+- Devemos estabelecer um plano formal para os testes?
+- Devemos testar o programa como um todo ou executar testes somente em uma parte dele?
+- Devemos refazer os testes quando acrescentamos novos componentes ao sistema?
+- Quando devemos envolver o cliente?
+
+
+### Quando terminar os testes?
+
+Em geral, os testes devem ser terminados quando a maioria das necessidades é atendida, permanecendo poucos erros importantes. Pode-se alguma vez ter certeza de que não existem mais falhas?
+
+![Possibilidade de existirem falhas](../../media/qualidade-e-teste-de-software/aula04/img/img005.png)
+
+
+Quando o teste é terminado, como saber se ele foi suficiente? **Não há uma resposta única.**
+
+Algumas respostas pragmáticas:
+- Você jamais terá completado a atividade de teste;
+- A carga simplesmente transfere-se do projetista para o cliente;
+- O teste para quando não há mais erros “visíveis”;
+
+O teste acaba quando o tempo acaba ou o dinheiro acaba:
+- Por restrição de tempo (nesse caso, deve-se negociar esse tempo);
+- Por restrição financeira (nesse caso, deve-se evitar).
+
+**A atividade de teste jamais termina. Ela passa do projetista para o usuário.**
+
+Então, quando terminar o teste? Basta pensar que:
+- O objetivo do teste é encontrar erros, e se eles não forem detectados, o teste não pode afirmar sua ausência;
+- Testar tudo é impossível;
+- As técnicas de teste são complementares, devendo ser aplicadas em conjunto.
+
+**Para testar com eficiência, é preciso conhecer bem o software.**
+
+
+## Papéis e responsabilidades de teste de software
+
+**Desenvolvedor**: É sempre responsável por testar unidades individuais (componentes). Em muitos casos, também conduz testes de integração, um passo que leva à construção (e teste) da arquitetura completa do software.
+
+**Grupo independente de teste (independent group test – ITG)**: Normalmente, para que o processo de teste transcorra de forma íntegra, é comum a utilização de um **grupo independente de teste**, já que as pessoas que criaram o software não devem ser as mesmas que irão realizar os testes. Seria um conflito de interesses, pois foram elas que o “criaram”. Eles se envolvem no projeto após a arquitetura do software estar completada.
+
+O engenheiro de software e o ITG trabalham juntos para garantir a execução de testes rigorosos. Existem testes que somente serão conduzidos pelos desenvolvedores, como o teste de unidade, que iremos estudar mais adiante.
+
+O desenvolvedor deve estar disponível para corrigir eventuais erros descobertos.
+
+**"O primeiro erro que o pessoal comete é pensar que a equipe de teste é responsável pela garantia de qualidade. " Bryan Marich.**
+
+**Existem várias responsabilidades e papéis dentro da equipe:**
+
+| Gerente de teste | Gerente de vários projetos de teste ou responsável pela área de teste da empresa. |
+| --- | --- |
+| Líder do projeto de testes | Responsável pela liderança de um projeto de teste, geralmente relacionado a um sistema em desenvolvimento, seja um projeto novo ou manutenção.|
+| Arquiteto | Responsável pela montagem da infraestrutura de teste, monta o ambiente de teste, escolhe as ferramentas e capacita a equipe para executar seu trabalho nesse ambiente.|
+| Analista do teste | Responsável pela modelagem e elaboração dos casos de teste e pelos scripts. Em alguns casos, estes podem ser elaborados pelos testadores. |
+| Testador | Responsável pela execução dos casos de teste e scripts. |
+
diff --git a/media/qualidade-e-teste-de-software/image-001.png b/media/qualidade-e-teste-de-software/aula01/img/img001.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/image-001.png
rename to media/qualidade-e-teste-de-software/aula01/img/img001.png
diff --git a/media/qualidade-e-teste-de-software/imagem-002.png b/media/qualidade-e-teste-de-software/aula01/img/img002.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/imagem-002.png
rename to media/qualidade-e-teste-de-software/aula01/img/img002.png
diff --git a/media/qualidade-e-teste-de-software/imagem-003.png b/media/qualidade-e-teste-de-software/aula01/img/img003.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/imagem-003.png
rename to media/qualidade-e-teste-de-software/aula01/img/img003.png
diff --git a/media/qualidade-e-teste-de-software/aula-004.png b/media/qualidade-e-teste-de-software/aula02/img/img001.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-004.png
rename to media/qualidade-e-teste-de-software/aula02/img/img001.png
diff --git a/media/qualidade-e-teste-de-software/aula-005.png b/media/qualidade-e-teste-de-software/aula02/img/img002.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-005.png
rename to media/qualidade-e-teste-de-software/aula02/img/img002.png
diff --git a/media/qualidade-e-teste-de-software/aula-006.png b/media/qualidade-e-teste-de-software/aula02/img/img003.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-006.png
rename to media/qualidade-e-teste-de-software/aula02/img/img003.png
diff --git a/media/qualidade-e-teste-de-software/aula-007.png b/media/qualidade-e-teste-de-software/aula02/img/img004.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-007.png
rename to media/qualidade-e-teste-de-software/aula02/img/img004.png
diff --git a/media/qualidade-e-teste-de-software/aula-008.png b/media/qualidade-e-teste-de-software/aula02/img/img005.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-008.png
rename to media/qualidade-e-teste-de-software/aula02/img/img005.png
diff --git a/media/qualidade-e-teste-de-software/aula-009.jpeg b/media/qualidade-e-teste-de-software/aula02/img/img006.jpeg
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-009.jpeg
rename to media/qualidade-e-teste-de-software/aula02/img/img006.jpeg
diff --git a/media/qualidade-e-teste-de-software/aula-010.png b/media/qualidade-e-teste-de-software/aula02/img/img007.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-010.png
rename to media/qualidade-e-teste-de-software/aula02/img/img007.png
diff --git a/media/qualidade-e-teste-de-software/aula-011.png b/media/qualidade-e-teste-de-software/aula02/img/img008.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-011.png
rename to media/qualidade-e-teste-de-software/aula02/img/img008.png
diff --git a/media/qualidade-e-teste-de-software/aula-012.png b/media/qualidade-e-teste-de-software/aula02/img/img009.png
similarity index 100%
rename from media/qualidade-e-teste-de-software/aula-012.png
rename to media/qualidade-e-teste-de-software/aula02/img/img009.png
diff --git a/media/qualidade-e-teste-de-software/aula03/img/img001.png b/media/qualidade-e-teste-de-software/aula03/img/img001.png
new file mode 100644
index 0000000..94f37d8
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula03/img/img001.png differ
diff --git a/media/qualidade-e-teste-de-software/aula03/img/img002.png b/media/qualidade-e-teste-de-software/aula03/img/img002.png
new file mode 100644
index 0000000..6d39d03
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula03/img/img002.png differ
diff --git a/media/qualidade-e-teste-de-software/aula03/img/img003.png b/media/qualidade-e-teste-de-software/aula03/img/img003.png
new file mode 100644
index 0000000..c7724bb
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula03/img/img003.png differ
diff --git a/media/qualidade-e-teste-de-software/aula04/img/img001.png b/media/qualidade-e-teste-de-software/aula04/img/img001.png
new file mode 100644
index 0000000..f13c316
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula04/img/img001.png differ
diff --git a/media/qualidade-e-teste-de-software/aula04/img/img002.png b/media/qualidade-e-teste-de-software/aula04/img/img002.png
new file mode 100644
index 0000000..cadac79
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula04/img/img002.png differ
diff --git a/media/qualidade-e-teste-de-software/aula04/img/img003.png b/media/qualidade-e-teste-de-software/aula04/img/img003.png
new file mode 100644
index 0000000..8d96d62
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula04/img/img003.png differ
diff --git a/media/qualidade-e-teste-de-software/aula04/img/img004.png b/media/qualidade-e-teste-de-software/aula04/img/img004.png
new file mode 100644
index 0000000..259d92d
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula04/img/img004.png differ
diff --git a/media/qualidade-e-teste-de-software/aula04/img/img005.png b/media/qualidade-e-teste-de-software/aula04/img/img005.png
new file mode 100644
index 0000000..3a2b94e
Binary files /dev/null and b/media/qualidade-e-teste-de-software/aula04/img/img005.png differ