A atividade do processo de desenvolvimento de testes faz parte da fase da validação no ciclo de vida do software em que encontramos todas as fases na vida do sistema, desde a definição dos seus requisitos até o fim da sua utilização.
O modelo de desenvolvimento utilizado no projeto Axa Banque é o modelo em V. Executam-se testes de aceitação de tipo funcionais em dois tipo de ambiente :
“qualification” e “certification”. O primeiro procura verificar se as aplicações desktop,
web e mobile funcionam de acordo com as especificações num ambiente com dados fictícios. O segundo tipo de testes funcionais são para garantir o bom funcionamento das aplicações num ambiente comparável àquele que será comercializado na realidade sendo uma cópia da base de dados real. Nesta categoria de testes também estão incluídos os conhecidos testes de regressão que testam as alterações e/ou correções feitas nas aplicações e permitem detetar disfunções que elas possam causar.
O processo de desenvolvimento de testes engloba várias fases: analisar os requisitos, desenhar o plano de testes, executar os testes, relatar as anomalias e documentar os resultados dos testes.
Tive a oportunidade ao longo do estágio de desenvolver cada uma dessas fases.
Análise de requisitos
A primeira etapa, na análise de requisitos, é a leitura e a análise da COF “Conception Fonctionnelle”. A COF é o documento de especificações, das exigências do sistema enviado pela equipa em França. Este documento detalha as suas funcionalidades e as regras de gestão que deve respeitar. Comparando com a área da construção, os documentos funcionais são para os sistemas informáticos o que são os planos para a construção. (Ver exemplo anexo II)
O passo seguinte é elaborar “L’estimative des charges”, o tempo necessário para o projeto, desde a análise da COF até a validação para ir para produção, passando pelo desenho do plano de teste, a execução dos testes, a correção das anomalias, os retestes e
reporting. O documento da estimativa de tempo e o plano de teste devem ser enviados
ao chefe de projeto para serem aprovados (o chefe de projeto pode ser diferente de projeto para projeto), ilustração 14 e 15.
Ilustração 14- "Estimative des charges" de um Projeto Ilustração 15 - "Estimative des charges" de uma DM
Desenho de planos de testes
A elaboração do plano de testes é a etapa seguinte. O plano de teste é um dos oito documentos descritos na IEEE 829, uma norma que especifica a forma e o conjunto de artefatos no teste de software (Wikipédia, 2015). Durante a conceção do plano de teste, os casos de teste e dados (valorização) de teste são criados e especificados.
Dependendo do tamanho do projeto, a análise da COF e a conceção do plano de teste pode demorar entre dois a cinco dias e é elaborado por um membro da equipa com o aval do chefe de projeto.
O Plano de teste é elaborado num excel tendo em conta as exigências, os requisitos, as necessidades que devem ser testadas, e é exportado no HP ALM (Application Lifecycle Management - versão 11.0) (Anexo III). Uma vez as exigências definidas desenham-se os casos de teste que vão ajudar a fazer com que os testes sejam mais eficientes. Cada caso de teste consiste em uma série de passos (“steps”), com um conjunto de valores de entrada, pré-condições de execução, resultados esperados e condições pós-execução. Os resultados esperados testam a eficácia do software. Eles incluem as saídas, as alterações aos dados e estados, e outras consequências do teste. Os resultados esperados devem ser definidos, idealmente, antes da execução do teste.
Para decidir a quantidade exata de testes é necessário ter em conta o nível de risco, incluindo ( de segurança, técnicos, empresariais) e as restrições do projeto (tempo
Demande de maintenance (DM) Análise COF + Plano de testes Testes em "Qualification" Testes em "Certification" Testes de regressão (TNR) Reporting Projeto Análise COF + Plano de testes Testes em "Qualification" Testes em "Certification" Testes de regressão (TNR) Reporting
e orçamento). As técnicas de testes selecionadas são técnicas de Black-Box, estando ligadas às especificações.
Os planos de teste elaborados na equipa têm como características os seguintes atributos:
“ID”: nome do caso de teste. O nome é precedido por trigramas, o primeiro grupo de
três letras são referentes à exigência correspondente, as restantes remetem ao teste em si.
“Description”: uma breve descrição que é uma visão geral do caso de teste. Explica
os objetivos e procedimentos do teste de forma clara, para que qualquer um seja capaz de entender sem conhecer previamente a aplicação testada.
“Steps”: número do passo do caso de teste.
“Description des steps”: descrição do que deve ser feito para realizar o passo do
caso de teste.
“Résultat attendu”: é o resultado esperado para que o teste seja validado com
sucesso.
Quando o plano de teste é feito no HP ALM é necessário indicar a prioridade (“élevé/moyen/faible”) e a severidade (“Bloquante/Importante/Mineure”) do caso de teste.
Execução de testes
Testes funcionais
Após o plano de teste ter sido elaborado começa a execução dos testes em ambiente de
“Qualification” quando há confirmação da instalação. A execução é feita manualmente
e registada no HP ALM (Application Lifecycle Management - versão 11.0 (Anexo IV).
Se o “PV de Recette”(Anexo V) for validado “accepté” segue a execução dos testes
em ambiente de “Certification” isto quando há confirmação da instalação neste
visto que todos os testes já foram executados no ambiente de Qualificação anteriormente.
Testes de regressão
Concluído um lote de projetos de testes e antes do software ir para produção é necessário executar os testes de regressão. Esses testes são designados pelo cliente de “Tests de Non Regression – TNR” e são agrupados num Excel partilhado (enviado pela equipa em França) diferente para cada aplicação (Web, Mobile, RC, AxaPac/NetAgent, ExtraNet) (Anexo VI).
Um lote pode ser por exemplo um conjunto de pequenos projetos e/ou de DM “Demande de Maintenance”. As DM são pequenas correções ou alterações nas aplicações do cliente, sem grande impacto, que não impedem a produção e que são corrigidas mais tarde. Podem ser “Evolutive” se for uma alteração ou “corrective” se for uma correção de anomalia. Normalmente estas alterações, correções são inseridas em versões posteriores.
Relatar anomalias
Existem dois tipos de anomalias as QC “Quality Center” (anomalias detetadas nos testes registados no ALM HP) e os PbEnv “Problèmes de environnement” (“Ticket”, anomalias ligadas a problemas de ambiente, quando este não funciona e impede a execução dos testes). As anomalias de ambiente são abertas no REDMINE. Sempre que é encontrada uma anomalia na aplicação testada é necessário elaborar um documento Word com as capturas de ecrã e a descrição de todos os passos efetuados até a anomalia.
Para as aplicações desktop (AxaPac/NetAgent, ExtraNet e RC) e Web as anomalias são abertas no HP ALM ( Application Lifecycle Management - versão 11.0).
Para as aplicações mobiles existem duas plataformas nas quais são abertas as anomalias. Para a aplicação SOON em Android e iOS, a plataforma usada é oTAPPTIC. Para a aplicação SOON no Windows Phone, as anomalias são abertas num REDMINE diferente daquele em que são abertas as anomalias da aplicação Refresh Mobile.
Podemos ver na ilustração 16 a classificação das anomalias no HP ALM:
Ilustração 16 - Classificação das anomalias no HP ALM
Documentar resultados dos testes
Após a finalização dos testes em ambiente de “Qualification”, é emitido um
“PV de Recette” (Anexo 5) que é o documento que garante formalmente que o produto
atende às especificações e que valida ou não o projeto. Neste documento indica-se o perímetro testado, o número de testes previstos e efetuados, o número de anomalias abertas e corrigidas e a identificação de qualquer diferença funcional ou técnica descrita. O “PV de Recette” pode emitir reservas se foram encontradas anomalias, problemas de ambiente, falta de valorisações para testar, etc.
Após a finalização dos testes em ambiente de“Certification” é emitido novamente um PV, o “PV de Certification” (Anexo 7), este só é validado se não existir nenhuma anomalia “Bloquante”.
Se o projeto se inserir num lote será necessário esperar que todos os projetos desse lote sejam validados. (O Lote é uma Release: nova versão do programa ao qual foram adicionadas correções e melhorias. É o conjunto de pequenos projetos da equipa). Se tudo estiver validado, o lote pode passar para produção.
A equipa deve, ao longo do projeto, preencher o “Bilan” (Anexo 8), documento que serve para fazer o balanço do projeto em vários indicadores. Este permite ter uma análise completa de toda a estrutura de testes desenvolvida com as várias equipas: chefes de projetos / programadores / Tester, ao longo dos testes.