Métricas nos testes de software

Tema de minha monografia, farei uma prévia e quem se interessar mais pelo assunto pode me contatar.

O teste de software revela a presença de defeitos, se as exigências de qualidade de software estão sendo seguidas e geram métricas para verificar a efetividade e a eficiência das atividades e desenvolvimento de software.

As métricas de teste tendem a indicar o aumento no número de defeitos e problemas no processo de desenvolvimento, indicar se um processo está sob controle e se os objetivos estão sendo atingidos.

Podemos utilizar as métricas de teste para:

•       Reportar a situação do teste

•       Avaliar a qualidade do produto

•       Analisar defeitos

•       Avaliar risco do projeto

•       Medir o progresso contra as metas

•       Melhorar as técnicas de estimativa

•       Medir a eficácia do processo de desenvolvimento

•       Identificar melhorias necessárias em processos

Devido a grande variedade de métricas de teste, se torna devidamente importante definir quais delas devemos utilizar, pois pode acontecer de o resultado não ser significativo ou útil para o processo atual de melhoria. Por isso, é importante que sejam capturadas e utilizadas corretamente, de maneira que auxiliem na melhoria do processo de desenvolvimento do software através de informações objetivas e pragmáticas para iniciativas de mudanças do processo.

As métricas de teste de software existentes estão distribuídas em métricas de processo, de produto e de projeto.

Métricas de Processo servem para auxiliar no controle da qualidade do processo de testes. Ex: Mudanças no escopo, fase em que o defeito foi encontrado, número de caso de testes, probabilidade de defeitos, etc.

Métricas de Projeto servem para planejar o desenvolvimento e avaliar a qualidade dos produtos. Ex: tempo necessário para executar um teste, tempo disponível para o esforço de teste, etc.

Métricas de Produto servem para auxiliar no controle da qualidade do produto que está sendo testado. Muitos relatórios são gerados a partir desse tipo de métrica, como, por exemplo, os relatórios de defeitos. Tais relatórios são muito importantes para a avaliação da qualidade do software.

A qualidade é uma medida de confiabilidade, de estabilidade e de desempenho do software, e se baseia fortemente na avaliação dos defeitos encontrados durante os testes, que variam de simples contagens a estatísticas mais complexas. Tais defeitos são um indicativo de necessidade de mudança, pois o objetivo do teste não satisfez aos requisitos. A avaliação dos defeitos estima a confiabilidade do software atual e prevê como será a confiabilidade na continuação dos testes e a eliminação dos defeitos.

Requisitos Não-Funcionais

Requisitos não funcionais são aqueles que incluem Atributos de Qualidade para o produto.

Exemplos:

Atributos importantes para os usuários:

• Desempenho ("Ao registrar um item sendo vendido, a descrição e preço devem aparecer em, no máximo, 2 segundos")
• Volume de utilização, incluindo número de usuários, número de transações, ... ("O sistema deverá suportar uma carga máxima de 2000 usuários simultâneos com degradação de desempenho de, no máximo, 10% em qualquer operação")
• Disponibilidade ("O sistema estará disponível pelo menos 99,7% do tempo em dias de semana entre 06:00 e meia-noite e pelo menos 99,95% entre 16:00 e 18:00")
• Flexibilidade ("Um programador de manutenção com pelo menos 6 meses de experiência no suporte ao produto deverá ser capaz de dar suporte a um outro dispositivo de interconexão em não mais do que 1 hora de trabalho")
• Integridade/segurança ("Apenas usuários com privilégios de acesso de Auditor poderão visualizar históricos de transações de clientes")
• Interoperabilidade ("O Sistema de Rastreamento de Produtos Químicos deverá ser capaz de importar qualquer estrutura química válida das ferramentas ChemiDraw e Chem-Struct")
• Compatibilidade com outras versões e necessidades de migração ("O sistema deverá reconhecer arquivos de versões antigas e transformar os arquivos para o novo formato automaticamente, após confirmação pelo usuário")
• Confiabilidade ("Não mais do que 5 experimentos químicos em cada 1000 podem ser perdidos devido a falhas de software")
• Robustez ("Todas as variáveis de entrada terão valores default e tais valores serão usados sempre que dados de entrada estiverem faltando ou inválidos")
• Tolerância a falha ("O sistema deve fazer log dos pagamentos autorizados via cartão de crédito em 24 horas, mesmo com falhas de energia ou de dispositivo")
• Usabilidade ("Um novo usuário deverá ser capaz de fazer um pedido de compra de um novo produto químico após não mais do que 30 minutos de orientação")
• Tipo de interface desejada ("O sistema deverá ser acessado completamente via browser HTTP/HTML")
• Hardware e software alvo ("O produto será desenvolvido para ambientes Windows e para máquinas com pelo menos 128 MB de memória")
• Necessidades de internacionalização ("O produto será disponibilizado em inglês, mas de forma a permitir que versões em línguas latinas possam ser produzidas sem necessidade de ter acesso ao código fonte")
• Documentação necessária ("A documentação on-line incluirá um Tutorial e um Manual de Referência")
• Uso de padrões ("O produto deverá dar suporte aos protocolos SNMP versões 1, 2 e 3")
• Aspectos legais ("O sistema deverá seguir regras do documento XPTO-12X/2001 do Banco Central no que diz respeito à auditibilidade das transações efetuadas")
• Preço da solução ("O produto deverá ser desenvolvido de forma a possibilitar um custo de produção de, no máximo, US$32")
• Packaging ("O produto será distribuído exclusivamente pela Internet, sem opção para aquisição de CDROM ou de manuais impressos. O tamanho máximo do download deve ser de 10 MB")
• Requisitos de instalação ("O Produto deve ser instalável através do instalador RPM do Linux")
• Business rules ("Apenas usuários com cargos de supervisão podem aceitar retorno de mercadoria com valor acima de R$100,00")

