Menu

Como você decide quais defeitos são aceitáveis ​​para a ativação do software?

how do you decide which defects are acceptable

Experimente Nosso Instrumento Para Eliminar Problemas

Software Go-Live é sempre um grande evento para qualquer produto de software. É importante ter certeza absoluta de que tudo funciona e que estamos liberando software de qualidade para os usuários .

Um produto ruim, prematuro, instável ou difícil de usar pode causar muitos prejuízos financeiros e também fazer com que o usuário perca a confiança na própria marca.

Muitas vezes, ouvimos que o teste deve ser feito até que atendamos aos critérios de saída. Também ouvimos que os defeitos devem ser corrigidos a um nível aceitável.

Embora essas sejam ótimas orientações, elas são vagas.

critérios de ativação do software

Para ser mais específico:

  • Qual porcentagem de defeitos é aceitável para o software entrar em operação?
  • Como você decide sobre os defeitos abertos com os quais o software pode entrar em operação?
  • o que tipos de defeitos são mais sérios que os outros?

Leitura recomendada => Quando parar o teste?

Você já teve essas perguntas alguma vez? Então, este artigo irá ajudá-lo a respondê-las. Leia…

Software complexo não é livre de defeitos e é uma história do ovo e da galinha sobre o fechamento de defeitos em relação ao software funcional.

Quanto mais você corrige os defeitos, é mais provável que um novo defeito seja injetado durante o fechamento do defeito. Então,

  • Como você decide sobre a extensão dos defeitos e os tipos de defeitos com os quais você pode continuar?
  • Como você define a linha de base do software a ser implantado para entrar em operação?
  • Como os coordenadores do UAT fazem a ligação para ir ao ar ou não?
  • Quais parâmetros o software deve ser julgado?
  • Como respondemos - O software é adequado para uso e trará valor para as partes interessadas?

O início da produção é um marco importante para o cliente e também para o fornecedor, pois geralmente está vinculado a marcos de pagamento. Ambos têm a mesma responsabilidade em garantir que os grandes projetos transformacionais sejam bem-sucedidos.

Minha experiência mostra que os clientes desejam seu valor pelo dinheiro e têm um critério de saída para que o UAT seja ativado.

Os referidos critérios de saída definiriam mais ou menos a extensão aceitável dos problemas em todas as áreas da aplicação, tais como:

  1. Funcional
  2. Desempenho e carga
  3. Usabilidade
  4. Segurança
  5. Integração com sistemas externos
  6. Relatórios
  7. Migração de dados

Acredito que cada um desses tipos de defeitos precisa ser explicado com mais detalhes. E é exatamente isso que faremos agora:

empresas envolvidas na internet das coisas

# 1. Defeitos funcionais:

Se o software for criado de acordo com as especificações fornecidas pelo cliente, ele deve atender aos requisitos. Quaisquer desvios são registrados como defeitos funcionais.

Defeitos funcionais são então classificados de acordo com gravidade e prioridade .

O que se segue são considerações importantes:

  • Os defeitos de alta gravidade e prioridade são geralmente os que afetariam o uso diário do software. Esses tipos de defeitos são os que devem ser corrigidos antes de entrarmos em operação. Sem exceções.
  • Às vezes, os defeitos funcionais são classificados como Solicitações de Mudança, pois não faziam parte dos requisitos fornecidos originalmente. Esses CRs, que são essenciais para que as empresas funcionem após o Go-live, também devem ser implementados.
  • A classificação de defeitos e a priorização de defeitos funcionais são feitas pelos coordenadores do UAT em colaboração com usuários de negócios e analistas de negócios. Normalmente, o cliente tem um critério de saída de quanto% dos defeitos podem ser abertos para go-live.

# 2. Defeitos de desempenho e carga:

Defeitos de desempenho são importantes a serem considerados para go-live e ainda mais se o software for usado por usuários externos.

