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.
![person holding black iPad](http://lacasadelamadre.com.br/wp-content/uploads/2022/04/ifsvn82xfgo-1-1024x683.jpg)
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.
![black and silver laptop computer on white table](http://lacasadelamadre.com.br/wp-content/uploads/2022/04/0xqo0y_moik-1024x683.jpg)
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.