DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Este é um post disponível para assinantes MVP
###
Engenharia de Software 48 - Índice

Teste de software baseado em risco - Revista Engenharia de Software Magazine 48

Neste artigo conheceremos a abordagem de teste baseado em riscos e as técnicas utilizadas no decorrer de suas atividades que favorecem a identificação de fatores de risco associados aos requisitos do software.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo
A atividade de teste tem como objetivo encontrar defeitos, reduzir os riscos associados a um sistema e identificar o máximo de problemas, efetivando a qualidade dos produtos desenvolvidos.

Uma vez que não é rentável testar exaustivamente, além da disponibilidade de tempo, os testes sofrem análise para sua seleção e execução. Umas das bases para essa análise é a visão do coordenador de teste e da equipe de teste quanto à execução e continuidade das atividades de testes. Em alguns casos, também é realizada uma reunião com a equipe do projeto para avaliar o nível de cobertura de teste para determinada funcionalidade, o impacto de defeitos na entrega, gargalos e a qualidade das linhas de base (baseline). Na informalidade, a equipe começa a discutir sobre o ponto de equilíbrio entre o custo do teste e o custo da falha para o negócio.

A técnica de teste baseada em riscos (Risk-basedTesting – RBT) é uma abordagem que minimiza a dificuldade de se priorizar teste e o esforço de teste. A sua execução favorece a identificação, análise e mitigação de fatores de riscos associados aos requisitos do produto de software, além de estimular a proposta de elaboração do plano de teste e caso de teste.

Dentro deste contexto, este artigo apresentará algumas técnicas sobre identificação de defeitos e o teste baseado em risco através das características e subcaracterísticas de qualidade.


Gerenciamento de risco em teste de software
A ausência de uma metodologia de teste e/ou melhoria nos processos de desenvolvimento de software nas organizações tende costumeiramente a tratar a atividade de teste como uma das etapas finais do desenvolvimento de software, sendo esta prática um fator de risco, pois o produto já se encontra “pronto”, acarretando em testes superficiais.

O envolvimento de todos no projeto é fundamental para a realização das avaliações e magnitude do risco. Estudos realizados demonstram que o esforço desprendido na atividade de teste é de 30% a 40% do esforço global do projeto. Embora o teste seja uma forma de mitigação do risco, é necessária uma estratégia de teste que incorpore: os estágios ou níveis a serem abordados (unidade, integração, sistema e aceitação); a fase do ciclo de vida de desenvolvimento em que se aplica determinado teste; e as técnicas de teste, ou seja, como testar (Estrutural e Funcional).

A atividade de teste de software está bastante relacionada ao risco. Quando um analista de teste não planeja a execução de um teste, ou não testa uma parte do sistema, a probabilidade do risco ocorrer é alta. A falta da avaliação do seu impacto compromete as novas etapas do projeto e pode ocasionar outros fatores de risco, tais como: financeiro, humano e recurso.

O teste orientado ao risco auxilia a disponibilização de recursos, prioriza a parte mais crítica do sistema, contribui com a análise de estratégia de teste e práticas de gestão de risco na área de teste, visando à maximização do sucesso do desenvolvimento do produto.
Enquanto não familiarizados com a técnica, podemos nos esbarrar em dúvidas sobre alguns itens como:
• Falta de definição precisa dos riscos (textos ou palavras com dupla interpretação);
• Subjetividade na avaliação do impacto de risco (ausência ou incompletude da causa e impacto);
• Riscos dinâmicos, ocorrendo em diferentes fases do ciclo de vida do projeto.

Para orientar a execução da abordagem de teste baseado em risco são identificadas três atividades distintas:
• Elaborar uma lista de riscos priorizada: Consiste na identificação e análise dos riscos técnicos associados aos requisitos do software;
• Realizar testes que explorem cada risco: Consiste na criação e/ou execução de testes que verificam a existência ou não do risco identificado;
• Acompanhar e controlar os riscos: Assim que um risco for eliminado, um novo risco surge e os esforços de testes devem ser realocados, focando nos riscos mais importantes.


Identificar o risco
O processo de identificação de risco permite aos projetos de desenvolvimento de software a exposição das incertezas que podem ocorrer durante o teste. Para isto, exige um bom conhecimento dos requisitos, perspectivas de negócios do usuário e da interação entre aplicação/interfaces e o ambiente de implantação.
Para identificar o risco com as possibilidades de testes, Bach (1999) orienta o uso de algumas técnicas: de dentro para fora (Inside-Out), de fora para dentro (Outside-in), lista genérica de risco e o questionário baseado em taxonomia de riscos (Taxonomy Based questionnaire –TBQ).

Na primeira abordagem, de dentro para fora (Inside-Out), a estratégia utilizada é realizar repetidamente a pergunta: o que poderia dar errado aqui? O objetivo é considerar quais eventos cuja ocorrência poderá acarretar em perdas, baseando-se nas seguintes perdas:
• Vulnerabilidade: Quais fraquezas ou possíveis falhas existentes neste componente?
• Ameaça: Que entradas ou situações poderiam existir que podem explorar uma vulnerabilidade e disparar uma falha neste componente?
• Vítimas: Quem ou o quê poderia ser impactado por uma possível falha e quão ruim isto seria?

Na segunda técnica, de fora para dentro (Outside-in), os riscos são explorados a partir de listas baseadas nos modelos de qualidade: NBR ISO/IEC 9126, Hewlett Packard – FURPS (Functionality, Usability, Reliability, Performance, Supportability) e outras fontes. Para cada atributo de qualidade da lista abaixo é feito a seguinte pergunta: O que aconteceria se os requisitos associados a este atributo não for cumprido?
• Capacitação: Ele pode desempenhar as funções necessárias?
• Confiabilidade: Será que vai funcionar bem e resistir aos defeitos em todas as situações exigidas?
"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



Atua no ramo de teste de software há 3 anos. É Bacharel em Sistemas de Informação, cursa MBA em Gestão da Tecnologia é Certificada CSTE – Certified Software Tester pela QAI e CBTS Certificação Brasileira de Teste de Software. Pres [...]

O que você achou deste post?
Serviços

Mais posts