PublicouIsabella Alvares Alterado mais de 4 anos atrás
153 Estratégias de teste Capítulo 8 Tópicos de Atuação Profissional
154 Desenvolvedores profissionais testam seus códigos
Testar não é simplesmente uma questão de escrever alguns testes de aceitação ou testes de unidades Fazer isso é algo positivo, porém insuficiente O que toda equipe de profissionais precisa é de uma boa estratégia Tópicos de Atuação Profissional
155 A Garantia de Qualidade (GQ) não deverá encontrar nada
Mesmo que se tenha um grupo separado da GQ para testar o software, a meta da equipe de desenvolvimento deve ser que a GQ não encontre nada errado É improvável que essa meta seja atingida constantemente Quando você tem um grupo unido de pessoas inteligentes, determinadas a encontrar todas as falhas e deficiências do produto, é quase certo que ele conseguirá Toda vez que a equipe da GQ encontrar algo, o pessoal do desenvolvimento deve reagir com horror É preciso que eles se perguntem como aquilo aconteceu e tomem ações para evitar que se repita no futuro Tópicos de Atuação Profissional
156 GQ faz parte da equipe A melhor forma de a GQ trabalhar como parte da equipe é agir como especificadores e caracterizadores GQ como especificadores Deve ser papel da GQ trabalhar com o pessoal de negócios, a fim de criar testes de aceitação automatizados que se tornem os verdadeiros documentos de especificação e requerimentos para o sistema GQ como caracterizadores O outro papel da GQ é usar a disciplina de testes exploratórios para caracterizar o verdadeiro comportamento dos sistemas e reportar esse comportamento para os desenvolvedores e a empresa Tópicos de Atuação Profissional
157 A pirâmide de testes de automação
Por melhor que seja ter um conjunto de testes de aceitação e testes de unidades, também precisamos de testes com um nível mais alto para assegurar que a GQ não encontrará nada A pirâmide de automação de teste é uma descrição gráfica dos tipos de testes que uma organização de desenvolvimento profissional precisa Tópicos de Atuação Profissional
158 Testes exploratórios manuais
~5% Testes exploratórios manuais Testes de sistema ~10% GUI Testes de integração ~25% API Testes de componentes ~50% API Testes de unidades ~100% XUnit Tópicos de Atuação Profissional
159 Testes de unidades Na parte mais baixa de pirâmide estão os testes de unidades Eles são escritos por programadores para programadores, na linguagem de programação do sistema A intenção desses testes é especificar o sistema em seu nível mais baixo Executados como uma parte da IC, a fim de garantir que a intenção dos programadores seja atingida Esses testes dão uma cobertura tão próxima a 100% quanto possível Em geral, esse número deve ser superior a 90% Deve ser uma cobertura verdadeira, em oposição aos testes falsos, que executam códigos sem afirmarem seu comportamento Tópicos de Atuação Profissional
160 Testes de componentes São escritos em oposição aos componentes individuais do sistema Os componentes do sistema encapsulam as regras da empresa Os testes para aqueles componentes são os testes de aceitação para aquelas regras Um teste de componente envolve um componente Ele passa os dados de entrada para o componente e reúne os dados de saída Ele atesta que a saída combina com a entrada Qualquer outro componente do sistema é dissociado do teste, utilizando simulações apropriadas e técnicas duplas de testes Tópicos de Atuação Profissional
161 Componente Teste de aceitação Tópicos de Atuação Profissional
162 Testes de componentes cobrem, grosseiramente, metade do sistema
Testes de componentes são escritos pela GQ com ajuda do desenvolvimento A intenção é que o pessoal de negócios seja capaz de ler e interpretar esses testes, e até criá-los Testes de componentes cobrem, grosseiramente, metade do sistema Eles são mais direcionados a situações de caminho feliz e casos bastante óbvios, como cantos, fronteiras e caminhos alternativos A grande maioria de casos de caminhos infelizes é coberta pelos testes de unidades e são insignificantes no nível em que os testes de componentes operam Tópicos de Atuação Profissional
163 Testes de integração Estes testes só fazem sentido para sistemas maiores que têm muitos componentes Eles montam grupos de componentes e testam a comunicação uns com os outros Os outros componentes do sistema são dissociados como sempre, com simulações e testes de duplas apropriadas Testes de integração são coreografados Eles não testam as regras da empresa Testam o quão bem a composição dos componentes funciona junta São testes de encanamento que garantem que os componentes estejam apropriadamente conectados e possam se comunicar com clareza entre si Tópicos de Atuação Profissional
164 Teste de integração Componente Componente Componente Componente
165 São escritos na mesma linguagem e ambiente que testes de componentes
Testes de integração são tipicamente escritos por arquitetos de sistemas ou designers principais do sistema Garante que a estrutura arquitetônica do sistema seja sólida Permite testar o desempenho e a taxa de transferência São escritos na mesma linguagem e ambiente que testes de componentes Eles não costumam ser executados como partes do conjunto de IC por possuírem tempos de execução mais longos São executados periodicamente (diariamente, semanalmente etc.), conforme seus autores julgarem necessário Tópicos de Atuação Profissional
166 Testes de sistema Testes automatizados executados em oposição ao sistema integrado completo São testes de integração definitivos Não testam as regras da empresa diretamente Testam que o sistema tenha sido cabeado corretamente, e que suas partes estejam interoperando conforme o planejado Espera-se ver testes de desempenho e taxa de transferência nesse grupo Tópicos de Atuação Profissional
167 Testes de sistemas cobrem por volta de 10% do sistema
Esses testes são escritos pelos mesmos arquitetos de sistema e principais técnicos Costumam ser feitos na mesma linguagem e ambiente que os testes de integração para a UI (interface de usuário) São executados com menos frequência, dependendo da duração, porém quanto mais frequentes, melhor Testes de sistemas cobrem por volta de 10% do sistema A sua intenção não é garantir o comportamento correto do sistema, mas sim sua construção correta O comportamento correto do código subjacente e dos componentes já foi estabelecido pelas camadas inferiores da pirâmide Tópicos de Atuação Profissional
168 Testes exploratórios manuais
É onde as pessoas colocam as mãos nos teclados e os olhos na tela Esses testes não são automatizados, muito menos escritos Tem como intenção explorar o sistema em busca de comportamentos inesperados, ao mesmo tempo em que comportamentos esperados são confirmados Precisamos de cérebros criativos para investigar e explorar o sistema Criar um plano de teste escrito para esse tipo de teste acabaria com seu propósito Tópicos de Atuação Profissional
169 Algumas equipes têm especialistas para esse trabalho
Outras, simplesmente declaram um dia ou dois de "caça aos bugs", nos quais o máximo de pessoas possível, incluindo gerentes, secretários, programadores, testadores e programadores de tecnologia, testam o sistema para ver se conseguem fazer com que ele trave A meta não é cobertura Não queremos comprovar cada regra da empresa e cada caminho de execução com esses testes Desejamos garantir que o sistema se comporte bem sob operação humana, e encontrar criativamente tantas "peculiaridades" quanto possível Tópicos de Atuação Profissional
170 Conclusão TDD é uma disciplina poderosa e testes de aceitação são formas valiosas de expressar e reforçar seus requerimentos Mas eles são apenas parte da estratégia completa Para atingir a meta de que "a GQ não poderá encontrar nada", as equipes do desenvolvimento precisam trabalhar lado a lado com a GQ a fim de criar uma hierarquia de testes de unidades, componentes, integração, sistema e testes exploratórios Esses testes devem ser rodados com o máximo de frequência possível para dar feedback e garantir que o sistema permaneça continuamente limpo Tópicos de Atuação Profissional