Atributos importantes para os desenvolvedores:

• Manutenabilidade ("Modificações a qualquer relatório deverão ser implementadas 24 horas após recepção de aviso de modificação de regulamentação pelo Ministério de Agricultura")
• Portabilidade ("O produto deverá ser desenvolvido de forma a possibilitar seu transporte para Linux em, no máximo, 60 dias")
• Reusabilidade ("O produto deverá usar componentes corporativos existentes sob forma de Enterprise JavaBeans. Novos componentes deverão ser EJBs")
• Testabilidade ("Testes de Unidade e de Aceitação deverão ser completamente automatizados")
• Suporte ("Suporte ao produto será feito exclusivamente através de site Web, com acesso a Base de Conhecimento sobre o produto")

Checklist do testador

Geral

• Verificar ortografia das mensagens e dos campos.
• Verificar se campos de radio button excludentes não podem ser marcados ao mesmo tempo.
• Verificar layout do sistema, tentar manter a aparência mais parecida possível com o protótipo. Além disso deve-se verificar se os campos e tabelas estão alinhados com relação aos outros campos.

Filtro e Pesquisa

• Verificar lógica das mensagens. Ex.: Campo de filtro para período entre anos ____ a ____ colocar ano _2000_ a _1500_ deverá aparecer a mensagem "O ano final deve ser maior que o inicial" e no caso de colocar ano _1500_ a _2000_ a mensagem não deve aparecer.
• Fazer combinações de filtros e verificar se estão sendo listados resultados relativos aos filtros selecionados.
• Verificar a ordenação das listagem (ver especificação).
• Verificar a ordenação de campos combo box (ver especificação).
• Verificar se os campos estão habilitados ou desabilitados conforme a especificação.
• Ficar atento aos erros de java script.
• Preencher os campos de texto com caracteres especiais e/ou caracteres inválidos.
• Se não conseguir preencher com caracteres inválidos via teclado, tentar ctrl+v e cola com o mouse.
• Verificar se o botão limpar está limpando todos os campos corretamente.
• Campos de texto deve ser possível pesquisar com uma substring. Ex.: Para pesquisar um funcionário com nome Ana Paula Muniz, se eu digitar na consulta a string "Ana" deve aparecer todos os funcionários que possuam a palavra Ana, como Ana Maria, Luciana, etc.
• Verificar na especificação quais campos já devem vir preenchidos.

Cadastro

• Preencher os campos de texto com caracteres especiais e/ou caracteres inválidos.
• Se não conseguir preencher com caracteres inválidos via teclado, tentar ctrl+v e cola com o mouse.
• Verificar se os campos estão habilitados ou desabilitados conforme a especificação.
• Ao confirmar a operação de cadastro, verificar se apareceu uma mensagem informando que o item foi cadastrado.

Exibir

• No exibir, deve-se ficar muito atento à consistência dos dados, tipo se um dado foi inserido no cadastro ele deve obrigatoriamente aparecer no Exibir com sua respecitiva máscara.
• Deve-se estar ciente qual o valor que deve ser exibido no caso de um campo não ter sido preenchido. Às vezes deve aparecer o campo vazio outras vezes deve aparecer algum caracter.
• Verificar na tela de exibição se todos os dados alterados foram exibidos corretamente na tela, inclusive ficar atento às máscaras.

