O controle de qualidade em projetos web (final)
04 de novembro de 2007, 10:20Gastar tempo com Quality Assurance é evitar dores de cabeça e correrias desnecessárias ao publicar um projeto que "não funciona". O custo deste erro é multiplicado quando há insatisfação por parte dos usuários.
Por
Na sequência do artigo anterior, a fase de QA é certamente uma das mais importantes da implementação de um projeto. Tendo efetuado todos os testes planejados e executado os roteiros de teste para identificar se as regras de negócio estão sendo corretamente aplicadas, a equipe do projeto deve ser novamente envolvida, desta vez em uma navegação livre, realizada de forma aleatória, seguindo a (falta de) lógica natural dos consumidores deste produto (produto = website).
Nesta etapa, os usuários-teste deverão iniciar uma navegação desordenada verificando, sobretudo, questões ligadas à capacidade de percorrer as diferentes áreas do site e realizar seus processos de forma a não existirem barreiras que impeçam o prosseguimento.
Os erros, alterações e sugestões devem ser registradas em documentação própria, sendo possível na seqüência priorizá-las ou mesmo avaliar a real necessidade de se efetuar a alteração. Estas observações podem ser identificadas conforme:
Regra #: 001
Ocorrência: Exemplo: Botão “Limpar” não está apagando os dados do formulário
URL/Área: Endereço ou área onde ocorreu a observação
Status: Pendente - em desenvolvimento - corrigido
Observações: Orientação adicional sobre o erro
Prioridade: Alta, média ou baixa, conforme explicação a seguir
Levantar uma planilha com 50 observações não significa, contudo, em momento algum que todas as alterações devem ser realizadas. Os pontos levantados devem ser analisados pelos heads das áreas envolvidas no projeto. Neste momento, já tendo envolvido o cliente final na avaliação, deve ser definida a criticidade de cada uma das observações usando inicialmente o bom-senso e, caso ele inexista no cliente final, através de uma argumentação de que a criticidade determinará a priorização dos trabalhos.
Uma boa divisão leva em consideração três níveis de ajustes:
Alta
Erro ou ações que impeçam a navegação ou continuidade do processo a que se destina o site. Neste item podem ser incluídos erros em funcionalidades, falta de links, links de retorno, elementos de orientação, etc., desde que respeitando a arquitetura de informação especificada (e que deveria ter sido aprovada junto ao cliente final);
Média
Erros ou ações que possam comprometer o correto fluxo de navegação, entendimento ou continuidade do processo a que se destina o site mas que não impeçam o fechamento do ciclo de navegação. Usualmente estes itens estão relacionados a diferentes níveis de habilidade dos usuários e quão intuitivo ou de fácil aprendizado e o processo de navegação;
Baixa
Melhorias de conteúdo ou alterações estéticas, com finalidades distintas da melhora de usabilidade e que não são restritivas a navegação, entendimento ou continuidade de processos dentro do website.
Uma vez classificados os ajustes, começa-se obviamente a resolver os itens de prioridade alta, pois impedem a publicação do produto final. Uma vez finalizado este grupo, tem-se a primeira decisão de publicar ou não o projeto, mesmo existindo outros ajustes de níveis médio e baixo. Isto dependerá do tempo e recurso disponível para aguardar até que as demais observações (médias) sejam realizadas ou não. Os ajustes de nível médio usualmente devem ser realizados, porém, dada facilidade em se publicar novas versões na web, podem ser executados mesmo após a publicação do website.
Por experiência, na consolidação das planilhas de QA das diferentes áreas em uma única, geral do projeto, identifica-se 10% de ajustes de nível alto, cerca de 20% de ajustes de nível médio e a grande maioria corresponde a melhorias ou alterações estéticas (nível baixo).
Para este último grupo, tem-se que ter MUITO bom senso para identificar o que efetivamente é melhoria e o que é gosto pessoal. O desenvolvimento destes itens deve ser realizado após a publicação do projeto e discutido a ponto de se identificar realmente o que deve ser feito e o que pode ser simplesmente descartado.
Metodologias à parte, é imprescindível gastar este tempo de QA não para preciosismos, mas para evitar dores de cabeça e correrias desnecessárias ao publicar um projeto que “não funciona”, pois o custo deste erro é multiplicado quando trazemos à tona a insatisfação gerada nos usuários/consumidores. [Webinsider]
.
1° Rogério Pereira Data: 04/11/2007 às 3:49 pm
Atividade: Arquiteto de Informação
Cidade: Brasília
Muito interessante essa metodologia apontada por você Rodrigues. Trabalhei em algumas etapas de controle de qualidade em alguns projetos, mas tenho sentido falta disso devido aos prazos cada vez mais curtos.