TMap Test Management Approach - Framework e Importância do Teste Parte 2

Atualmente existem muitas definições sobre o que é teste de software. No entanto, a maioria delas centraliza na comparação do objeto de teste em relação a algum tipo de padrão(ex: expectativas, correta operação, requisitos).

por Fábio Martinho Campos

Atualmente existem muitas definições sobre o que é teste de software. No entanto, a maioria delas centraliza na comparação do objeto de teste em relação a algum tipo de padrão(ex: expectativas, correta operação, requisitos).

Com isso, é importante saber exatamente o que você irá testar(o objeto de teste – test object), em relação com o que você irá comparar(base para os testes, ex: documentações – test basis) e como você irá testar(os métodos e técnicas).

Cada instituição, entretanto, apresenta a sua definição especifica de teste de software. Vamos conhecer algumas destas definições:

- QAI(Quality Assurance Institute): Teste é uma atividade de controle da qualidade, que por sua vez, é o processo pelo qual a qualidade do produto é comparada com padrões aplicáveis, e a ação tomada quando não-conformidades são encontradas. (...) Ainda, atividades de controle da qualidade focam na identificação de defeitos nos produtos produzidos. (CSTE CBOK – Common Body Of Knowledge , 2006; v6.2)

-ISO/IEC(International Organization for Standardization/International Electrotechnical Commission): Teste é a operação técnica que consiste na determinação de uma ou mais características de um dado produto, processo ou serviço de acordo com um procedimento especificado. (extraído do livro TMap Next for result-driven testing, 1991; p. 35)

- IEEE(Institute of Electrical and Electronics Engineers): Uma atividade na qual um sistema ou componente é executado sob condições especificadas, os resultados são observados ou gravados, e uma avaliação é feita sobre algum aspecto do sistema ou componente. (IEEE 610.12 - Standard Glossary of Software Engineering Terminology, 1990)

- ISTQB(International Software Testing Qualifications Board): Processo que consiste em todas as atividades do ciclo de vida, tanto estáticas quanto dinâmicas, voltadas para o planejamento, preparação e avaliação de produtos de software e produtos de trabalhos relacionados a fim de determinar se elas satisfazem os requisitos especificados e demonstrar que estão apenas aptas para a sua finalidade e para a detecção de defeitos. (Glossário Padrão de Termos Utilizados em Teste de Software, 2010; v2.1)

- ALATS(Associação Latino-Americana de Teste de Software): O objetivo principal do processo de testes é simplesmente encontrar o maior número de defeitos. (Base de conhecimento em teste de software, 2007)

Nota: Vale à pena ressaltar que não existem definições erradas ou totalmente corretas. Cada instituição possui a sua ideologia e visão própria do teste de software. O objetivo aqui é apenas mostrar os diferentes conceitos entre estas instituições.

Pode-se notar por sua vez que todas as definições acima apresentadas convergem para o conceito de comparar o produto com padrões(documentações).

O teste fornece, assim, uma visão na diferença entre o atual e o requerido status de um objeto de teste, sendo que o teste é um dos meios de detecção de defeitos dentro de um programa de controle de qualidade. Adicionalmente, existem outras formas e meios bem como técnicas de detecção de defeitos.

O teste está relacionado com revisão, simulação, inspeção, auditoria, desk-checking, walkthrough, etc.

Os vários instrumentos de detecção estão espalhados nos grupos de Avaliação(Evaluation) e Teste(Testing):

- Evaluation: Avaliação dos produtos de trabalho/artefatos de projetos(Ex: requisitos, documentos de arquitetura, casos de teste, planos, etc.) produzidos durante o ciclo de vida de desenvolvimento de software.

- Testing: avaliação de produtos finalizados.

O nível da qualidade do produto está relacionado com os riscos que a organização desejar aceitar quando o produto é colocado em produção. Portanto, a definição de teste para o TMap Next é:

“O teste é um processo que fornece visão e conselhos sobre a qualidade e riscos relacionados”.

No entanto, o TMap Next levanta um questionamento sobre a sua definição de qualidade dentro do seu conceito de teste de software e frisa: Mas conselhos na qualidade de quê? O que é qualidade na verdade?

