Teste Estático

Ao contrário dos testes dinâmicos, nos testes estáticos o software em teste não precisa ser executado. O código, a especificação do processo, a especificação da arquitetura do sistema ou outros produtos de trabalho são avaliados por meio de exame manual (p. ex., revisões) ou com a ajuda de uma ferramenta (p. ex., análise estática). Os objetivos do teste incluem a melhoria da qualidade, a detecção de defeitos e a avaliação de características como legibilidade, integridade, correção, testabilidade e consistência. O teste estático pode ser aplicado tanto para verificação quanto para validação. Testadores, representantes do negócio e desenvolvedores trabalham juntos durante o mapeamento de exemplos, escrita colaborativa de histórias de usuários e sessões de refinamento do backlog para garantir que as histórias de usuários e os produtos de trabalho relacionados atendam aos critérios definidos, por exemplo, a Definição de Pronto (DoR - Definition of Ready) (ver seção 5.1.3). Técnicas de revisão podem ser aplicadas para garantir que as histórias de usuários sejam completas e compreensíveis e incluam critérios de aceite testáveis. Ao fazer as perguntas certas, os Testadores exploram, desafiam e ajudam a melhorar as histórias de usuário propostas. A análise estática pode identificar problemas antes dos testes dinâmicos e, muitas vezes, exige menos esforço, já que não são necessários casos de teste e, normalmente, são usadas ferramentas (ver capítulo 6). A análise estática é frequentemente incorporada às estruturas de CI (ver seção 2.1.4). Embora seja amplamente usada para detectar defeitos específicos no código, a análise estática também é usada para avaliar a capacidade de manutenção e a segurança. Verificadores ortográficos e ferramentas de legibilidade são outros exemplos de ferramentas de análise estática.

3.1.1 Produtos de trabalho examináveis por testes estáticos

Quase todos os produtos de trabalho podem ser examinados por meio de testes estáticos. Os exemplos incluem documentos de especificação de requisitos, código-fonte, planos de teste, casos de teste, itens da lista de pendências do produto, cartas de teste, documentação do projeto, contratos e modelos. Qualquer produto de trabalho que possa ser lido e compreendido pode ser objeto de uma revisão. No entanto, para a análise estática, os produtos de trabalho precisam de uma estrutura em relação à qual possam ser verificados (p. ex., modelos, código ou texto com uma sintaxe formal). Os produtos de trabalho que não são apropriados para testes estáticos incluem aqueles que são difíceis de serem interpretados por seres humanos e que não podem ser analisados nem por ferramentas (p. ex., código executável de terceiros por motivos legais).

3.1.2 Valor do teste estático

O teste estático pode detectar defeitos nas primeiras fases do SDLC, cumprindo o princípio do teste antecipado (ver seção 1.3). Ele também pode identificar defeitos que não podem ser detectados por testes dinâmicos (p. ex., código inacessível, padrões de projeto não implementados conforme desejado, defeitos em produtos de trabalho não executáveis). Os testes estáticos permitem avaliar a qualidade e criar confiança nos produtos de trabalho. Ao verificar os requisitos documentados, os stakeholders também podem se certificar de que esses requisitos descrevem suas necessidades reais. Como os testes estáticos podem ser realizados no início do SDLC, é possível criar um entendimento compartilhado entre os stakeholders envolvidos. A comunicação entre os stakeholders também será aprimorada. Por esse motivo, é recomendável envolver uma grande variedade de participantes nos testes estáticos. Embora a implementação das revisões possa ser dispendiosa, os custos gerais do projeto geralmente são muito menores do que quando não são realizadas revisões, pois é necessário gastar menos tempo e esforço para corrigir defeitos posteriormente no projeto. Os defeitos de código podem ser detectados usando a análise estática de forma mais eficiente do que em testes dinâmicos, geralmente resultando em menos defeitos de código e em um menor esforço geral de desenvolvimento.

3.1.3 Diferenças entre testes estáticos e testes dinâmicos

As práticas de teste estático e de teste dinâmico se complementam. Elas têm objetivos semelhantes, como apoiar a detecção de defeitos em produtos de trabalho (ver seção 1.1.1), mas também existem algumas diferenças, como:

●Os testes estáticos e dinâmicos (com análise de falhas) podem levar à detecção de defeitos, mas há alguns tipos de defeitos que só podem ser encontrados por meio de testes estáticos ou dinâmicos;

●Os testes estáticos encontram defeitos diretamente, enquanto os testes dinâmicos causam falhas a partir das quais os defeitos associados são determinados por meio de análises subsequentes;

