Como teste para a aceitação do usuário e Feedback para Análise de Negócios

Depois de terminar a parte de teste de usabilidade de sua análise da implementação do projeto, que pretende testar a interface com as pessoas que vão realmente usá-lo.

Como realizar um teste de aceitação do usuário

O objectivo da teste de aceitação de usuário (UAT) é mostrar a adesão aos objetivos do projeto, não para encontrar bugs ou defeitos de software. É a fase final de testes, onde os usuários enviar o software para cenários do mundo real para verificar se ele atende às suas necessidades.

Siga estes passos para realizar o teste de aceitação do usuário:

  1. Obter um acordo com o cliente / usuário sobre os parâmetros de teste.

    Certifique-se de que você eo usuário estão na mesma página em relação aos seguintes itens:

  2. Conjunto de casos de teste de aceitação e critério de aprovação: Como o analista de negócios, você normalmente ajudar fornecendo casos de teste e cenários de teste para as pessoas que executam a UAT.

  3. Ambiente de teste: Você pode querer testar off-site ou em um local remoto se que o ambiente é o mundo real em que os usuários operar. Por exemplo, os vendedores remotos são muitas vezes em seus carros ou em hotspots Wi-Fi, para testar uma solução para eles talvez precise ocorrer em um desses locais.

  4. Os procedimentos de ensaio: Confirmar como os usuários vão testar através das condições.

  5. Vire qualquer informação sobre defeitos conhecidos no sistema.

    Este passo é benéfico por duas razões. Um deles, o seu ser aberto e honesto é melhor do que os usuários de descobrir por conta própria. Dois, você pode ter um plano de mitigação e explicar aos usuários quando eles terão uma correção para os defeitos.

  6. Deixe os usuários testar o sistema de acordo com o plano.

  7. Tenha usuários assinar no sistema, aceitando assim.

    Usuários se a assinar o teste de aceitação do usuário não só indica acceptance- também é um marco importante do projeto.

Como realizar uma avaliação do usuário pós-implementação

Embora você como o analista de negócios deve aceitar feedback sobre um sistema qualquer momento que é dado, você também deve executar uma avaliação oficial pós-implementação depois que os usuários tenham obtido treinamento sobre e usou o produto por algum tempo - geralmente cerca de 3 a 6 meses após a implementação .

O verdadeiro teste de saber se um sistema cumpre com sucesso seu objetivo é se os usuários ainda estão usando vários meses após a implementação. Se assim for, a solução foi bem sucedida e é satisfazer a necessidade. Se não, o processo quebrou em algum lugar, ou a solução de outra forma não conseguiu atender a essa necessidade.

Veja como realizar uma avaliação do usuário pós-implementação:

  1. Após o período inicial de uso de 3 a 6 meses, agendar uma sessão com os usuários de negócios para realizar uma avaliação pós-implementação.

  2. Durante a sessão, obter o feedback seja através de observação ou uma oficina facilitada.

    Obter os usuários falando. Preste especial atenção aos seus superlativos e levá-los para explicar essas declarações. Se eles dizem que o sistema é inútil, detalhar por isso que é inútil. Se eles dizem que é sempre falhando, perguntar-lhes quais ações eles executam direito antes de congelar. Afinal, você quer entender suas preocupações, porque eles podem transformá-las em futuros requisitos!

    Nota: Algumas de suas observações podem ser as métricas (medidas de tempo, esforço ou qualidade) em torno de um processo. Certifique-se de que você está familiarizado com a expectativa e venha preparado com um cronômetro!

  3. Registre suas observações e respostas dos utilizadores às suas perguntas.

  4. Dotar os participantes de sua documentação e tê-los validar as informações.

  5. Fazer as alterações finais com base no feedback dos usuários.

  6. Se necessário, fazer recomendações para os próximos passos, que podem ser um novo projeto, uma correção de manutenção, ou uma mudança no processo.

A avaliação pós-implementação não é uma sessão de reclamação (# 147-o sistema é horrível # 148-) ou um lições aprendidas sessão (que se concentra em como você pode melhorar os processos do projeto). Ele foi projetado para ser um relatório-parte de trás do produto e se / quão bem o produto atende às necessidades de negócios.

menu