“A totalidade dos recursos e características de um produto ou serviço que afetam sua capacidade de satisfazer necessidades explícitas ou implícitas” (ISO 1994).

O conceito de qualidade é uma definição muito pessoal que varia de pessoa para pessoa. No entanto, desde 1977 quando McCall criou uma proposta de dividir o conceito de qualidade em um número diferente de propriedades, as também chamadas “Características da Qualidade”, muito progresso foi feito nesse sentido.

“A Característica da Qualidade descreve uma propriedade de um sistema de informação”.

Um exemplo das Características da Qualidade pode ser observado na norma ISO/IEC 9126-1. Pra mais informações vide Quais são as Reais Características da Qualidade da NBR ISO/IEC 9126-1?

Qual é a resposta então para pergunta: Conselhos na qualidade de quê?

- Teste é muito mais do que garantir o correto funcionamento do software. Com exceção do software, outros objetos de teste existem, os quais a qualidade pode ser estabelecida.

- O que é testado e as recomendações de qualidade que são subseqüentemente dadas são conhecidos como Objeto de Teste.

O Objeto de Teste é o sistema de informação (ou parte dele) que será testado. Um objeto de teste consiste de:

Hardware

Software

Aplicação de software

Organizações

Procedimentos

Documentação

Implementações

Ainda, conselhos na qualidade podem envolver com exceção da funcionalidade características da qualidade como: usabilidade, performance, portabilidade, testabilidade e manutenibilidade.

Armadilhas – O Que Teste Não É!

Como o TMap Next é um modelo extremamente organizado e estruturado, algumas definições são apresentadas sobre o que teste não é ou pelo menos o que teste não deveria ser, justamente porque a maioria das empresas estão encaixadas em alguns dos seguintes itens abaixo:

O teste não é uma questão de entregar ou aceitar alguma coisa. Teste fornece conselhos na qualidade e a decisão da liberação do software para produção é dos stakeholders.

Teste não é uma fase pós-desenvolvimento. Ao contrário, cobre uma série de atividades que devem ser realizadas em paralelo ao desenvolvimento(ou pelo menos deveriam).

Teste não é a implementação do sistema. Resultados de teste tendem a impedir os planos de implementação.

Teste não pretende inicialmente estabelecer se a correta funcionalidade foi implementada, mas garante se a funcionalidade requerida foi implementada.

Teste não é barato! Entretanto, um teste executado no tempo certo terá uma influência positiva no processo de desenvolvimento e um sistema qualitativamente melhor poderá ser entregue, gerando menos defeitos em produção.

Teste não é treinamento para operação e gerenciamento.

Por quê testar?

Embora muitos fatores existam para comprovar por que os testes devam ser realizados, o TMap Next cita os seguintes fatores contribuintes para que a atividade de teste:

T.I. cada vez mais está se tornando imprescindível nas organizações.

Pressão de budget e tempo para implementação de projetos, entregando assim sistemas com defeitos.

Organizações têm aceitado ou tendo que aceitar sistemas sem ter uma visão real da qualidade.

Falta de gerenciamento do release.

Grandes riscos são gerados: alto custo de re-trabalho, perda de produtividade, perda de reputação e perda de competitividade através de entregas atrasadas de um novo produto(perda de receita).

A partir dos fatores acima apresentados, surgem ainda os seguintes questionamentos:

Todos os requisitos foram implementados?

Todas as partes e aspectos do sistema foram explorados em profundidade suficientes?

Com exceção das funcionalidades, outros testes foram realizados?(performance, segurança, etc.)

Todos os erros foram re-trabalhados? Novos erros foram introduzidos com o re-trabalho?

O sistema realmente provê solução confiável com informações para o qual ele foi projetado?

Que riscos a organização está aceitando e que medidas são tomadas para reduzir estes riscos?

“Evitando responder estas questões na fase de operação, um bom e confiável processo de teste é necessário que demande uma estratégia de testes estruturada, organização e infra-estrutura, a qual uma visão contínua deve ser obtida de forma controlada no status atual do sistema e riscos envolvidos”.

O que o teste entrega?

