Testes no Desenvolvimento de Software

Prévia do material em texto

<p>1</p><p>TESTES NO ciclo de</p><p>Desenvolvimento</p><p>DE SOFTWARE</p><p>conteúdo</p><p>1. Teste no Processo de Software</p><p>2. Níveis de Testes</p><p>3. Tipos de Testes</p><p>1</p><p>2</p><p>2</p><p>3</p><p>TESTE NO</p><p>PROCESSO DE SOFTWARE</p><p>4</p><p>Um processo de software é um</p><p>conjunto de atividades relacionadas que</p><p>levam à produção de um produto de</p><p>software.</p><p>3</p><p>4</p><p>3</p><p>5</p><p>OBJETIVOS DO PROCESSO DE SOFTWARE</p><p>• Facilitar a compreensão humana,</p><p>comunicação e coordenação;</p><p>• Auxiliar na gestão de projetos de software;</p><p>• Medir e melhorar a qualidade dos</p><p>produtos de software de maneira eficiente;</p><p>• Apoiar a melhoria de processos;</p><p>• Fornecer uma base para o suporte</p><p>automatizado da execução de processos.</p><p>6</p><p>MODELO DE PROCESSO DE SOFTWARE</p><p>Um modelo de processo de</p><p>software é uma representação</p><p>simplificada de um processo de</p><p>software.</p><p>5</p><p>6</p><p>4</p><p>7</p><p>MODELO DE PROCESSO DE SOFTWARE</p><p>Um modelo de processo de</p><p>software é uma representação</p><p>abstrata e de alto nível do processo</p><p>de desenvolvimento de software.</p><p>8</p><p>MODELO DE PROCESSO DE SOFTWARE</p><p>Ele descreve as atividades incluídas</p><p>no processo de desenvolvimento de</p><p>software e as relações entre elas,</p><p>tanto lógicas quanto temporais.</p><p>7</p><p>8</p><p>5</p><p>9</p><p>MODELO DE PROCESSO DE SOFTWARE</p><p>Os modelos são usados para:</p><p>• Determinar como o software será</p><p>desenvolvido;</p><p>• Facilitar a compreensão da sucessão</p><p>de diferentes fases do processo de</p><p>fabricação.</p><p>10</p><p>MODELOS DE SOFTWARE PRESCRITIVOS (TRADICIONAIS)</p><p>1. Modelos Sequenciais: modelo</p><p>cascata, modelo em V;</p><p>2. Modelos Iterativos: modelo</p><p>espiral de Boehm, prototipagem;</p><p>3. Modelos Incrementais: Processo</p><p>Unificado</p><p>9</p><p>10</p><p>6</p><p>11</p><p>MÉTODOS ÁGEIS</p><p>• Scrum</p><p>• Kanban</p><p>• eXtreme Programming (XP)</p><p>• Test-Driven Development (TDD)</p><p>• Acceptance Test-Driven Development (ATDD)</p><p>• Behavior-Driven Development (BDD)</p><p>• Domain-Driven Design (DDD)</p><p>• Feature-Driven Development (FDD)</p><p>12</p><p>TESTE NO PROCESSO SOFTWARE</p><p>O teste, para ser eficaz, deve ser</p><p>integrado ao Modelo do Ciclo de</p><p>Vida de Desenvolvimento de</p><p>Software do projeto.</p><p>11</p><p>12</p><p>7</p><p>13</p><p>EXEMPLO – TESTE NO PROCESSO DE SOFTWARE</p><p>Uma organização, em nome do Ministério</p><p>da Justiça, está desenvolvendo o produto</p><p>Judge Lottery, um sistema para atribuição</p><p>aleatória de casos a juízes.</p><p>14</p><p>EXEMPLO – JUDGE LOTTERY (REQUISITOS)</p><p>Atividade de Desenvolvimento</p><p>• Reunir requisitos do sistema</p><p>• Criar documentação de requisitos.</p><p>Atividade de Teste</p><p>Inspeção dos requisitos quanto à sua:</p><p>• Testabilidade</p><p>• Conformidade com os requisitos de negócios</p><p>• Exemplo: requisitos da Lei sobre os</p><p>Tribunais Gerais.</p><p>13</p><p>14</p><p>8</p><p>15</p><p>EXEMPLO – JUDGE LOTTERY (PROJETO)</p><p>Atividade de Desenvolvimento</p><p>Projeto do Banco de Dados</p><p>Atividade de Teste</p><p>Inspeção do design do banco de dados para</p><p>conformidade com os requisitos do sistema.</p><p>16</p><p>EXEMPLO – JUDGE LOTTERY (IMPLEMENTAÇÃO)</p><p>Atividade de Desenvolvimento</p><p>• Aplicação Baseada na Web;</p><p>• Implementação do front-end;</p><p>Atividade de Teste</p><p>• Testes de Usabilidade;</p><p>• Testes de integração do sistema com o</p><p>banco de dados;</p><p>• Teste do sistema.</p><p>15</p><p>16</p><p>9</p><p>17</p><p>EXEMPLO – JUDGE LOTTERY (IMPLANTAÇÃO)</p><p>Atividade de Desenvolvimento</p><p>Instalação do sistema no ministério da justiça.</p><p>Atividade de Teste</p><p>Teste de aceitação (beta) do sistema no</p><p>ambiente alvo pelos presidentes dos tribunais.</p><p>18</p><p>QUADRANTES DOS TESTES ÁGEIS</p><p>Teste Exploratório</p><p>Cenários</p><p>Teste de Usabilidade</p><p>Teste de Aceitação</p><p>Alfa / Beta</p><p>Testes Funcionais</p><p>Exemplos</p><p>Story Tests</p><p>Protótipos</p><p>Simulações</p><p>Teste de Desempenho</p><p>Teste de Carga</p><p>Teste de Segurança</p><p>Testes de “ilidade”</p><p>Testes Unitários</p><p>Testes de</p><p>Componentes</p><p>Q 3 Q 4</p><p>Q 1 Q 2</p><p>Foco na Tecnologia</p><p>Critica o ProdutoAp</p><p>oi</p><p>a</p><p>o</p><p>Ti</p><p>m</p><p>e</p><p>Foco no Negócio</p><p>Manual</p><p>FerramentasAutomatizado</p><p>Automatizado</p><p>& Manual</p><p>17</p><p>18</p><p>10</p><p>19</p><p>IMPACTO DO PROCESSO DE SOFTWARE NO TESTE DE SOFTWARE</p><p>A escolha do modelo do processo de software</p><p>afeta as seguintes questões de teste:</p><p>• Escopo e cronograma das atividades de teste;</p><p>• Seleção e tempo de níveis e tipos de teste;</p><p>• Nível de detalhe da documentação do teste;</p><p>• Seleção de técnicas e práticas de teste;</p><p>• Escopo da automação de testes.</p><p>20</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>• O conhecimento dos modelos de processo de</p><p>software é crucial para os testadores;</p><p>• A escolha do modelo afeta o momento e a forma</p><p>das atividades de teste;</p><p>• Existem princípios de boas práticas de teste que</p><p>devem ser seguidos, independentemente do</p><p>modelo adotado.</p><p>19</p><p>20</p><p>11</p><p>21</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>Para cada atividade de</p><p>desenvolvimento de software, há uma</p><p>atividade de teste correspondente.</p><p>22</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>• Esse princípio chama a atenção para a</p><p>"totalidade" das atividades de teste;</p><p>• Todo produto de trabalho que foi produzido</p><p>durante o desenvolvimento de software;</p><p>• Deve estar sujeito a controle de qualidade.</p><p>21</p><p>22</p><p>12</p><p>23</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>Cada nível de teste corresponde a</p><p>objetivos de teste apropriados para a</p><p>fase ou grupo de atividades dentro do</p><p>ciclo de desenvolvimento de software.</p><p>24</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>• Os objetivos de teste podem diferir</p><p>significativamente;</p><p>• Em um nível, estaremos principalmente</p><p>interessados em detectar o maior número</p><p>possível de defeitos;</p><p>• Enquanto em outro nível, estaremos mais</p><p>interessados em validar que o sistema atenda</p><p>aos requisitos e necessidades do cliente.</p><p>23</p><p>24</p><p>13</p><p>25</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>A análise e o design de testes para um</p><p>determinado nível de teste devem ser</p><p>iniciados já durante a execução da</p><p>atividade de desenvolvimento de</p><p>software correspondente.</p><p>26</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>• Essa regra está relacionada ao princípio de</p><p>teste precoce;</p><p>• As atividades de teste começam o mais cedo</p><p>possível para detectar problemas assim que</p><p>possível;</p><p>• Defeitos geralmente são baratos para</p><p>corrigir nas fases iniciais e frequentemente</p><p>muito caros nas fases posteriores.</p><p>25</p><p>26</p><p>14</p><p>27</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>• Os testadores devem participar das revisões dos</p><p>produtos de trabalho, por exemplo:</p><p>• Requisitos</p><p>• Design</p><p>• Histórias de Usuário</p><p>• Assim que as versões preliminares dos</p><p>documentos relevantes estiverem disponíveis.</p><p>28</p><p>BOAS PRÁTICAS DE TESTE DE SOFTWARE NO PROCESSO DE SOFTWARE</p><p>• Este princípio destaca o papel do testador como</p><p>especialista em controle de qualidade de</p><p>software;</p><p>• Durante tais revisões, os testadores</p><p>frequentemente conseguem encontrar:</p><p>• Ambiguidades;</p><p>• Erros;</p><p>• Contradições.</p><p>• Se não notados, poderiam resultar em</p><p>problemas sérios no futuro.</p><p>27</p><p>28</p><p>15</p><p>29</p><p>abordagem</p><p>TEST-FIRST</p><p>30</p><p>ABORDAGEM TEST-FIRST</p><p>Antes que o código-fonte que implementa</p><p>uma função específica seja escrito, um</p><p>teste para essa função é criado.</p><p>29</p><p>30</p><p>16</p><p>31</p><p>ABORDAGEM TEST-FIRST</p><p>• A abordagem “test-first" tem origem na</p><p>programação extrema (XP)</p><p>• É uma das práticas fundamentais do</p><p>desenvolvimento ágil de software.</p><p>• Essa abordagem pode parecer</p><p>contraintuitiva, porque normalmente</p><p>criamos algo primeiro e testamos depois;</p><p>32</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Testar substitui o método de</p><p>tentativa e erro</p><p>31</p><p>32</p><p>17</p><p>33</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>• Em vez de verificar por tentativa e erro</p><p>se uma função implementada funciona</p><p>corretamente;</p><p>• Um conjunto de casos de teste</p><p>significativos é criado com valores de</p><p>entrada e saída estritamente definidos;</p><p>• O código é escrito para passar nesses</p><p>testes.</p><p>34</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Casos de teste fornecem</p><p>feedback objetivo sobre o</p><p>andamento do projeto.</p><p>33</p><p>34</p><p>18</p><p>35</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Cada teste que é aprovado é uma</p><p>evidência objetiva de que o</p><p>projeto está avançando</p><p>36</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Casos de teste substituem</p><p>especificações.</p><p>35</p><p>36</p><p>19</p><p>37</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>• Os testes, escritos antes do código, não</p><p>são apenas procedimentos de controle;</p><p>• Mas também definem o comportamento</p><p>do objeto de teste, servindo como uma</p><p>"documentação viva".</p><p>38</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>• Documentação Viva: alterações nos</p><p>requisitos implicam mudanças nos</p><p>testes;</p><p>• Garantindo que a documentação</p><p>permaneça relevante durante todo o</p><p>projeto.</p><p>37</p><p>38</p><p>20</p><p>39</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Melhora a qualidade das</p><p>interfaces de programação de</p><p>aplicações (APIs) públicas</p><p>40</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Teste de componente e teste de</p><p>integração de componente utilizam</p><p>os métodos públicos das classes</p><p>sob teste.</p><p>39</p><p>40</p><p>21</p><p>41</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>• Como os testes são escritos antes do código;</p><p>• Eles definem os nomes dos métodos públicos</p><p>da classe sob teste, seus parâmetros e</p><p>exemplos de uso dos métodos;</p><p>• Logo, o design dos testes se torna</p><p>praticamente a definição da interface de</p><p>programação.</p><p>42</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Melhora a estabilidade dos</p><p>testes do código em</p><p>desenvolvimento</p><p>41</p><p>42</p><p>22</p><p>43</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>• Uma vez que os testes são</p><p>implementados, o desenvolvedor deve</p><p>então escrever código que os passe.</p><p>• Isso implica que o código deve invocar as</p><p>interfaces requeridas pelos testes.</p><p>44</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>• Em vez de escrever testes que verifiquem o</p><p>código existente</p><p>• O desenvolvedor deve escrever código que</p><p>seja "compatível" com os testes escritos</p><p>anteriormente.</p><p>43</p><p>44</p><p>23</p><p>45</p><p>BENEFÍCIOS DA ABORDAGEM TEST-FIRST</p><p>Como o código é escrito para passar em testes</p><p>específicos:</p><p>• O programador tem um controle melhor</p><p>do código;</p><p>• Consegue alcançar mais facilmente um</p><p>nível mais alto de cobertura de código com</p><p>os testes.</p><p>46</p><p>TESTE ORIENTANDO O DESENVOLVIMENTO DE SOFTWARE</p><p>Métodos de desenvolvimento populares</p><p>baseados na abordagem test-first:</p><p>• Desenvolvimento Orientado a Testes (TDD)</p><p>• Desenvolvimento Orientado ao Comportamento</p><p>(BDD)</p><p>• Desenvolvimento Orientado a Testes de</p><p>Aceitação (ATDD)</p><p>TDD ATDD</p><p>BDD</p><p>45</p><p>46</p><p>24</p><p>47</p><p>MÉTODOS DE DESENVOLVIMENTO TEST-FIRST</p><p>O TDD foca nos testes de</p><p>componentes TDD ATDD</p><p>BDD</p><p>48</p><p>TDD</p><p>• O TDD usa casos de teste automatizados de</p><p>componentes para orientar o desenvolvimento</p><p>de código</p><p>• Geralmente é realizado por um desenvolvedor.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>47</p><p>48</p><p>25</p><p>49</p><p>1. ESCREVA UM TESTE - TDD</p><p>• O programador escreve um teste</p><p>automatizado que define uma nova</p><p>funcionalidade ou uma mudança em uma</p><p>funcionalidade existente;</p><p>• Este teste deve falhar inicialmente;</p><p>• Pois a funcionalidade ainda não foi</p><p>implementada.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>50</p><p>2. FAÇA O TESTE PASSAR - TDD</p><p>O programador escreve o código de</p><p>produção mínimo necessário para</p><p>que o teste automatizado passe.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>49</p><p>50</p><p>26</p><p>51</p><p>3. REFATORE O CÓDIGO - TDD</p><p>• Uma vez que o teste esteja passando</p><p>• O código é refatorado para:</p><p>• Melhorar sua estrutura, legibilidade e</p><p>eficiência;</p><p>• E, manter os testes passando. REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>52</p><p>TDD</p><p>1. Escreva um teste;</p><p>2. Faça o teste passar;</p><p>3. Refatore o código;</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>51</p><p>52</p><p>27</p><p>53</p><p>TDD</p><p>Repita o processo</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>54</p><p>EXEMPLO TDD</p><p>• Ao longo do semestre, os estudantes de uma</p><p>universidade realizam quatro avaliações, cada uma</p><p>valendo 25 pontos, totalizando 100 pontos ao final do</p><p>semestre.</p><p>• Caso a nota final de um estudante seja inferior a 60</p><p>pontos, ele tem direito a uma recuperação.</p><p>• No entanto, se a nota for inferior a 40 pontos, ele é</p><p>reprovado diretamente.</p><p>TDD ATDD</p><p>BDD</p><p>53</p><p>54</p><p>28</p><p>55</p><p>1. ESCREVA UM TESTE - TDD</p><p>• O programador escreve um teste</p><p>automatizado que define uma nova</p><p>funcionalidade ou uma mudança em uma</p><p>funcionalidade existente;</p><p>• Este teste deve falhar inicialmente;</p><p>• Pois a funcionalidade ainda não foi</p><p>implementada.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>56</p><p>1. ESCREVA UM TESTE - TDD</p><p>import org.junit.jupiter.api.Test;</p><p>import static org.junit.jupiter.api.Assertions.*;</p><p>class AlunoTest {</p><p>private final Aluno alunoSobTeste = new Aluno();</p><p>@Test</p><p>void deveAprovarAluno() {</p><p>float notaFinal = 75.00f;</p><p>String saidaEsperada = "Aprovado";</p><p>String resultado = alunoSobTeste.verificarStatus(notaFinal);</p><p>assertEquals(saidaEsperada, resultado);</p><p>}</p><p>}</p><p>TDD ATDD</p><p>BDD</p><p>55</p><p>56</p><p>29</p><p>57</p><p>2. FAÇA O TESTE PASSAR - TDD</p><p>O programador escreve o código de</p><p>produção mínimo necessário para</p><p>que o teste automatizado passe.</p><p>TDD ATD</p><p>D</p><p>BD</p><p>D</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>58</p><p>2. FAÇA O TESTE PASSAR - TDD</p><p>public class Aluno {</p><p>public String verificarStatus(float nota) {</p><p>if (nota >= 60.00) {</p><p>return "Aprovado";</p><p>} else {</p><p>return "Reprovado";</p><p>}</p><p>}</p><p>} // Fim da classe Aluno</p><p>TDD ATDD</p><p>BDD</p><p>57</p><p>58</p><p>30</p><p>59</p><p>3. REFATORE O CÓDIGO - TDD</p><p>• Uma vez que o teste esteja passando</p><p>• O código é refatorado para:</p><p>• Melhorar sua estrutura, legibilidade e</p><p>eficiência;</p><p>• E, manter os testes passando. REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>60</p><p>3. REFATORE O CÓDIGO - TDD</p><p>Neste ponto, não há</p><p>necessidade de refatoração.</p><p>O teste está passando e o</p><p>código é simples.</p><p>TDD ATDD</p><p>BDD</p><p>59</p><p>60</p><p>31</p><p>61</p><p>1. ESCREVA UM TESTE - TDD</p><p>Vamos escrever um teste para verificar se a</p><p>função retorna “Recuperação" para uma nota</p><p>menor que 60 e maior ou igual a 40.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>62</p><p>1. ESCREVA UM TESTE - TDD</p><p>@Test</p><p>void deveFicarDeRecuperacao() {</p><p>float notaFinal = 50.00f;</p><p>String saidaEsperada = "Recuperação";</p><p>String resultado = alunoSobTeste.verificarStatus(notaFinal);</p><p>assertEquals(saidaEsperada, resultado);</p><p>}</p><p>TDD ATDD</p><p>BDD</p><p>61</p><p>62</p><p>32</p><p>63</p><p>2. FAÇA O TESTE PASSAR - TDD</p><p>O programador escreve o código de</p><p>produção mínimo necessário para</p><p>que o teste automatizado passe.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>64</p><p>2. FAÇA O TESTE PASSAR - TDD</p><p>public class Aluno {</p><p>public String verificarStatus(float nota) {</p><p>if (nota >= 60.00) {</p><p>return "Aprovado";</p><p>} else if (nota >= 40.00) {</p><p>return "Recuperação";</p><p>} else {</p><p>return "Reprovado";</p><p>}</p><p>}</p><p>} // Fim da classe Aluno</p><p>TDD ATDD</p><p>BDD</p><p>63</p><p>64</p><p>33</p><p>65</p><p>3. REFATORE O CÓDIGO - TDD</p><p>• Uma vez que o teste esteja passando</p><p>• O código é refatorado para:</p><p>• Melhorar sua estrutura, legibilidade e</p><p>eficiência;</p><p>• E, manter os testes passando. REFATORAR VERDE</p><p>VERMELHO</p><p>TDD ATDD</p><p>BDD</p><p>66</p><p>3. REFATORE O CÓDIGO - TDD</p><p>• Problema: Seu código usa um número que</p><p>tem um certo significado.</p><p>• Solução: Substitua esse número por uma</p><p>constante que tenha um nome legível</p><p>explicando o significado do número.</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>Replace Magic Number with Symbolic Constant</p><p>TDD ATDD</p><p>BDD</p><p>65</p><p>66</p><p>34</p><p>67</p><p>3. REFATORE O CÓDIGO - TDD</p><p>public class Aluno {</p><p>public static final float NOTA_APROVACAO = 60.00f;</p><p>public static final float NOTA_RECUPERACAO = 40.00f;</p><p>public Status verificarStatus(float nota) {</p><p>if (nota >= NOTA_APROVACAO) {</p><p>return Status.APROVADO;</p><p>} else if (nota >= NOTA_RECUPERACAO) {</p><p>return Status.RECUPERACAO;</p><p>} else {</p><p>return Status.REPROVADO;</p><p>}</p><p>}</p><p>} // Fim da classe Aluno</p><p>TDD ATDD</p><p>BDD</p><p>68</p><p>3. REFATORE O CÓDIGO - TDD</p><p>public enum Status {</p><p>APROVADO,</p><p>REPROVADO,</p><p>RECUPERACAO</p><p>}</p><p>TDD ATDD</p><p>BDD</p><p>67</p><p>68</p><p>35</p><p>69</p><p>3. REFATORE O CÓDIGO - TDD</p><p>Mantenha o Teste Passando</p><p>TDD ATDD</p><p>BDD</p><p>REFATORAR VERDE</p><p>VERMELHO</p><p>70</p><p>3. REFATORE O CÓDIGO - TDD</p><p>import org.junit.jupiter.api.Test;</p><p>import static org.junit.jupiter.api.Assertions.*;</p><p>class AlunoTest {</p><p>private final Aluno alunoSobTeste = new Aluno();</p><p>@Test</p><p>void deveAprovarAluno() {</p><p>float notaFinal = 75.00f;</p><p>Status saidaEsperada = Status.APROVADO;</p><p>Status resultado = alunoSobTeste.verificarStatus(notaFinal);</p><p>assertEquals(saidaEsperada, resultado);</p><p>}</p><p>@Test</p><p>void deveFicarDeRecuperacao() {</p><p>float notaFinal = 50.00f;</p><p>Status saidaEsperada = Status.RECUPERACAO;</p><p>Status resultado = alunoSobTeste.verificarStatus(notaFinal);</p><p>assertEquals(saidaEsperada, resultado);</p><p>}</p><p>}</p><p>69</p><p>70</p><p>36</p><p>71</p><p>MÉTODOS DE DESENVOLVIMENTO TEST-FIRST</p><p>O BDD foca nos testes de</p><p>comportamento do sistema TDD ATDD</p><p>BDD</p><p>72</p><p>ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>Software</p><p>Funcionando</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>71</p><p>72</p><p>37</p><p>73</p><p>HISTÓRIAS DE USUÁRIO</p><p>TDD ATDD</p><p>BDD</p><p>Levantar Requisitos usando</p><p>Histórias de Usuário.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>74</p><p>1. DESCOBERTA - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>• Discutir exemplos concretos da nova</p><p>funcionalidade a ser explorada.</p><p>• Descobrir e concordar sobre os</p><p>detalhes do que se espera ser feito.</p><p>• Explorar os casos de uso e as</p><p>interações que essa mudança implicará.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>73</p><p>74</p><p>38</p><p>75</p><p>1. DESCOBERTA - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>Chegar a um entendimento</p><p>comum entre todas as partes</p><p>interessadas sobre os requisitos e</p><p>expectativas da funcionalidade.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>76</p><p>MAPEAMENTO</p><p>TDD ATDD</p><p>BDD</p><p>1. Histórias de Usuário (Amarelo):</p><p>funcionalidade desejada pelo usuário</p><p>2. Critérios de Aceite - Regras (Azul): condição</p><p>que a funcionalidade deve atender para ser</p><p>aceita pelo usuário;</p><p>3. Exemplo (Verde): exemplos para ilustrar os</p><p>critérios de aceitação;</p><p>4. Questões (Vermelho): dúvidas que não</p><p>podem ser respondidas</p><p>75</p><p>76</p><p>39</p><p>77</p><p>2. FORMULAÇÃO - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>1. Descrever os comportamentos do</p><p>sistema em termos de cenários e</p><p>casos de teste.</p><p>2. Isso é feito utilizando uma linguagem</p><p>de domínio específico (DSL) como</p><p>Gherkin.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>78</p><p>2. FORMULAÇÃO - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>3. Os cenários e casos de teste são</p><p>baseados em exemplos concretos</p><p>para tornar as especificações mais</p><p>compreensíveis.</p><p>4. As especificações são revisadas e</p><p>validadas pelas partes interessadas</p><p>para garantir sua precisão e</p><p>abrangência.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>77</p><p>78</p><p>40</p><p>79</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• Gherkin é uma linguagem de especificação</p><p>utilizada para descrever o comportamento</p><p>de um software em termos de cenários de</p><p>teste;</p><p>• Ela é uma linguagem baseada em texto</p><p>simples e fácil de entender;</p><p>• Permite que todos os membros da equipe</p><p>de desenvolvimento possam compreender</p><p>e colaborar nos cenários de teste.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>80</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• Funcionalidade (Feature): identifica a</p><p>funcionalidade que será implementada.</p><p>• Geralmente é a primeira linha do arquivo e</p><p>deve ser seguida de uma descrição</p><p>detalhada da funcionalidade.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>79</p><p>80</p><p>41</p><p>81</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• Cenário (Scenario): identifica um cenário de</p><p>teste específico dentro da funcionalidade.</p><p>• Cada cenário deve ser uma descrição de</p><p>um comportamento esperado do sistema.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>82</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• Dado (Given): descreve o estado inicial do</p><p>sistema antes do teste.</p><p>• Geralmente é usado para definir as pré-</p><p>condições do cenário.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>81</p><p>82</p><p>42</p><p>83</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• E (And): adiciona um passo adicional à</p><p>sequência de passos de um cenário.</p><p>• Mas (But): é a palavra-chave usada para</p><p>adicionar uma condição de exceção a</p><p>um cenário.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>84</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• Quando (When): descreve a ação que está</p><p>sendo realizada no cenário de teste.</p><p>• É a etapa que gera a mudança no estado</p><p>do sistema.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>83</p><p>84</p><p>43</p><p>85</p><p>GHERKIN</p><p>TDD ATDD</p><p>BDD</p><p>• Então (Then): descreve o resultado</p><p>esperado do teste.</p><p>• É a etapa que verifica se a ação</p><p>realizada no passo anterior produziu</p><p>o resultado esperado.</p><p>Funcionalidade: Adição de produto ao carrinho</p><p>Como um usuário logado</p><p>Eu quero adicionar um produto ao meu carrinho</p><p>Para que eu possa comprar o produto posteriormente</p><p>Cenário: Adição de produto com estoque insuficiente</p><p>Dado que estou logado no sistema</p><p>E estou na página do produto que desejo adicionar ao carrinho</p><p>Mas o estoque do produto está zerado</p><p>Quando clico no botão "Adicionar ao carrinho"</p><p>Então devo ver a mensagem "Estoque insuficiente"</p><p>E não devo ver o produto no meu carrinho</p><p>86</p><p>3. AUTOMAÇÃO - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>Implementar testes</p><p>automatizados que verifiquem o</p><p>comportamento do sistema em</p><p>relação às especificações definidas.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>85</p><p>86</p><p>44</p><p>87</p><p>FEEDBACK</p><p>TDD ATDD</p><p>BDD</p><p>Software</p><p>Funcionando</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>• Realizar mudanças pequenas e iterativas,</p><p>movendo-se para níveis superiores</p><p>sempre que mais informações forem</p><p>necessárias.</p><p>• Automatizar e implementar cada exemplo</p><p>novo, adicionando valor ao sistema e</p><p>permitindo responder ao feedback</p><p>rapidamente.</p><p>88</p><p>FRAMEWORKS BDD</p><p>TDD ATDD</p><p>BDD</p><p>87</p><p>88</p><p>45</p><p>89</p><p>CALCULADORA – EXEMPLO BDD</p><p>TDD ATDD</p><p>BDD</p><p>• Considere uma aplicação simples e eficiente</p><p>projetada para realizar operações básicas</p><p>matemáticas.</p><p>• O usuário pode facilmente inserir números e</p><p>selecionar a operação</p><p>desejada entre adição,</p><p>subtração, multiplicação e divisão</p><p>90</p><p>1. DESCOBERTA - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>Chegar a um entendimento</p><p>comum entre todas as partes</p><p>interessadas sobre os requisitos e</p><p>expectativas da funcionalidade.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>89</p><p>90</p><p>46</p><p>91</p><p>CALCULADORA | MAPEAMENTO</p><p>1. Histórias de Usuário (Amarelo):</p><p>funcionalidade desejada pelo usuário</p><p>2. Critérios de Aceite - Regras (Azul): condição</p><p>que a funcionalidade deve atender para ser</p><p>aceita pelo usuário;</p><p>3. Exemplo (Verde): exemplos para ilustrar os</p><p>critérios de aceitação;</p><p>4. Questões (Vermelho): dúvidas que não</p><p>podem ser respondidas</p><p>92</p><p>2. FORMULAÇÃO - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>• Descrever os comportamentos do</p><p>sistema em termos de cenários e</p><p>casos de teste.</p><p>• Isso é feito utilizando uma linguagem</p><p>de domínio específico (DSL) como</p><p>Gherkin.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>91</p><p>92</p><p>47</p><p>93</p><p>2. FORMULAÇÃO - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>• Descrever os comportamentos do</p><p>sistema em termos de cenários e</p><p>casos de teste.</p><p>• Isso é feito utilizando uma linguagem</p><p>de domínio específico (DSL) como</p><p>Gherkin.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>94</p><p>3. AUTOMAÇÃO - ATIVIDADES DO BDD</p><p>TDD ATDD</p><p>BDD</p><p>Implementar testes</p><p>automatizados que verifiquem o</p><p>comportamento do sistema em</p><p>relação às especificações definidas.</p><p>Histórias</p><p>de Usuário</p><p>Descoberta Formulação Automação</p><p>Software</p><p>Funcionando</p><p>93</p><p>94</p><p>48</p><p>95</p><p>MÉTODOS DE DESENVOLVIMENTO TEST-FIRST</p><p>O ATDD foca nos testes de</p><p>aceitação do sistema TDD ATDD</p><p>BDD</p><p>96</p><p>MÉTODOS DE DESENVOLVIMENTO TEST-FIRST</p><p>• Segue o mesmo procedimento definido</p><p>para o TDD e BDD;</p><p>• Porém com casos de teste</p><p>automatizados que estão no nível</p><p>apropriado para testes de aceitação.</p><p>TDD ATDD</p><p>BDD</p><p>95</p><p>96</p><p>49</p><p>97</p><p>MÉTODOS DE DESENVOLVIMENTO TEST-FIRST</p><p>• Esses casos de teste de aceitação são</p><p>derivados de critérios de aceitação que são</p><p>gerados em conjunto por:</p><p>• Desenvolvedores</p><p>• Testadores</p><p>• Representantes de negócios.</p><p>TDD ATDD</p><p>BDD</p><p>98</p><p>MÉTODOS DE DESENVOLVIMENTO TEST-FIRST</p><p>1. Selecionar uma história do usuário.</p><p>2. Escrever um teste de aceitação.</p><p>3. Implementar a história do usuário</p><p>(codificação).</p><p>4. Executar um teste de aceitação.</p><p>5. Refatorar o código, se necessário.</p><p>6. Obter aprovação da história do usuário</p><p>(assinatura).</p><p>TDD ATDD</p><p>BDD</p><p>97</p><p>98</p><p>50</p><p>99</p><p>FRAMEWORK ATDD</p><p>100</p><p>abordagem</p><p>SHIFT-LEFT</p><p>99</p><p>100</p><p>51</p><p>101</p><p>ABORDAGEM SHIFT-LEFT</p><p>Testes iniciais economizam</p><p>tempo e dinheiro</p><p>102</p><p>ABORDAGEM SHIFT-LEFT</p><p>É uma abordagem na qual o teste</p><p>é feito o mais cedo possível em</p><p>um determinado Processo de</p><p>Software</p><p>101</p><p>102</p><p>52</p><p>103</p><p>ABORDAGEM SHIFT-LEFT</p><p>• Shift-left geralmente implica que os testes</p><p>devem ser feitos mais cedo, ou seja, sem</p><p>esperar pela:</p><p>• Implementação do código;</p><p>• Integração de componentes.</p><p>• Não significa que os testes posteriores no</p><p>ciclo de desenvolvimento devam ser</p><p>negligenciados</p><p>104</p><p>COMO ALCANÇAR O SHIFT-LEFT NO TESTE DE SOFTWARE</p><p>• Revisões</p><p>• Integração e Entrega Contínua – CI/CD</p><p>• Análise Estática</p><p>• Testes Não funcionais</p><p>• Teste Baseado em Modelo</p><p>103</p><p>104</p><p>53</p><p>105</p><p>REVISÕES</p><p>• As revisões podem ser realizadas no início do</p><p>ciclo de desenvolvimento, mesmo antes do</p><p>código ser escrito.</p><p>• Uma revisão da especificação geralmente</p><p>encontra defeitos potenciais na especificação,</p><p>como:</p><p>• Ambiguidades;</p><p>• Incompletude;</p><p>• Inconsistências;</p><p>• Elementos supérfluos ou contradições.</p><p>106</p><p>INTEGRAÇÃO E ENTREGA CONTÍNUA – CI/CD</p><p>• Fornece feedback rápido sobre a</p><p>qualidade do código</p><p>• Força a criação de testes</p><p>automatizados para o código-fonte</p><p>• À medida que ele é enviado ao</p><p>repositório de código.</p><p>105</p><p>106</p><p>54</p><p>107</p><p>ANÁLISE ESTÁTICA</p><p>• A análise estática do código-fonte pode</p><p>ser realizada antes do teste dinâmico</p><p>• Como parte de um processo</p><p>automatizado, como um pipeline de</p><p>implantação de DevOps</p><p>108</p><p>TESTES NÃO FUNCIONAIS</p><p>• Realizar Testes Não Funcionais o mais rápido</p><p>possíveis;</p><p>• Esta é uma forma de Shift-Left;</p><p>• Testes não funcionais geralmente são feitos</p><p>mais tarde no ciclo de desenvolvimento de</p><p>software</p><p>• Quando um sistema completo e ambientes de</p><p>teste representativos estão disponíveis.</p><p>107</p><p>108</p><p>55</p><p>109</p><p>TESTE BASEADO EM MODELO</p><p>• Nesta abordagem, o testador utiliza ou cria</p><p>um modelo do software;</p><p>• Uma ferramenta especial com base neste</p><p>modelo cria automaticamente casos de</p><p>teste que atingem um determinado critério</p><p>de cobertura;</p><p>• O modelo geralmente pode ser criado antes</p><p>do início do trabalho de implementação.</p><p>110</p><p>EXEMPLO - SHIFT-LEFT NOS MODELOS ITERATIVOS</p><p>• Nos modelos iterativos: Espiral e</p><p>Prototipagem;</p><p>• O teste geralmente está presente</p><p>em todas as iterações;</p><p>• Logo, os testes começam no início</p><p>do projeto. 1. COMUNICAÇÃO</p><p>4. CONSTRUÇÃO</p><p>Do Protótipo</p><p>5. IMPLANTAÇÃO</p><p>Entrega e</p><p>Feedback</p><p>2. PLANEJAMENTO</p><p>Rápido</p><p>3. MODELAGEM</p><p>Projeto Rápido</p><p>109</p><p>110</p><p>56</p><p>111</p><p>EXEMPLO - SHIFT-LEFT NO TEST-FIRST</p><p>• Na abordagem Test-First;</p><p>• Os testes são escritos antes da</p><p>implementação do código;</p><p>• Naturalmente as atividades de teste são</p><p>movidas para o início do ciclo de</p><p>desenvolvimento.</p><p>TDD ATDD</p><p>BDD</p><p>BIBLIOGRAFIA</p><p>STAPP, Lucjan; ROMAN, Adam; PILAETEN, Micha</p><p>ël. ISTQB – Certified Tester Foundation Level: A</p><p>Self-Study Guide Syllabus v4.0. Chapter 2. Testing</p><p>in the Context of a Software Development Cycle.</p><p>Springer, 2023.</p><p>111</p><p>112</p><p>57</p><p>BIBLIOGRAFIA</p><p>MYERS, Glenford J.; BADGETT, Tom; SANDLER,</p><p>Corey. The Art of Software Testing. Wiley, 2011.</p><p>BIBLIOGRAFIA</p><p>SOMMERVILLE, Ian. Engenharia de Software. Cap. 2</p><p>– Processo de Software. pág. 18. Cap. 3 –</p><p>Desenvolvimento Ágil de Software. pág. 38. Pearson,</p><p>2019.</p><p>113</p><p>114</p><p>58</p><p>BIBLIOGRAFIA</p><p>PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia</p><p>de Software: Uma Abordagem Profissional. Cap.</p><p>4.1 Modelos de Processos Prescritivos, pág. 41.</p><p>AMGH, 2021.</p><p>BIBLIOGRAFIA</p><p>BOURQUE, Pierre.; FAIRLEY, Richard E. (Dick).</p><p>SWEBOK V3.0. Chapter 8. Software Engineering</p><p>Process, pág. 81. AMGH, 2021.</p><p>115</p><p>116</p><p>59</p><p>Diego Augusto Barros é bacharel em Sistemas de</p><p>Informação pela Pontifícia Universidade Católica de Minas</p><p>Gerais (2012) e mestre em Ciência da Computação pela</p><p>Universidade Federal de Minas Gerais (2015).</p><p>Sua pesquisa concentra-se nas áreas de Visualização de</p><p>Dados e Interação Humano-computador, e investiga</p><p>fatores cognitivos e perceptivos envolvidos na análise de</p><p>grandes conjuntos de dados, que resultam em novos</p><p>sistemas interativos para comunicação e análise visual.</p><p>Seus principais interesses nas áreas são: visualização de</p><p>informação, Visual Analytics, métodos de avaliação de</p><p>interfaces, interação com sistemas, tecnologias web,</p><p>sistemas de informação, engenharia de software e</p><p>informática na educação.</p><p>diegoaugustobarros.com</p><p>@diegoaugustobarros</p><p>@profdiegoaugusto</p><p>PROF. DIEGO AUGUSTO BARROS</p><p>117</p>