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
Este post também está disponível para assinantes da Engenharia de Software Magazine
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

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?
Publicidade
Serviços

Mais posts