Desenvolvimento

Ξ Deixe um comentário

Qualidade em TI – A homologação pelo usuário / cliente

publicado por Paul Robert Bergami

Qualidade em TI – A homologação pelo usuário / clienteEm nosso último texto falamos a respeito das falhas que têm sua origem na implantação. Pouco antes da implantação temos outro ponto crítico para a qualidade em TI: a homologação pelo Usuário ou Cliente.

É a sua satisfação que sustenta a decisão pela implantação!

O que ele precisa em tempo de homologação é perceber a qualidade do software!

O que tenho visto nas organizações nesta ocasião é um debate desalinhado. O Usuário ou Cliente alertando que o prazo de implantação está chegando, que o lançamento do produto ou serviço já tem data comprometida, que não consegue perceber quais os riscos que enfrentará na produção, etc. O pessoal de TI questiona que não sabem até que ponto os Testes de Usuário foram completados, se todos as funcionalidades, todas as entradas e saídas foram validadas, se os resultados foram aprovados e assim por diante.

Uma discussão que mais parece uma “Torre de Babel”, onde cada um usa uma linguagem diferente e ninguém se entende!

A qualidade do produto ou serviço, em geral é abstrata e para que possa ser percebida, precisa ganhar corpo, ser materializada, ser quantificada, traduzida em indicadores que atinjam as expectativas do usuário ou cliente. E ainda mais, é preciso que estes indicadores falem a linguagem do “Business”, que é a razão do projeto de software.

O que proponho é que homologação não é teste – há que se transformar os Testes de Usuário em um Serviço de Homologação de Software, uma atividade de Validação , de Aceite.

Sou a favor de que o Usuário ou Cliente não deve testar o software. Isso já foi feito pela equipe de TI. A atividade de validação é o aceite e deve focar a constatação dos resultados de todos os testes efetuados anteriormente Significa que:

  • há evidência de definição de todos os requisitos para o software;
  • há evidência da tradução de todos os requisitos em condições de testes com resultados esperados;
  • há evidência de execução d as condições de testes com evidência dos resultados produzidos;
  • há evidências de que os resultados produzidos foram comparados aos resultados esperados;
  • há evidência de todos os desvios, problemas e contornos e ocorrências de execução dos testes.

Além disso, estas evidências devem ser submetidas a uma análise que resulte na visibilidade da qualidade do software a ser implantado em produção.

ž  A visibilidade da qualidade do software deve ter a aparência de um relatório de exceção, onde são reportados:

  • as condições não coberta pela execução dos testes;
  • as ocorrências dos testes e as correções e a repetição dos testes efetuados;
  • as divergências dos resultados esperados;
  • o plano de ação para estas exceções.

Parece tudo muito simples, não é mesmo?

Sim, desde que algumas providências e cuidados sejam tomados:

  • estas atividades devem ser planejadas e programadas para serem executadas desde o início do projeto;
  • a elicitação de requisitos, deve validar e qualificar os requisitos funcionais e não-funcionais classificando-os quanto a sua importância em essenciais, importantes e desejáveis e, ainda ponderado-os quanto a sua criticidade, em alta, média, ou baixa, o que indica o nível de cobertura e de resultado atingido durante os testes;
  • as qualidades e dos defeitos do software devem ser demonstrados com a sua análise de risco para o Business e seus planos de mitigação e/ou contorno;
  • estas ações devem ser tomadas antes da conversão, por serem de suporte à implantação.

Assim o Usuário ou Cliente, com este reporte, terá a visibilidade da qualidade do software, dos riscos a enfrentar durante a implantação e em produção, dos planos de contorno / mitigação que pode acionar e poderá suportar a sua decisão pela implantação ou não munido de argumentos qualificados e quantificados.

No próximo texto vamos falar de um processo auxiliar à Prevenção de Falhas em produção: Qualidade em TI – O processo de pré-produção.

[Crédito da Imagem: Usuário – ShutterStock]

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Professor de Qualidade de Software, Auditoria de Sistemas e MBA/TI, Economista pela FEA-USP com pós em Qualidade e Produtividade pela POLI-USP, especialista em qualidade de software para usuários e fornecedores de TI. Mais de 30 anos como Gestor em TI para Bancos, Consultorias, Marketing, Serviços e Governo. Focado em soluções pragmáticas de TI que aliam resultado e satisfação de clientes e acionistas, experiência internacional em London/UK no desenvolvimento de aplicativos bancários mundiais e Nova York/USA em consultoria para conformidade à Sarbanes & Oxley. br.linkedin.com/in/bergamipaul/

Paul Robert Bergami

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes