Técnicas de Teste Estáticas

As técnicas de análise estáticas são formas de testar software onde o código desenvolvido não é executado. Este tipo de testes deve ser utilizado pelas equipas de trabalho com o objectivo identificar falhas na documentação associada a um projecto. Estes princípios podem, e devem, ser utilizados para melhorar a qualidade dos requisitos, a documentação associada a um produto, os planos de testes elaborados, assim como qualquer outro tipo de documentação num projecto. As técnicas estáticas também são usadas para efectuar verificações sintácticas no código. Esta análise é já na maioria dos casos, feitas pelos compiladores. Com certeza já toda a gente encontrou situações do género:

“Warning    1    The field 'xpty' is assigned but its value is never used”

Este exemplo é apenas um das muitas verificações possíveis de ser feita.

Processos de Revisão

Desde há algum tempo atrás que se começa a aceitar que testar o software é uma parte importante da construção de um sistema. Mas se o software criado for baseado em requisitos imprecisos, a seguir mesmo que o código criado seja muito bem escrito, o software resultante estará incorrecto e será insatisfatório. Existem inúmeras notícias sobre falhas gravas de software, mas o que muitas vezes estas histórias não contam é que a maioria dos defeitos podem ser rastreados até à definição do requisitos. Também já de algum tempo a esta parte que a atenção dada aos testes têm aumentado, assim como a qualidade dos mesmos. Mas maioritariamente estes testes são efectuados sobre o software produzido, i.e. após se terem cometidos os erros. È muito mais vantajoso que consigamos detectar os erros cometidos o mais cedo possível no ciclo de vida do desenvolvimento, pois os custos de correcção serão muito inferiores ao que seriam se fossem encontrados numa fase posterior, ou mesmo depois de o software entrar em funcionamento no cliente. Neste caso não são apenas os custos de correcção que são elevados, mas também a imagem da empresa que fica afectada. Assim faz todo o sentido começarmos a testar e validar as exigências do software antes mesmo de as construir.

A criação/edição de requisitos é um processo que é muitas vezes visto como uma “acção única”,porque na maioria das vezes os requisitos não são reavaliados ao longo das diferentes fases de desenvolvimento. Porém este é um processo que deve ser iterativo, de modo a que uma melhoria continua seja adquirida. As vantagens do uso de processo iterativo podem ser obtidos com a realização de revisões.

Com a realização de revisões a requisitos, ou outro tipo de documentação podemos obter, entre outros, os seguintes benefícios:

• Detecção e correcção de defeitos numa fase inicial do projecto.
• Melhorias na produtividade do desenvolvimento.
• Redução do tempo de desenvolvimento.
• Redução do tempo necessário para testes, assim como redução de custos.
• Menor conjunto de defeitos.
• Melhorias na comunicação.

Claro que nem tudo são benefícios e geralmente efectuar revisões fica caro, pelo que deve ser sempre analisada quais os potenciais benefícios das mesmas.

De seguida apresentam-se as fases essenciais de um processo de revisão formal.

Fases de um processo de revisão formal

• Planeamento – Nesta fase deve ser feita a selecção dos pessoal, a alocação das tarefas a cada uma das pessoas envolvidas. Deve também ser efectuada a definição de critérios de entrada e saída.
• Kick-off – Nesta fase é feita a distribuição de documentos, são explicados os objectivos aos intervenientes e é verificado se o critério de entrada já está comprido.
• Preparação individual – Esta fase corresponde ao trabalho efectuado por cada uma das pessoas envolvidas, com o objecto de compreender o trabalho e os pré-requisitos necessários. Devem ser levantadas todas as dúvidas encontradas e feitos os comentários adequados nesta fase.
• Reunião de revisão – Nesta fase é efectuada uma reunião com as pessoas envolvidas de modo a se discutir o assunto em questão. Nesta fase fazem-se recomendações e apresentam-se soluções para os problemas em causa. São também tomadas decisões sobre como resolver os problemas encontrados.
• Correcções – Nesta fase são corrigidos os problemas encontrados, sendo geralmente essa correcção atribuída ao autor.
• Continuidade – Nesta fase é efectuada a verificação se os problemas encontradas estão a ser resolvidos, e se estes estão devidamente escalonados entre o grupo de trabalho. Vai sendo verificado se o critério de saída já está a ser comprido de modo a dar como finalizado o trabalho.

Para a realização da sequência de actividades acima descrita, geralmente, entram em acção os seguintes intervenientes.

