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

Em 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]