Aula 1 — Plano de Ensino — Testes em aplicações de linguagem natural

1. Identificação

Componente	Registro
Módulo	Módulo 8 — Arquitetura digital segura e tolerante a falhas
Curso	Engenharia de Software
Encontro	Aula 1 — Testes em aplicações de linguagem natural
Data e duração	18/09/2026 · 120 minutos
Docente	Afonso Brandão
Natureza	Aprendizagem em equipe com cinco decisões de arquitetura, uma por categoria de exceção, sistematização conceitual e aplicação em grupo sobre o projeto do parceiro
Artefatos do módulo	Lista de exceções classificadas por categoria; arquivo de cenários em Gherkin dos requisitos não funcionais; tabela de benchmarking dos serviços de processamento de linguagem natural, produzida fora do encontro
Recurso próprio	Sala de aprendizagem em equipe publicada no acervo, com painel de condução do docente

2. Objetivo de aprendizagem

Ao final do encontro, o estudante deve ser capaz de enumerar, por categoria, as exceções que um trecho de código do projeto precisa tratar fora do caminho feliz — regra de negócio incompleta, infraestrutura, segurança por fraude ou imprecisão, não repúdio e usabilidade —, associar cada exceção à característica de qualidade correspondente da ISO/IEC 25010 e convertê-la em requisito verificável com valor, unidade, limiar, nível de teste e oráculo declarado, redigindo o cenário de aceitação correspondente em Gherkin.

Resultados observáveis

Justificar uma decisão de arquitetura declarando a classe de falha que ela intercepta e a evidência que a refutaria.
Rever a própria decisão diante de dado novo, indicando se a escolha anterior sobrevive à evidência apresentada.
Distinguir o caminho feliz das demais condições de execução de um trecho de código.
Enumerar exceções nas cinco categorias, com ao menos duas por categoria.
Declarar a consequência da ausência de tratamento de cada exceção.
Identificar a etapa da cadeia de processamento em que cada exceção se origina.
Associar cada exceção à característica correspondente da ISO/IEC 25010 e registrar as características sem exceção correspondente.
Converter atributo enunciado por adjetivo em especificação com valor, unidade e instrumento de medição.
Declarar o oráculo de um requisito por conjunto de referência ou por propriedade invariante.
Alocar cada verificação ao nível de teste em que o defeito é isolável, com justificativa.
Redigir um cenário em Gherkin com uma única cláusula Quando e resultado observável em Então.
Distinguir redação declarativa de redação imperativa em cenários de aceitação.
Distinguir autenticação, integridade e não repúdio, e indicar os mecanismos que sustentam o terceiro.

3. Produtos do encontro

Decisões registradas no TBL

Dez escolhas individuais — duas por questão, uma antes e outra depois da discussão —, cada uma com justificativa escrita, e a matriz de transições de cada questão.

Lista de exceções classificadas

Exceções do trecho de código em exame, ao menos duas por categoria, com a consequência da ausência de tratamento e a característica da ISO/IEC 25010 correspondente.

Cenários em Gherkin

Três exceções convertidas em requisito com valor, unidade e limiar, cada uma com cenário de aceitação, oráculo declarado e nível de teste.

Registro transversal

A lista de exceções e o arquivo de cenários são versionados no repositório do grupo ao final do encontro e alimentam o plano de teste dos requisitos não funcionais do módulo. A tabela de benchmarking é produzida fora do encontro e retomada na aula seguinte.

4. Preparação

Responsabilidade dos grupos

Ler as seções 2 a 15 do material antes do encontro.
Realizar o Autoestudo 1 (páginas 1 a 5 e 10 a 14 do artigo) e o Autoestudo 2 (Pressman, 372 a 387).
Assistir ao vídeo sobre o ciclo de desenvolvimento dirigido por testes, incorporado à seção 15 do material.
Levar o trecho de código do projeto que será submetido à enumeração de exceções, identificado por arquivo e função.
Levar a lista de requisitos não funcionais já acordados com o parceiro.
Levar o repositório do projeto com a suíte de testes existente em condição de execução.
Levar dispositivo com acesso à internet para a participação individual no TBL.

Responsabilidade do docente

Abrir o painel do TBL e autenticar-se com o token antes do início do encontro.
Verificar a sala em lobby, sem participantes remanescentes de turma anterior.
Projetar o endereço da sala e confirmar o acesso da turma antes da primeira rodada.
Preparar o exemplo de trilha de auditoria encadeada utilizado no bloco de não repúdio.
Preparar a tabela em branco de enumeração de exceções por categoria para distribuição.
Registrar as lacunas identificadas nas listas de exceção para retomada na aula seguinte do módulo.

5. Cronograma