• Gestor – Decide o que deve ser alvo de um processo de revisão, efectua a alocação do tempo nos vários projectos destinado ao processo de revisão e determina quando é que os objectivos da revisão estão compridos.
• Moderador – Tem a responsabilidade de conduzir a reunião, definir o seu planeamento e definir a continuação de trabalhos após a mesma.
• Autor - O escritor ou a pessoa directamente responsável pelos textos originais que irão ser alvo de revisão. É geralmente o elemento responsável pela correcção dos problemas levantados durante a reunião de revisão.
• Revisores – Conjunto de elementos que efectuam a avaliação dos documentos em análise e reportam os problemas encontrados.

Para efectuar uma processo de revisão não são efectivamente necessários os quatro intervenientes referidos acima. Em projectos de média e pequena dimensão alguns dos intervenientes acumulam mais de que um cargo. Embora não seja recomendável que um destes processo de revisão tenha menos de três pessoas envolvidas, duas no casos de revisões informais.

Tipos de Revisões

Cada projecto é diferente dos restantes, existem pequenos projectos, grandes projectos, projectos críticos, entre outros. Todos eles podem ser alvo de uma revisão estática, mas o grau de formalismo usado deverá depender sempre da importância e dimensão do projecto.

• Revisão Informal – Este tipo de revisão não possui nenhum processo formal associado. È visto como um modo, relativamente, barato de obter algum benefício. Este processo pode ser tão simples como ter duas pessoas a discutir um documento numa conversa telefónica, ou enquanto se toma um café.
• Walk-throughs - Walk-throughs é definido por um conjunto de revisões onde o autor da documentação é o moderador. Aqui o autor conduz a revisão e nestas revisão, os elementos revisores examinam secção a secção a partir dos itens em análise.
• Revisão Técnica – Uma actividade de discussão em grupo de modo a se conseguir obter um consenso sobre  uma abordagem técnica a ser tomada.
• Inspecção – São tipo de revisões mais formais, lideradas por um moderador com formação especializada, e sempre diferente do autor. Todos os passos efectuados aqui possuem um nível de formalismo bastante elevado.

As revisões formais são usadas principalmente na análise dos requisitos. Aqui a tentativa de definir uma medida de qualidade a atribuir a um requisito ajuda a clarificar requisitos mais obscuros. Possíveis soluções consistem em substituir um requisito vago, por um conjunto de requisitos mais específicos. Para todos os requisitos escritos deveria-se verificar que os seguintes atributos são compridos.

• Correcção – A correcção de um requisito é a avaliação do mesmo com base no que é pretendido pelo utilizador. Por exemplo, deve-se verificar que as regras e regulamentos existentes são indicados correctamente.
• Completude – A completude garante que não existem elementos elementos essenciais a percepção do requisito fora do mesmo. O objectivo é evitar a omissão nos requisitos, simplesmente porque ninguém tem as perguntas certas ou examinou pontos fortes. È sempre boa prática associar requisitos não funcionais como performance, segurança, acessibilidade entre outros aos requisitos funcionais que vão sendo criados.
• Coerência – A coerência verifica que não há contradições internas ou externas entre os elementos definidos no conjunto de requisitos a trabalhar. Aqui verifica-se que cada termo usado na elaboração do requisito está claramente definido e que não existem ambiguidades no uso de um termo, pois se estas existirem vão levar, quase certamente, a interpretações diferentes pelos elementos de uma equipa de trabalho.
• Testabilidade – A testabilidade confirma a possibilidade de criar um testes para criar um teste para um requisito, e que o resultado esperado é conhecido e pode ser verificado  programaticamente ou por meio de visualização directa.
• Viabilidade – A viabilidade de um requisito garante que este pode ser comprido tendo em conta o orçamento existente, o roadmap, as tecnologia conhecidas e outros recursos disponíveis.
• Necessidade – A necessidade permite verificar se todos os requisitos da especificação são relevante para o sistema a construir, e se não estamos apenas a adicionar funcionalidades por adicionar, sem que estas tragam mais valias para o. Para testar a relevância ou a necessidade, o testador verifica o requisito contra as metas estabelecidas para o sistema. Será que este requisito de contribuir para esses objectivos? Será que sem este requisito impedir que o sistema a consecução desses objectivos? Quaisquer outros requisitos dependentes deste requisito? Alguns requisitos irrelevantes não são realmente requisitos, mas as soluções propostas.
• Rastreabilidade – A rastreabilidade garante que para cada requisito é identificado, de tal forma a que possa ser associado a todas as partes do sistema onde irá usado. De modo a que para qualquer alteração aos requisitos, esta seja fácil de detectar por todas as partes onde a mudança realizada têm impacto.

Bom, até à próxima.