Freqüentemente o processo de teste é considerado muito caro e é verdade se apenas olharmos para os custos de teste, desconsiderando seus benefícios. Os custos de teste são basicamente dois, conforme o TMap Next:

Custo da infra-estrutura do teste.

Horas trabalhadas pelos testadores(Horas X R$).

Benefícios do teste, segundo Rex Black(2002):

A prevenção de altos custos de re-trabalho e danos conseqüentes da situação da produção, graças aos defeitos encontrados durante o teste.

A prevenção de danos em produção, graças aos erros sendo encontrados durante o teste e enquanto não resolvidos, marcados como “erros conhecidos”.

Maior confiança no produto.

Facilitação de um bom gerenciamento do projeto fornecendo informações de qualidade e progresso

Podemos, assim, responder a questão inicial através de uma perspectiva econômica de teste: “O Que o Teste Entrega?”

ROI do Teste = Benefícios do Teste – Custos do Teste

O papel do teste

O papel dos testes e sua significância possuem certos conceitos em seus ambientes específicos:

Teste e Gestão da Qualidade

Qualidade foi, é e ainda será um desafio dentro da indústria de T.I. e teste de software não será a solução para isso. Levando-se em conta esta realidade, a qualidade deve ser construída e não testada!

Teste é o instrumento que provê uma visão da qualidade dos sistemas. Por isso, a atividade de testar o software deveria fazer parte de um sistema de medição para atingir a qualidade.

Teste de software deve ser uma atividade integrada na Gestão da Qualidade da organização.

Esta medição pode ser dividida em preventivas, detectivas e corretivas:

Preventivas: Focadas na prevenção da falta de qualidade(Ex: padrões de documentação, métodos, técnicas, treinamentos, etc.).

Detectivas: Focadas na descoberta da falta de qualidade pelos dois instrumentos de detecção: avaliação(revisões, inspeção, etc.) e teste.

Corretivas: Focadas na retificação da falta de qualidade(Ex: re-trabalho de defeitos).

Garantia da Qualidade cobre todas as ações planejadas e sistemáticas necessárias para proporcionar confiança adequada de que um produto ou serviço atenda aos requisitos de qualidade.

Teste: Como e Por Quem?

O teste é muito mais do que uma simples execução e geralmente não atrai muita atenção até ser iniciado de fato. Envolve, também, a correta preparação e planejamento e é mais abrangente que simplesmente coletar métricas.

A parte visível do iceberg é a execução dos testes, o que representa e cobre cerca de 40% das atividades de teste. Entretanto, a parte encoberta do iceberg é o planejamento e a preparação, o que representa cerca de 20% e 40% do esforço de teste respectivamente.

Maneiras de testar o software:

Três maneiras de testar o software podem ser apresentadas, conforme o TMap Next:

Teste Dinâmico Explícito: Os casos de teste são especificados para obter informação na característica da qualidade relevante. Com a execução do software, o resultado atual é comparado com o resultado esperado a fim de determinar se ‘sistema está se comportando de acordo com os requisitos.

Teste Dinâmico Implícito: Durante a execução de testes dinâmicos, informações podem ser coletadas com relação a outras características da qualidade. Análises podem ser realizadas como performance, confiança, recuperação e usabilidade baseadas na experiência sem a presença de casos de teste específicos para este fim.

Teste Estático: Produtos finais são avaliados sem a execução do software. Este teste consiste na inspeção de documentos como procedimentos de segurança, treinamentos, manuais, etc. e geralmente é feito com checklists.

Quem testa?

Qualquer um pode testar e quem realmente testa é determinado pelo papel ou responsabilidade de alguém em determinado tempo.

Representantes do teste podem ser: desenvolvimento, usuários e/ou gerência. Além destes, o teste é realizado por analistas profissionais, treinados e que podem trazer uma perspectiva diferente.

Teste e o Processo de Desenvolvimento de Sistemas

Os processos de teste e o desenvolvimento são integrados, sendo que enquanto um entrega o produto o outro avalia e testa. Uma das maneiras de se visualizar esta integração é através do Modelo V.

1 Contém especificações funcionais e não-funcionais

O lado esquerdo do Modelo V