Se o software for lento para um determinado número de usuários, os usuários evitarão usá-lo, pois ele leva muito tempo para carregar. Os usuários tendem a se mudar para o site do concorrente se o software for muito lento, perdendo negócios.

Às vezes, as partes do aplicativo que não são voltadas para o cliente também podem afetar o desempenho.

Por exemplo: Se houver um processo em lote executado no final de cada dia e se o tempo de resposta do aplicativo sofrer enquanto isso ocorre, o desempenho do lote também é um fator a ser considerado.

  • O desempenho é geralmente medido em termos de tempo de resposta das telas para renderizar e tornar-se disponíveis para os usuários enquanto houver um certo número de usuários simultâneos no sistema.
  • Os testes de desempenho são feitos usando ferramentas como LoadRunner , WebLoad , Neoload etc.
  • O desempenho do software em uma determinada carga e em uma carga futura prevista geralmente é documentado no contrato e deve ser demonstrado antes de entrar em operação.
  • As telas ou partes do aplicativo que são menos usadas pelos usuários são adiadas para avaliações após o go-live.
  • O desempenho também depende do tipo de hardware e das condições de rede em que o software é implantado.
  • Os testes de desempenho são feitos durante o UAT no hardware especificado usando ferramentas de desempenho e seus defeitos são rastreados de forma semelhante aos defeitos funcionais. Eles também são priorizados e um consenso é alcançado sobre o cumprimento dos critérios de saída para go-live.
  • Normalmente, os testes de desempenho e carga no UAT são feitos depois que o UAT funcional pelos usuários de negócios é concluído e um critério de saída aceitável para defeitos funcionais é alcançado.

# 3. Defeitos de usabilidade:

O software criado deve ser facilmente utilizável pelos usuários finais usando diferentes teclas de atalho, atalhos, o número mínimo de navegação na tela, paginação etc. O software deve ser inteligente e intuitivo.

Se houver muitos movimentos da página antes de passar para a tela apropriada, os usuários geralmente mostram menos interesse em usar o software.

  • As diretrizes de usabilidade são criadas antes da construção do software. O software deve seguir essas diretrizes.
  • Também pode haver restrições de ferramenta durante a criação do software que devem ser superadas de forma inteligente antes que o software seja utilizável pelos usuários finais.
  • Com um software altamente utilizável, um usuário final pode inserir dados até 5 vezes mais que o software normal.
  • A aparência do software deve ser nítida e também as questões legais devem ser resolvidas antes de entrar em operação.
  • Muitas vezes, um consultor de usabilidade é nomeado para garantir uma experiência de usabilidade tranquila para os usuários.
  • A documentação que deve ser fornecida com o aplicativo de software também deve aderir a diretrizes de usabilidade rigorosas, visto que podem ser usadas legalmente.
  • Os defeitos de usabilidade registrados por testadores UAT / testadores externos também são priorizados como defeitos funcionais e de desempenho e devem atender aos critérios de saída para go-live.

# 4. Defeitos de segurança:

Segurança do software é uma questão importante, pois o aplicativo de software pode ser hackeado e dados confidenciais do cliente podem ser roubados em pouco tempo.

Portanto, um software confiável não deve permitir que mesmo um hacker muito competente entre no aplicativo sem os privilégios adequados.

  • O teste de segurança é feito no UAT com entradas específicas no software para garantir que não seja hackável.
  • O teste de segurança é feito por hackers legais que tentam hackear o software para verificar se ele está vulnerável.
  • Todos os defeitos de segurança devem ser fechados antes de o sistema entrar no ar.
  • Segurança também significa login e funções e privilégios para vários usuários (externos e internos) para usar diferentes seções dos aplicativos e também para criar e aprovar dados.

# 5. Integração com sistemas de software externos:

Normalmente, um aplicativo de software que deve ser implantado no local do cliente deve fazer interface com qualquer software existente que já possa existir lá.