Atualizar

• Este deve ser o caso de teste mais rigoroso e deve ser feito com mais atenção.
• Verificar se os campos atualizados foram realmente atualizados. Esta verificação deve ser feita tanto no exibir quanto na tela de alteração.
• Verificar se na tela de alteração se todos os campos foram carregados corretamente.
• Executar o fluxo de alteração mais de uma vez, para garantir que nenhum dado esteja sendo mantido na sessão.
• Verificar a atualização de campos que fazem parte de pop-up. Pois muitas vezes as alterações que são feitas dentro do pop-up se perdem ao fechar a janela.
• Verificar se os dados cadastrados/atualizados nos pop-up estão corretos.
• Quando houver uma tabela em que seja possível inserir e remover dados dela antes de cadastrar, realizar testes de carga para ver se os dados estão sendo mantidos/removidos corretamente.
• Ao confirmar a operação de atualização, verificar se apareceu uma mensagem informando que o item foi atualizado.
• Verificar se ao chamar algum pop-up se ao fechar a janela, o fluxo continua no modo de alteração.

Excluir

• Tentar excluir um registro, no alert de confirmação clicar em Cancelar e depois verificar se o registro não foi excluído.
• Tentar excluir um registro, no alert de confirmação clicar em OK e depois verificar se o registro foi excluído.
• Realizar uma pesquisar e verificar se a exclusão foi realizada realmente.
• Verificar se apareceu uma mensagem informando que o item foi excluído.

Relatórios

• Ficar muito atento aos dados que contém no relatório, ou seja, ao fazer uma filtragem de dados, deve-se verificar se apenas aqueles dados selecionados é que fazem parte do relatório.
• Verificar se o layout do relatório está idêntico ao do protótipo.
• Verificar a ortografia dos relatórios.
• Verificar questões de agrupamento das colunas quando há dados repetidos numa mesma coluna, geralmente esta informação está presente no projeto de teste ou especificação.

Quanto mais tarde um defeito é corrigido, mais cara é a sua correção.

Por que um defeito ocorre?

• Software não faz o que a especificação diz para fazer;
• Software faz algo que na especificação diz para não fazer;
• Software faz algo que a especificação do produto não menciona;
• Software não faz algo que a especificação do produto menciona;
• Software é difícil de entender, difícil de usar, lento, ou simplesmente aos olhos do testador o “usuário não gostará”.

Tipos de Defeitos:

1.            Defeitos de interface com os usuários

• Defeitos da funcionalidade – Ocorrem quando o software executa uma ação não especificada nos seus requisitos ou quando o requisito especifica uma coisa e o software faz outra.
• Defeitos de usabilidade – São defeitos decorrentes da dificuldade para se navegar em uma aplicação.
• Defeitos de desempenho – O programa não atende com rapidez necessária às solicitações do usuário, especialmente no caso dos sistemas interativos. Existem estudos que indicam um tempo máximo de 3 segundos como o tempo máximo que o usuário suporta sem desviar a sua atenção para outra coisa.
• Defeitos de saída – Os resultados apresentados pelo software não estão conforme definido pelas especificações fornecidas pelo usuário ou foram mal projetadas dificultando a sua análise.

2.            Defeitos no manuseio de defeitos

• Prevenção dos defeitos – O programa não se protege das entradas de dados não previstas que posteriormente são processadas de forma inadequada. O software pode, por exemplo, aceitar valores em branco em campos numéricos.
• Detecção dos defeitos – O programa não trata (ou trata inadequadamente) as indicações de defeitos resultados das suas operações, tais como: overflow, flags de defeitos, etc. Nestes casos deveria ser dado um aviso da ocorrência do problema.
• Recuperação dos defeitos – Mesmo detectando o defeito, o programa falha porque não trata adequadamente a situação.

3.            Defeitos de limites

O programa não consegue tratar ou trata inadequadamente valores extremos (o maior, o menor, o primeiro, o último, etc) ou fora dos limites estabelecidos.

4.            Defeitos de cálculo

O programa efetua um cálculo e produz um resultado errado, causado basicamente por: lógica errada, defeito de codificação e/ou imprecisão no cálculo.

5.            Defeitos de inicialização ou fechamento

Alguns programas ou rotinas devem ser inicializados respectivamente quando usados pela primeira vez ou sempre que são chamadas para execução. Muitos no momento da inicialização criam um arquivo em disco, a ausência deste arquivo poderá causar problemas nas etapas seguintes do processamento.