Mostram as fases nas quais o sistema é construído ou convertido dos desejos, legislação, política, etc. na solução realizada. Durante o processo de desenvolvimento do sistema, produtos de trabalho ou artefatos são gerados. Com isso, podemos avaliá-los de forma que possamos sempre compará-los com fases anteriores usando revisões ou inspeções.

O artefato precedente:

O design funcional está consistente com o design técnico?

Os requisitos das fases posteriores

Pode o analista construir o design de forma não ambígua e as especificações são testáveis?

Outros artefatos no mesmo nível:

O design funcional está internamente consistente e com designs funcionais relacionados?

O padrão acordado do produto:

Existem casos de uso presentes?

As expectativas do cliente:

Os artefatos estão ainda consistentes com as expectativas de quem vai aceitar o produto?

O lado direito do Modelo V

Quando o lado direito do Modelo V é apresentado(iniciado no projeto), as responsabilidades devem ser definidas claramente, especialmente para testes: quem será o cliente do teste, quem aceita, quem quer conselhos na qualidade e quem vai testar o quê e quando?

Na prática, a distinção das responsabilidades nos testes é traduzida em grupos de atividades de teste dentro dos níveis de teste.

Nível de teste é um grupo de atividades de teste que são gerenciadas e executadas coletivamente.

Para cada fase de construção existem um ou mais níveis de teste:

Testes de Desenvolvimento: Demonstra que o produto está de acordo com especificações técnicas, entre outras coisas.

Testes de Sistema: Demonstra que o produto está de acordo com as especificações funcionais e não-funcionais, entre outras coisas.

Testes de Aceite: Demonstra que o produto está de acordo com as expectativas do cliente/usuários.

O Modelo V, especialmente o lado direito do V, pode sofrer alterações de organização para organização e de projeto para projeto, podendo existir mais níveis de teste.

Base para os Testes e Níveis de Teste

Um nível de teste tem como meta demonstrar o grau o qual um produto está de acordo com as expectativas, requisitos, especificações funcionais ou técnicas, sendo que a documentação do sistema é geralmente usada para referência. Se não houve documentação(cenário comum em projetos de T.I.), os usuários finais podem ser usados como referência. Muitas fontes podem ser usadas para o teste e em geral o termo usado para estas fontes é Base para os Testes(Test Basis).

Base para os Testes é a informação que define o comportamento necessário do sistema.

Estas fontes são a base para se criar os casos de teste. A figura a seguir usa setas com o texto “Input For” para indicar qual fonte de informação pode ser usada em qual nível de teste como base para se criar casos de teste. É possível que a mesma base de teste esteja sendo usada em dois níveis de teste. Isso acontece porque quando existem duas partes diferentes realizando testes de acordo com suas responsabilidades individuais.

É provável também que em alguma situação exista a chance de se duplicar os testes que são executados, sendo esta uma decisão válida para se justificar igualmente a combinação de certos níveis de teste.

Níveis de Teste e Responsabilidades

Na fase de desenvolvimento do sistema, uma separação pode ser feita entre as responsabilidades do cliente, usuário, gerente e administrador do sistema de um lado e desenvolvedor/fornecedor por outro lado. No contexto de teste, o primeiro grupo é coletivamente conhecido como “aceitador”(requisitante) e o segundo grupo como o fornecedor. Outros conceitos que também podem ser mencionados nesta conexão são as organizações demandantes e organizações fornecedoras. Com isso, existem dois possíveis focos do teste:

A parte fornecedora demonstra que o que deveria ser fornecido, na verdade, é fornecido.

A parte “aceitadora” estabelece se o que é requisitado tem, na verdade, sido recebido e se eles podem fazer o produto que eles querem/precisam.

Tipos de Teste

Durante o teste de um sistema vários tipos de propriedades podem ser observados, a também chama “Características da Qualidade”(Ex: funcionalidade, performance e continuidade). Esta forma normalmente usada como característica da qualidade é também chamada de Tipos de Teste.

Um grupo de atividades de teste com a intenção de verificar o sistema de informação em relação a uma série de correlações com a (aspectos  da)  características de qualidade.

