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]
.
JC Rodrigues
JC Rodrigues (@jcrodrigues) é publicitário pela ESPM, pós-graduado pela UFRJ, MBA pela ESPM. Foi professor da ESPM, da Miami Ad School e diretor da Disney Interactive, na The Walt Disney Company.
8 respostas
Não uma planilha, mas já estamos pensando em criar um sistema on-line usando essa metodologia, para uso interno
Caro JC,
Não podemos dizer que essa metodologia explicada em seu artigo deriva da Análise Heurística?
Abraços,
Marcelo Mattei
Achei interessante o artigo, hoje a qualidade em softwares é necessário. Lembrem que estamos falando de um web site, mas a controle de qualidade deve ser relizado em todos os tipos de softwares.
As empresas ainda não perceberam que o tempo e o dinheiro utilizado no controle de qualidade não é gasto, é um recurso empregado em resolver os problemas antes que ocorram. Aumentamos o tempo em qualidade e diminuimos em retrabalho.
Interessante a abordagem simples e prática que você deu Rodrigues. Acho também que a área de engenharia de software pode emprestar muitas de suas técnicas e ferramentas para outras áreas, como projetos web. Mesmo porque estes mordem uma grande fatia no cenário de desenvolvimento de software atual. Os testes que você descreveu só dizem respeito aos testes funcionais, ou caixa-preta. Neste caso são montados os cenários de uso, tal como descritos por você. Interessante que a visão por casos de uso pode incorporar inúmeras regras de negócio em um mesmo cenário. Outro tipo de teste é chamado de caixa-branca realizado no código do software, ou da página/aplicação web. Podem ser utilizados para checar atendimento aos webstandards, padrões de acessibilidade, interoperabilidade etc.
Abordar estes aspectos daria uma visão mais completa sobre o controle da qualidade em projetos web.
Abraços, Leandro Cianconi
Sentindo falta de organização no desenvolvimento de projetos, implantei na empresa uma Gerência de Configuração baseada em SVN, TRAC e Bitten. Com TRAC consigo gerenciar todos os processo citados no artigo usando tickets, sistema de documentação Wiki entre outros. Além de integrá-lo ao SVN. O maior desafio está sendo mesmo, é treinar a equipe para usá-lo.
Você utiliza alguma documento em específico para fazer o controle de qualidade. Seria interessante fazemos um padrão.
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.