Tempo	Bloco	Conteúdo
15 min	Daily	Estado dos artefatos, atividade prevista para o encontro e impedimentos de cada grupo.
5 min	Abertura	Tese do encontro, apresentação do caso do PIX, das cinco questões e das regras do TBL.
9 min	Questão 1	Regra de negócio incompleta: a combinação que a regra não previu. Decisão individual (3), discussão (4) e segunda decisão (2).
9 min	Questão 2	Infraestrutura: a ordem liquidada cuja resposta não chegou e a duplicidade por reenvio.
9 min	Questão 3	Fraude e imprecisão: a resposta primária à perda, com a reclassificação das 1.870 ocorrências liberada na discussão.
9 min	Questão 4	Não repúdio: a ordem que o titular nega ter emitido e o mecanismo que sustenta a prova.
9 min	Questão 5	Usabilidade: a confirmação que deixou de ser lida por habituação.
5 min	Consolidado	Projeção das distribuições das cinco questões e leitura dos deslocamentos.
15 min	Exceções	Caminho feliz, cinco categorias de exceção, cadeia de processamento, não repúdio e conversão da exceção em requisito verificável.
25 min	ISO 25010 e Gherkin	Características de qualidade, estrutura do cenário e produção em grupo da lista de exceções e dos cenários do projeto.
5 min	Encaminhamentos	Tabela de benchmarking, autoestudos e vídeo do ciclo de desenvolvimento dirigido por testes.
5 min	Fechamento	O valor da atitude de qualidade para o projeto entregue ao parceiro.

6. Roteiro de condução

Enunciar a tese do encontro: um trecho de código é defendido pelos testes que saem do caminho feliz.
Apresentar o caso do PIX com os números do trimestre e as três origens de incidente que a classificação vigente não distingue.
Apresentar as cinco questões e as quatro táticas de cada uma, com ganho e custo declarados, sem indicar preferência.
Projetar o endereço da sala, confirmar o acesso da turma e abrir a primeira questão pelo painel.
Durante a decisão individual, acompanhar a presença e o número de decisões registradas sem projetar a distribuição.
Avançar para a discussão e conduzir a leitura das justificativas, solicitando que cada uma seja examinada por três perguntas: que exceção trata, que suposição carrega e que evidência a derrubaria.
Abrir a segunda decisão, com a distribuição revelada, e acompanhar a migração entre táticas.
Projetar a síntese da questão e passar à seguinte, repetindo o percurso nas cinco.
Na terceira questão, verificar que a reclassificação das ocorrências foi lida antes do registro da segunda decisão.
Ao final, projetar o consolidado das cinco questões e conduzir a leitura dos deslocamentos, distinguindo migração pelo argumento de migração pela evidência.
Estabelecer a passagem ao bloco conceitual: em 78% das ocorrências o sistema executou corretamente o que foi pedido, e a perda ocorreu com o caminho feliz percorrido inteiro.
Expor as cinco categorias de exceção e solicitar que cada grupo identifique, no próprio projeto, uma exceção de cada categoria.
Percorrer a cadeia de processamento indicando a etapa em que cada categoria se manifesta, e tratar o não repúdio com o exemplo da trilha encadeada.
Demonstrar a conversão de exceção em requisito verificável, com métrica, limiar, nível de teste e oráculo declarado.
Apresentar as oito características da ISO/IEC 25010 e solicitar a distribuição das exceções já levantadas entre elas.
Expor a estrutura do cenário em Gherkin sobre os exemplos do caso do PIX, contrastando redação declarativa e imperativa.
Enunciar a atividade, distribuir a tabela de enumeração e acompanhar os grupos, verificando a declaração de oráculo e de nível de teste em cada linha.
Encaminhar a tabela de benchmarking, os autoestudos e o vídeo do ciclo de desenvolvimento dirigido por testes.
Fechar com as quatro proposições sobre o valor da atitude de qualidade no projeto.

7. Metodologia

Aprendizagem em equipe conduzida sobre uma decisão de arquitetura sem resposta correta, em que cada participante registra a escolha individualmente antes de conhecer a posição da turma. A sequência de rodadas separa dois efeitos: o do argumento alheio, observado entre a primeira e a segunda decisão, e o da evidência nova, observado entre a segunda e a terceira. O que se avalia é a consistência entre a evidência disponível e a decisão declarada.

O bloco conceitual é derivado da discussão precedente: as categorias de exceção são apresentadas depois que a turma constatou que o sistema do caso operou corretamente e a perda ocorreu. A aplicação transfere o procedimento ao projeto do parceiro, com a lista de exceções e os cenários produzidos em sala e versionados no repositório de cada grupo.

8. Verificação da aprendizagem