Dentre os vários tipos de teste, um se destaca: o teste de regressão. Isso porque um tipo de teste é pretendido a prover informações detalhadas sobre um risco específico(características da qualidade), enquanto que a regressão, ao contrário, atende a um fim específico de tipo de teste.

Regressão é o fenômeno que a qualidade de um sistema se deteriora como um todo, como resultado de mudanças individuais.

Um teste de regressão é destinado a assegurar que todas as partes de um sistema inalterado ainda funcionem corretamente após a implementação de uma mudança.

O que é teste estruturado?

Na prática, como se parece uma Abordagem por Testes Estruturados? Em geral, são caracterizadas por:

Prover uma estrutura de forma a possibilitar claramente o quê, por quem, quando e em qual seqüência deve acontecer.

Cobrir o escopo totalmente.

Prover apoio concreto, sem a necessidade de se reinventar a roda repetidamente.

Gerenciar atividades de teste no contexto de tempo, dinheiro e qualidade.

Desvantagens do Testes Não Estruturados

Teste não estruturado é caracterizado pela situação de desordem, na qual é impossível prever o esforço do teste, executar os testes de forma adequada ou medir os resultados eficientemente, sendo referenciado por muitos como “Ad Hoc Testing”.

Este tipo de abordagem não implica em critérios de qualidade de modo que, por exemplo, se determine e priorize riscos e atividades de teste, nem o uso de técnicas de teste para se derivar casos de teste.

Algumas informações encontradas em estudos sobre testes estruturados e não estruturados são:

Pressões de tempo resultando em:

Ausência de um bom plano de teste e métodos de orçamento.

Ausência de uma abordagem nas quais atividades de testes são realizadas em determinada fase e por quem.

Ausência de acordos sólidos nos termos e procedimentos para delivery e re-trabalho das aplicações.

Sem visão ou habilidade para fornecer conselhos na qualidade do sistema devido a:

Ausência na estratégia de risco.

Ausência na estratégia de teste.

Técnicas de design de teste não são utilizadas, portanto ambas a qualidade e a quantidade de casos de teste são inadequados.

Ineficiência e ineficácia resultando em:

Falta de coordenação entre as partes envolvidas no teste, permitindo que os objetos de teste são potencialmente testados mais de uma vez ou ainda pior: não são testados!

Falta e acordos na área de gerenciamento de configuração e mudanças para ambos os produtos de teste e desenvolvimento de sistemas.

O incorreto ou não uso das, freqüentemente disponíveis, ferramentas de teste.

Falta de priorização resultando em mais testes executados em partes menos importantes e deixando as partes com risco mais alto com menos testes executados.

Vantagens da Abordagem por Testes Estruturados

Uma reposta simples para as vantagens dos testes estruturados seria apenas invertermos as desvantagens. Algumas das vantagens notórias para o uso do TMap Next(testes estruturados) são:

Pode ser usado em qualquer situação, independentemente de quem é o cliente ou qual abordagem de desenvolvimento de sistemas é usada.

Entrega uma visão e aconselha em qualquer risco em respeito à qualidade do sistema testado.

Encontra defeitos em estágios inicias do processo de desenvolvimento de software.

Previne defeitos.

O teste está no caminho crítico do total de desenvolvimento o mais cedo possível, fazendo com que o prazo total de entrega do desenvolvimento seja diminuído.

Os produtos de teste(Ex: casos de teste) são reusáveis.

O processo de teste é compreensível e gerenciável.

Referências e Links:

- Livros utilizados para a base deste artigo e materiais de apoio

TMap Next, for result-driven testing

Software Testing: A guide to the TMap Approach

End-to-end testing with TMap Next

CSTE CBOK – Common Body Of Knowledge , 2006; v6.

IEEE 610.12 - Standard Glossary of Software Engineering Terminology, 1990

Glossário Padrão de Termos Utilizados em Teste de Software, 2010; v2.1

Livro Base de conhecimento em teste de software, 2007

- Links

            - Site TMap Next: http://eng.tmap.net/Home/

-TMap Next Downloads: http://eng.tmap.net/Home/TMap/Downloads/index.jsp

            - Glossário TMap Next: http://eng.tmap.net/Home/TMap/Glossary.jsp