Por exemplo: Com o sistema de impressão, eles estão em uso ou podem ser sistemas externos, como um aplicativo de faturamento ou sistemas de tela de dados. O aplicativo de software que está sendo implantado deve se integrar perfeitamente a esses sistemas externos. Todas as entradas e saídas desses sistemas devem funcionar de forma síncrona. A tecnologia hoje engloba aplicativos móveis e diferentes plataformas de software que o aplicativo deve ser compatível com .

A verificação da interface do sistema externo deve ser realizada extensivamente durante os estágios do sistema e do UAT. Deve ser obrigatório nos critérios de saída que devem ser atendidos antes do go-live.

# 6. Relatórios:

Os relatórios do aplicativo de software são uma forma crítica de mostrar que os dados dentro do aplicativo estão sendo computados.

Por exemplo: todos os dados relacionados ao faturamento devem ser contabilizados nos saldos de crédito e débito.

  • Todos os dados do software devem ser reconciliados. Essa reconciliação de dados dentro do software é mostrada por meio de relatórios e eles devem estar funcionando conforme planejado.
  • Isso é especialmente verdadeiro se a migração de dados de um sistema antigo para um novo é a intenção principal da versão atual.

# 7. Migração de dados:

Se um sistema antigo está sendo substituído por um novo, os dados do sistema antigo são movidos para o novo (depois que uma data limite é alcançada usando o novo sistema). Os dados migrados devem ser suportados pelo novo sistema conforme definido durante a coleta de requisitos.

Todos os dados antigos podem não estar disponíveis no novo sistema; entretanto, um instantâneo dos dados antigos pode estar disponível no novo sistema. Esses dados devem estar disponíveis conforme acordado.

Observação : A lista acima não é exaustiva. Dependendo do tipo de aplicativo, pode haver mais coisas que você precisa validar ou nem tudo acima pode ser aplicável. Portanto, um entendimento completo do software, do propósito comercial, das expectativas do usuário e das dependências arquitetônicas ou de hardware é essencial para desenvolver critérios de saída abrangentes.

Um exemplo de critério de saída para go-live:

Este é apenas um exemplo. Isso pode variar de projeto para projeto.

  • 100% dos defeitos de Prioridade 1 são fechados (Severidade Crítica e prioridade 1)
  • 90% dos defeitos de prioridade 2 são fechados (severidade alta e prioridade 2) com uma solução alternativa lógica estando disponível para o restante dos 10% dos defeitos. E está disponível um plano para o fechamento dos 10% restantes dos defeitos.
  • A lista de verificação de implantação e sanidade da produção está pronta.
  • A equipe de suporte de produção foi formada e pronta para o fechamento de tickets.
  • 70% dos defeitos de prioridade 3 são fechados e um plano está em vigor para o fechamento do restante dos 30% de defeitos baixos.

Alguns pontos a serem observados:

  • Todas as definições de gravidade e prioridade são decididas durante as reuniões de negócios entre o cliente e o fornecedor no início do programa.
  • Depois que todos os defeitos do UAT forem registrados e todos os outros defeitos forem fechados, os coordenadores do UAT e os patrocinadores do negócio se reúnem para fazer um balanço dos defeitos pendentes e abertos. Se todos os defeitos necessários para a ativação do Dia 1 forem encerrados, os patrocinadores comerciais estarão prontos para a ativação e colocar o software em produção.

Em conclusão

Esperamos que este artigo tenha dado a você alguns insights sobre algumas das considerações importantes que entram na criação de critérios de saída sólidos que protegem o software de falhas em potencial nas produções.

Sobre o autor: Este é um artigo convidado de Krishnan Venkatraman. Ele tem quase 18 anos de experiência em teste de software. Ele trabalhou em muitos projetos de teste de software grandes e complexos.

Sinta-se à vontade para postar suas dúvidas / comentários abaixo.

Leitura recomendada

^