Seu projeto Web acaba de ser entregue e você precisa aceitá-lo? Antes do comissionamento, você deve verificar se o que foi entregue funciona bem e corresponde ao que você solicitou . Isso é chamado de receita e não deve ser esquecido. Como garantir a eficácia e o sucesso deste passo fundamental antes de entrar online?
A receita para um projeto web é o termo usado para designar a fase essencial e, no entanto, muitas vezes abusada de um projeto: teste de aceitação. Ou seja, o que é entregue funciona e corresponde ao que foi solicitado?
A receita é um momento delicado que mina fortemente a paciência de todos.
Já que todos querem a mesma coisa, o sucesso do projeto , não vamos nos irritar.
A receita é uma operação que deve ser tratada com seriedade, método e preparo . À medida que ela chega ao final do projeto, às vezes com atraso, todos os mal-entendidos, imprecisões ou erros de interpretação se cristalizam nesse momento.
Se somarmos os poucos erros ou anomalias que escaparam à vigilância dos técnicos, não é incomum ver tensões. Estes não promovem o andamento do projeto, neste o (bom) método permite ir além .
Em primeiro lugar, a receita requer a intervenção de todas as partes interessadas do projeto . Alguns podem não se sentir preocupados, eles devem estar convencidos dos méritos da abordagem para que ela tenha sucesso.
De fato, não se trata simplesmente de “fazer um tour pelo aplicativo” para ver se está tudo bem. Isso, os desenvolvedores já fizeram.
Isso é para garantir que:
- todas as funções de negócios estão operacionais (usuários e MOA),
- casos não conformes são atendidos (AMOA, AMOE),
- as interfaces interoperam adequadamente (MOA, AMOA e MOE),
- a identidade da empresa é respeitada (MOA e AMOA),
- o back office é seguro (DSI, AMOA, AMOE) ,
- e que todos os outros aspectos descritos nas especificações foram incorporados.
Para ser eficaz, a receita deve ser preparada a montante, o mais cedo possível, construindo protocolos de teste reais
Essa abordagem deve ser levada em consideração desde a elaboração das especificações funcionais , ou mesmo durante a concepção das funções sensíveis do projeto.
Ele então se estende até o final da Verificação de Serviço Regular (VSR), ou seja, pelo menos algumas semanas após o comissionamento.
Este trabalho de aceitação pode ser dividido em duas etapas bem distintas :
- a preparação,
- e execução.
A preparação começa com a definição da estratégia de aceitação, segundo qual método e sobretudo em que calendário e por quais stakeholders. Continua com o desenho de cenários de teste e sua preparação.
Dê tempo suficiente para a receita
… caso contrário, na produção, será mais longo, mais difícil e mais estressante porque com fortes impactos para os usuários.
A execução da receita é estabelecida em dois eixos. Testes automatizados são suportados por técnicos . Os resultados, apresentados na forma de logs , podem ser analisados para identificar problemas.
Esse tipo de teste é essencial para funções de negócios complexas ou para verificar a não regressão durante as atualizações.
O teste manual é suportado pela AMOA e pelos usuários . O objetivo é destacar problemas e áreas de melhoria em situações reais. Os resultados são apresentados em forma de relatório.
Em todos os casos, as observações são alimentadas em um sistema de monitoramento – ticket manager – permitindo que sejam qualificadas e atendidas.
Assim, a receita é estabelecida com base em testes . Para poder testar uma função é necessário identificar seus casos de uso, propor coletas de dados de teste, definir os resultados esperados e as ações consecutivas.
Quando o teste é automatizado, um programa ou script é escrito para realizar as operações.
Quando é manual, uma folha de teste é escrita para permitir que o testador o execute de acordo com o protocolo planejado.
Certamente, podemos aceitar que os testes sejam estabelecidos pelo testador, por exemplo para validar um layout, ergonomia ou uma simples função. No entanto, deve-se ter o cuidado de usar dados reais para garantir a verdadeira mensuração do resultado .
Em qualquer caso, a receita deve ser objeto de um relatório, chamado relatório , que explique o que foi testado, como foi testado, as anomalias observadas e as que foram corrigidas. Adicionaremos os ajustes e alterações que foram solicitados. É com base neste relatório que você poderá expressar sua aceitação da entrega e, assim, autorizar – ou pelo menos validar – o comissionamento.
Terminologia da receita
MOA / AMOA
A autoridade contratante (MOA) é a pessoa ou empresa que encomenda o projeto. O assistente do dono do projeto ( AMOA ) é um consultor especializado que acompanha o dono do projeto em sua abordagem.
MOE / AMOE
O Gerente de Projeto (MOE) é a pessoa ou empresa que realiza o projeto. O assistente do gestor de projeto (AMOE) é um consultor que acompanha o gestor de projeto durante a realização do projeto, nomeadamente na sua relação com o cliente.
Minutos: minutos
O relatório de aceitação incorpora o relatório de operação de um lote de testes de projeto web. Cada relatório está sujeito a validação pelo MOA com vista à aceitação da entrega do projeto.
VABF: Verificação de Aptidão para Operação Adequada
Isso envolve a verificação do bom funcionamento do produto de acordo com as especificações funcionais para autorizar o comissionamento.
VSR: verificação de serviço regular
Isso envolve garantir que o produto funcione adequadamente em condições reais, seja em um local piloto ou em produção. Este período permite prestar especial atenção ao funcionamento durante os primeiros momentos de vida.
TMA: Manutenção de aplicativos de terceiros
Quando o produto está em operação, as avarias podem ser identificadas e as alterações podem ser programadas. Este trabalho é suportado por um prestador de serviços (Terceiro) dentro de um quadro contratual para manutenção corretiva e evolutiva, suporte ou trabalho operacional.
Caso de uso
Esta é a descrição de um recurso do ponto de vista do usuário. A abordagem permite identificar o contexto da funcionalidade e, sobretudo, especificar o protocolo de teste.
Os diferentes tipos de testes
Os principais testes
- Teste de unidade: Ele vem sob o MOE. Este é o teste de funcionamento adequado de uma unidade de programa, um módulo.
- Teste de integração: Ele vem sob o MOE. Isso é para garantir que as unidades de programas conjuntos funcionem bem em conjunto.
- Teste do sistema: É de responsabilidade do MOE. Também chamado de teste de certificação, trata-se de garantir a validade do todo em seu ambiente técnico alvo.
- Teste de aceitação : Ele se enquadra no MOA. É a aceitação funcional estritamente falando que leva à aceitação da entrega.
Outros tipos de testes
- Teste de migração: é de responsabilidade do MOE e do MOA. Isso é para garantir que a transição de um sistema para outro ocorra em boas condições. Muitas vezes, a migração exige que tarefas específicas sejam executadas apenas uma vez.
- Teste de segurança: É de responsabilidade do MOE e do DSI do MOA. Isso envolve garantir que as várias restrições de segurança – dados, acesso, etc. – sejam respeitadas.
- Testes de carga: É de responsabilidade do MOE e do DSI do MOA. Isso é para garantir que o produto resista bem sob carga normal e sob carga pesada. São necessários protocolos de teste automatizados.
- Teste do usuário: está sob o MOA. Trata-se de observar o comportamento dos usuários em relação ao produto para preparar sua evolução, ou um protótipo do produto para seu design.
- Teste de ergonomia: está sob o MOA ou o MOE. Um especialista em ergonomia estuda a proposta para o produto para ajustá-lo ou alterá-lo. Essa abordagem geralmente é associada a um teste de usuário.
- Testes de acessibilidade: enquadra-se no MOA ou no MOE. Isso é para garantir que o produto possa ser usado por usuários com deficiência de acordo com as restrições e regulamentos do projeto.
Testes no método de desenvolvimento ágil
Muitas vezes imaginamos que o método ágil permite superar os testes graças à integração contínua ou porque os testes unitários são escritos antes do próprio código-fonte.
Isso é apenas parcialmente verdade. É certo que a integração contínua evita muitos problemas , em particular a regressão. E testes de unidade, embora muito sólidos, ainda são testes de unidade.
Muitas vezes, diante da realidade dos processos e da produção reais , surgem deficiências e defeitos.
Por exemplo, se uma verificação de formato for bem implementada, mas não ocorrer no momento certo, um processo de entrada pode ser seriamente desafiado.
É por isso que os testes devem ser realizados, mesmo dentro da estrutura de um método ágil.
A consequência da inserção de testes é a potencial perda de agilidade. De fato, durante a aceitação de um sprint – fase que gera uma versão de um projeto ágil – a versão não está disponível para usuários finais e não podemos realmente lançar o próximo sprint .
A inserção de um teste de aceitação pode causar perda de agilidade.
Um método pode consistir em gerenciar a aceitação do sprint A em paralelo com o sprint B. Encontramos então agilidade, mas devemos gerenciar as correções do sprint A nos desenvolvimentos do sprint B.