●Os testes estáticos podem detectar com mais facilidade os defeitos que se encontram nos caminhos do código que raramente são executados ou que são difíceis de alcançar usando testes dinâmicos;

●O teste estático pode ser aplicado a produtos de trabalho não executáveis, enquanto o teste dinâmico só pode ser aplicado a produtos de trabalho executáveis;

●Os testes estáticos podem ser usados para medir as características de qualidade que não dependem da execução do código (p. ex., capacidade de manutenção), enquanto os testes dinâmicos podem ser usados para medir as características de qualidade que dependem da execução do código (p. ex., eficiência de performance).

Os defeitos típicos que são mais fáceis e/ou mais baratos de encontrar por meio de testes estáticos incluem:

●Defeitos nos requisitos (p. ex., inconsistências, ambiguidades, contradições, omissões, imprecisões, duplicações)

●Defeitos de projeto (p. ex., estruturas de banco de dados ineficientes, modularização deficiente)

●Certos tipos de defeitos de codificação (p. ex., variáveis com valores indefinidos, variáveis não declaradas, código inacessível ou duplicado, complexidade excessiva do código)

●Desvios dos padrões (p. ex., falta de adesão às convenções de nomenclatura nos padrões de codificação)

●Especificações incorretas da interface (p. ex., número, tipo ou ordem de parâmetros incompatíveis)

●Tipos específicos de vulnerabilidades de segurança (p. ex., estouro de buffer)

●Lacunas ou imprecisões na cobertura da base de testes (p. ex., testes ausentes para um critério de aceite)

3.2.1 Benefícios do feedback antecipado e frequente dos stakeholders

O feedback antecipado e frequente permite a comunicação precoce de possíveis problemas de qualidade. Se houver pouco envolvimento dos stakeholders durante o SDLC, o produto que está sendo desenvolvido pode não atender à visão original ou atual dos stakeholders. A incapacidade de entregar o que o stakeholder deseja pode resultar em retrabalho dispendioso, perda de prazos, jogos de culpa e até mesmo levar ao fracasso total do projeto. O feedback frequente dos stakeholders durante todo o SDLC pode evitar mal-entendidos sobre os requisitos e garantir que as alterações nos requisitos sejam compreendidas e implementadas mais cedo. Isso ajuda a equipe de desenvolvimento a melhorar a compreensão do que está sendo desenvolvido. Isso permite que a equipe se concentre nos recursos que agregam mais valor aos stakeholders e que têm o maior impacto positivo sobre os riscos identificados.

3.2.2 Atividades do processo de revisão

A norma ISO/IEC 20246 define um processo de revisão genérico que fornece um framework estruturado, porém flexível, a partir da qual um processo específico de revisão pode ser adaptado a uma situação particular. Se a revisão exigida for mais formal, serão necessárias mais tarefas descritas para as diferentes atividades.

O tamanho de muitos produtos de trabalho os torna grandes demais para serem cobertos por uma única revisão. O processo de revisão pode ser invocado algumas vezes para concluir a revisão de todo o produto de trabalho. As atividades no processo de revisão são:

●Planejamento. Durante a fase de planejamento, deve ser definido o escopo da revisão, que inclui o objetivo, o produto de trabalho a ser revisado, as características de qualidade a serem avaliadas, as áreas a serem enfocadas, os critérios de saída, as informações de apoio, como padrões, o esforço e os prazos para a revisão.

●Início da revisão. Durante o início da revisão, o objetivo é garantir que todos os envolvidos estejam preparados para começar a revisão. Isso inclui garantir que todos os participantes tenham acesso ao produto de trabalho, entendam suas funções e responsabilidades e recebam tudo o que for necessário para realizar a análise.

●Revisão individual. Cada revisor realiza uma revisão individual para avaliar a qualidade do produto de trabalho sob revisão e para identificar anomalias, recomendações e perguntas, aplicando uma ou mais técnicas de revisão (p. ex., revisão baseada em lista de verificação, revisão baseada em cenário). A norma ISO/IEC 20246 fornece mais detalhes sobre as diferentes técnicas de revisão. Os revisores registram todas as anomalias, recomendações e perguntas identificadas.

●Comunicação e Análise de Problemas. Como as anomalias identificadas durante uma revisão não são necessariamente defeitos, todas essas anomalias precisam ser analisadas e discutidas. Para cada uma encontrada, deve ser tomada uma decisão sobre seu status, propriedade e ações necessárias.

Normalmente, isso é feito em uma reunião de revisão, durante a qual os participantes também decidem qual é o nível de qualidade do produto de trabalho revisado e quais ações de acompanhamento são necessárias. Pode ser necessária uma revisão de acompanhamento para concluir as ações.