6.            Defeitos de controle de fluxo

O controle de fluxo controla, em determinadas circunstâncias, o que o programa fará a seguir. Um defeito deste tipo leva o programa fazer coisas erradas, parando ou tendo comportamento inesperado.

7.            Defeitos de manuseio ou de interpretação de dados

Ocorre quando um programa tem que passar um grupo de dados para outro programa. No processo, os dados podem ser corrompidos ou interpretados incorretamente. As últimas modificações de dados podem ser perdidas ou estar disponível no momento errado.

8.            Defeitos de condições de disputa

Ocorre quando o programa espera pela resposta dos eventos A e B, sendo que é suposto que A sempre termine primeiro. Se por algum problema B terminar primeiro, o programa pode não estar preparado para esta situação e apresentar resultados inesperados.

9.            Defeitos de carga

O programa não pode suportar um pico de serviço em um determinado momento (estresse) ou uma carga alta de serviço por um tempo muito prolongado. Por exemplo, os testes previram um pico de processamento, porém não previram este pico por um tempo prolongado.

10.         Defeitos de hardware ou software

São defeitos decorrentes da incompatibilidade entre o programa e o ambiente onde está sendo processado, gerando falhas de comunicação entre ambos.

11.         Defeitos de controle de versões

Acontece devido a uma falha no processo de gestão de configuração.

Quando a versão de um programa é ligada com versões diferentes de outros componentes. Deve haver controle de configuração não apenas nos artefatos de desenvolvimento quanto nos artefatos de teste.

O defeito está associado a vários fatores como, por exemplo: o processo de software, a execução das atividades, o ambiente de trabalho, o hardware, o software e vários outros fatores podem auxiliar para que o defeito ocorra.

Quando um software falha, dependendo da cultura da empresa ou do testador, serão usados diferentes termos para explicar essa ocorrência, vamos esclarecer o significado comum entre eles:

• Falha, defeito representa de forma semelhante “o software falhou em não funcionar corretamente ou em não fazer a coisa correta”.
• Anomalia, incidência, variança representam um “funcionamento eventual ou involuntário do software”.
• Problema, erro, “bug” são termos genéricos.

Teste é uma tarefa extremamente criativa e desafiante.

“O teste de software busca contribuir com a qualidade do software auxiliando a prevenir defeitos e identificando os defeitos que estão presentes no software.”

São "missões" do testador:

• Provar que o software não faz o que deveria;
• Provar que o software faz o que não deveria;
• Provar que o programa não funciona;
• Não existe programa 100% livre de defeitos;
• Ter uma visão diferente do desenvolvedor;
• Diminuir o risco para o negócio.

O profissional de teste deve ser:

• Explorador: não ter medo de se aventurar nas situações;
• Resolvedor de problemas:
• Incansável: testar até estar satisfeito;
• Criativo: testar nem sempre é óbvio;
• Perfeccionista: teste não tem meio-termo;
• Exercitar o julgamento: tomar decisões enquanto testa, que afetam para melhor ou pior a qualidade do teste;
• Diplomático: o ser humano não gosta de ter erros apontados, mas que o erro venha do programa;
• Persuasivo: quem conserta o defeito deve entender a importância de fazê-lo;

Aumentar a qualidade do software, desde o levantamento de seus requisitos até a utilização em produção:

• Economiza tempo;
• Reduz riscos;
• Reduz custos;
• Melhora processos;
• Melhora qualificações dos profissionais.

Tenha em mente:

• Teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem.
• O Teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se nenhum defeito for encontrado, não prova que ele esteja perfeito. Teste não mostra que bugs não existem.
• Os testes são indispensáveis para detectar os defeitos que ainda escapam das revisões e para avaliar o grau de qualidade de um produto e de seus componentes.

Equipe de teste: 

• Líder do Projeto de Testes - Técnico responsável pela liderança de um projeto de teste específico, normalmente, seja um projeto novo ou uma manutenção.
• Arquiteto de Teste - É o técnico responsável pela montagem da infra-estrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e capacitando a equipe para executar o seu trabalho neste ambiente de teste.
• Analista de Teste - É o técnico responsável pela modelagem e elaboração dos Casos de teste e pelos Scripts de Teste. Pode ser que em alguns casos os Scripts de Teste sejam elaborados pelos testadores.
• Testador - Técnico responsável pela execução dos Casos de Teste e Scripts de Teste.

Testar pode ser aparentemente simples, porém quando olhamos com “lupa”, vemos que existe um novo universo logo ali, e no caso em questão, um “projeto dentro de outro projeto”.