Critério	Evidência esperada	Indício de insuficiência
Justificativa da decisão	Classe de falha interceptada, custo aceito e evidência que refutaria a escolha.	Preferência por familiaridade com a tecnologia ou adesão à alternativa majoritária.
Revisão diante de evidência	Declaração explícita de que a escolha anterior sobrevive ou não ao argumento ouvido e ao dado apresentado, com o motivo.	Manutenção da escolha sem exame do dado, ou troca sem justificativa nova.
Enumeração de exceções	Ao menos duas exceções por categoria, com consequência declarada.	Categorias vazias, ou exceções concentradas em regra de negócio e infraestrutura.
Associação à norma	Cada exceção vinculada a uma característica da ISO/IEC 25010, com registro das características sem correspondência.	Uso da norma como lista decorativa, sem vínculo com as exceções levantadas.
Especificação do requisito	Valor, unidade, condição de medição e limiar declarados.	Atributo enunciado por adjetivo, sem instrumento de medição.
Oráculo	Conjunto de referência versionado ou propriedade invariante asserida.	Comparação literal com uma única resposta esperada.
Cenário em Gherkin	Um `Quando` por cenário, resultado observável em `Então` e vocabulário do domínio.	Cenário que descreve cliques, seletores e chamadas de função.
Nível de teste	Verificação alocada ao nível em que o defeito é isolável.	Toda verificação prevista no nível de sistema.

9. Recursos

Deck de slides do encontro, material de leitura e plano publicados no acervo.
Sala de aprendizagem em equipe do encontro e painel de condução do docente, com token de acesso.
Dispositivo com acesso à internet por participante, para o registro individual das decisões.
Projeção para a exibição do caso, das distribuições e das trajetórias entre rodadas.
Repositório do projeto de cada grupo, com a suíte de testes existente.
Tabela em branco de enumeração de exceções por categoria.
Artigo do Autoestudo 1 e acesso ao capítulo de Pressman pela biblioteca.

10. Riscos e contingências

Indisponibilidade da sala do TBL

O caso e as questões são projetados pelo painel e a decisão é registrada em papel, com contagem manual das distribuições. O percurso de cada questão permanece inalterado.

Turma sem dispositivo ou sem rede

A participação é feita em duplas no mesmo dispositivo, com registro individual da justificativa em papel para a leitura da plenária.

Questões excedendo o tempo previsto

A extensão de prazo é aplicada à discussão da questão em curso, e as questões 4 e 5 podem ser conduzidas sem a segunda decisão, com a síntese logo após a discussão. O bloco de exceções é reduzido à exposição das cinco categorias.

Grupos sem trecho de código selecionado

A enumeração incide sobre o comando de maior consequência do projeto, descrito em prosa, com a identificação do trecho registrada como pendência.

Autoestudos não realizados

A exposição de níveis de teste e de oráculo é conduzida com os exemplos do material, e a leitura é reencaminhada como pendência registrada.

Convergência imediata da turma

Persistindo distribuição concentrada na primeira decisão, a discussão é conduzida com a atribuição da defesa das táticas minoritárias a participantes que não as escolheram.

11. Fechamento

O encontro encerra com as quatro proposições sobre o valor da atitude de qualidade: a decisão de arquitetura defensável declara a evidência que a refutaria; a enumeração por categoria substitui a inspiração pela varredura sistemática; o requisito verificável converte a exceção em compromisso perante o parceiro; e o registro oponível sustenta a contestação quando o sistema operou corretamente e a perda ocorreu. Registram-se, por grupo, as categorias em que a lista de exceções permaneceu vazia, retomadas na verificação dos artefatos da sprint.

12. Referências

HAYASHI, S.; ARAKAKI, R.; RUGGIERO, W. Benchmarking baseado em testes, 2020. Documento do autoestudo.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. Páginas 372 a 387. Código na plataforma da biblioteca: 9786558040118.
Test-Driven Development In Python: the power of red-green-refactor — vídeo do autoestudo. youtube.com/watch?v=B1j6k2j2eJg.
Cucumber — documentação de referência da linguagem Gherkin e das definições de passo.
NORTH, D. Introducing BDD, 2006 — origem da formulação Dado, Quando, Então.
SMART, J. F. BDD in Action — especificação por exemplos e documentação viva.
ISO/IEC 25010 — modelo de qualidade de produto de software.
ISO/IEC/IEEE 29119 — processo, documentação e técnicas de teste de software.
ISO/IEC 27001 e 27002 — registro de eventos e proteção da trilha de auditoria.
BANCO CENTRAL DO BRASIL — Mecanismo Especial de Devolução e limites de valor do PIX.
BRASIL. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais.
MICHAELSEN, L.; SWEET, M. The essential elements of team-based learning, 2008.

Plano de ensino · Testes em aplicações de linguagem natural

Sobre este encontro

Objetivo de aprendizagem

Estratégia do encontro

Estrutura do encontro