●Correção e Relatório. Para cada defeito, deve ser criado um relatório de defeitos para que as ações corretivas possam ser acompanhadas. Quando os critérios de saída forem atingidos, o produto de trabalho poderá ser aceito. Os resultados da revisão são relatados.

3.2.3 Funções e responsabilidades nas revisões

As revisões envolvem vários stakeholders, que podem assumir diversas funções. As principais, e suas responsabilidades são:

●Gerente: decide o que deve ser revisado e fornece recursos, como equipe e tempo para a revisão

●Autor: cria e corrige o produto de trabalho em análise

●Moderador (também conhecido como facilitador): garante o andamento eficaz das reuniões de revisão, incluindo mediação, gerenciamento de tempo e um ambiente de revisão seguro no qual todos possam falar livremente

●Relator (também conhecido como registrador): reúne as anomalias dos revisores e registra as informações da revisão, como decisões e novas anomalias encontradas durante a reunião de revisão

●Revisor: realiza revisões. Um revisor pode ser alguém que esteja trabalhando no projeto, um especialista no assunto ou qualquer outra parte interessada

●Líder da revisão: assume a responsabilidade geral pela revisão, como decidir quem estará envolvido e organizar quando e onde a revisão será realizada

Outras funções mais detalhadas são possíveis, conforme descrito na norma ISO/IEC 20246.

3.2.4 Tipos de revisão

Existem muitos tipos de revisão, desde revisões informais até revisões formais. O nível necessário de formalidade depende de fatores como o SDLC que está sendo seguido, a maturidade do processo de desenvolvimento, a importância e a complexidade do produto de trabalho que está sendo revisado, os requisitos legais ou regulamentares e a necessidade de uma trilha de auditoria. O mesmo produto de trabalho pode ser revisado com diferentes tipos de revisão, por exemplo, primeiro uma informal e depois uma mais formal.

A seleção do tipo certo de revisão é fundamental para atingir os objetivos de revisão exigidos (ver seção 3.2.5). A seleção não se baseia apenas nos objetivos, mas também em fatores como as necessidades do projeto, os recursos disponíveis, o tipo e os riscos do produto de trabalho, o domínio do negócio e a cultura da empresa. Alguns tipos de revisão comumente usados são:

●Revisão informal. As revisões informais não seguem um processo definido e não exigem um resultado formal documentado. O principal objetivo é detectar anomalias.

●Walkthrough. Um passo a passo, conduzido pelo autor, pode servir a muitos objetivos, como avaliar a qualidade e criar confiança no produto do trabalho, instruir os revisores, obter consenso, gerar novas ideias, motivar e permitir que os autores melhorem e detectar anomalias. Os revisores podem realizar uma revisão individual antes do passo a passo, mas isso não é obrigatório.

●Revisão técnica. Uma revisão técnica é realizada por revisores tecnicamente qualificados e liderada por um moderador. Os objetivos de uma revisão técnica são obter consenso e tomar decisões em relação a um problema técnico, mas também detectar anomalias, avaliar a qualidade e criar confiança no produto do trabalho, gerar novas ideias e motivar e capacitar os autores a melhorar.

●Inspeção. Como as inspeções são o tipo mais formal de revisão, elas seguem o processo genérico completo (ver seção 3.2.2). O objetivo principal é encontrar o número máximo de anomalias. Outros objetivos são avaliar a qualidade, criar confiança no produto do trabalho e motivar e permitir que os autores melhorem. As métricas são coletadas e usadas para aprimorar o SDLC, inclusive o processo de inspeção. Nas inspeções, o autor não pode atuar como líder ou relator da revisão.

3.2.5 Fatores de sucesso para revisões

Há vários fatores que determinam o sucesso das revisões, que incluem:

●Definir objetivos claros e critérios de saída mensuráveis. A avaliação dos participantes nunca deve ser um objetivo;

●Escolher o tipo de revisão apropriado para atingir os objetivos determinados e se adequar ao tipo de produto de trabalho, aos participantes da revisão, às necessidades e ao contexto do projeto;

●Realizar revisões em pequenas partes, de modo que os revisores não percam a concentração durante uma revisão individual e/ou a reunião de revisão (quando realizada);

●Fornecer feedback das revisões aos stakeholders e aos autores para que eles possam melhorar o produto e suas atividades (ver seção 3.2.1);

●Fornecer tempo suficiente para que os participantes se preparem para a revisão;

●Apoio da gerência para o processo de revisão;

●Tornar as revisões parte da cultura da organização, para promover o aprendizado e o aprimoramento dos processos;

●Fornecer treinamento adequado a todos os participantes para que eles saibam como desempenhar suas funções;

●Facilitação de reuniões;