Roteiro para controle de qualidade em projetos web

Na aplicação de processos de qualidade em projetos web, crie roteiros de navegação e execução de tarefas para averiguar se a resposta do sistema condiz com o esperado.

Por JC Rodrigues

Desde a saudosa reunião de briefing, dos primeiros traços e rabiscos de AI, toda equipe de atendimento, planejamento, criação e tecnologia ficou envolvida na concepção daquele que virá a ser seu mais novo orgulho (ou ao menos ocupará espaço no portfolio), um novo site.

A arquitetura de informação foi seguida, o cliente assinou o layout em sangue (por extenso) e todas as funcionalidades foram programadas de forma a atender aquele pesado documento de especificações funcionais.

Eis que chega o momento de tirar “a prova dos 9″, de “por os pingos nos is” e ver efetivamente se ‘essa coisa funciona’. “Ué, publicamos?”; Não! Claro que não, estamos apenas no final do projeto, a fase de Quality Assurance.

Mas o que é isso, afinal de contas? Como funciona?

A fase de Quality Assurance, ou Controle de Qualidade, visa averiguar se as regras de negócio especificadas estão funcionando corretamente no ambiente desenvolvido e se os demais elementos de navegação e interação atendem ao escopo pré-definido.

Faz parte do fluxo de projetos considerar a etapa de verificação da qualidade do material produzido, sejam websites, micro-sites ou material de mídia online, nos cronogramas dos projetos, preferencialmente reservando 10% do tempo total do projeto para este fim (podendo variar pra mais, caso este novo site possua integração com outros sistemas ou funcionalidades consideradas “complexas” pelo gerente de projetos).

O processo de Quality Assurance deve, entre outras coisas:

• assegurar cumprimento do escopo apresentado ao cliente;
• avaliar, testar e reportar questões ligadas à usabilidade e navegação;
• identificar, testar e reportar comportamento de funcionalidades sistêmicas;
• assegurar formatos, pesos e medidas em peças de mídia.

A fase de QA deve ser aplicada em dois momentos: um interno, realizado pela equipe envolvida no projeto, para só então - depois de solucionadas as questões mais críticas - ser aplicada também junto ao cliente final.

Para o primeiro QA, interno, fechada a entrega do job pela área de tecnologia, cabe ao profissional de atendimento ou projetos planejar a revisão das funcionalidades, que pode ser feita através de roteiros de testes para navegação controlada e/ou horas reservadas à navegação livre, além da verificação das regras de negócio e análise de usabilidade do projeto.

Deve-se criar roteiros de navegação e execução de tarefas visando averiguar se a resposta do sistema condiz com o esperado.

Estes roteiros são planejados ainda durante a fase de especificação do projeto, juntamente com as orientações funcionais passadas à área de arquitetura de informação e tecnologia. Devem identificar a área onde a função irá ocorrer, quais condições (qual perfil de usuário, sob quais variáveis), qual o resultado esperado (incluindo previsibilidade e mensagens de erro) e por suposto alguma observação no que tange estabilidade do ambiente.

Regra #: 001
Página/Área: Lista de contatos
Condições: Usuário logado como gerente administrativo
Resultado esperado: Deve poder visualizar telefones de contato de todos os funcionários
Status: OK
Obs.:

Regra #: 002
Página/Área: Lista de contatos
Condições: Usuário logado como gerente administrativo
Resultado esperado: Ao clicar no nome do funcionário, deve acessar dados cadastrais para visualização
Status: OK-Obs
Obs.: Os dados foram acessados, porém vieram de forma “editável”.

Regra #: 003
Página/Área: Lista de contatos
Condições: Usuário logado como gerente administrativo
Resultado esperado: Ao clicar em “Atualizar”, o novo telefone deve ser gravado em base de dados
Status: NÃO-OK
Obs.: Novas informações não aparecem no site”.

O status desta avaliação pode ser:

• OK: Funcionalidade correu conforme especificação;
• OK-Obs: Funcionalidade correu conforme especificação, porém apresentou ação não especificada; sua criticidade deve ser avaliada entre as áreas de Atendimento, Projetos e Planejamento;
• NÃO-OK: Funcionalidade não correu conforme especificado e deve ser remetida à área responsável para ajuste.

Não só funcionalidades podem ser avaliadas através de um roteiro de testes.

A partir de mapa do site, por exemplo, pode-se realizar navegação em cada uma das páginas/áreas verificando:

Funcionamento dos links. Avaliar níveis de navegação e links de retorno a níveis superiores. Checar necessidade de breadcrumbs, menus flutuantes, mapas, etc.

Consistência textual e visual. Verificar se os termos e expressões utilizadas ao longo do projeto são consistentes com a função e objetivo a que se destinam, assim como entre si, mantendo uma unidade na comunicação.

Por exemplo: “Imprimir” vs. “Clique para imprimir”; “Clique para retornar” vs. “Clique para voltar”. Verificar elementos visuais de ajuda, ícones de identificação de conteúdo ou ações (ex.: “Incluir no carrinho de compras”) e utilização de metáforas que visem auxiliar ou reforçar o entendimento por parte do usuário.

Respostas a erros funcionais. Verificar necessidade de incluir mecanismos de ajuda para facilitar a navegação do usuário, incluindo textos de orientação e exemplos de comportamentos e/ou preenchimento e também checar como o website comporta-se quando um usuário realiza uma ação de forma equivocada ou diferente da especificada ou necessária.

Neste item considera-se preenchimento de formulários e cadastros, ações do usuário em peças Flash etc.

Também deve ser feita a validação do projeto em diferentes sistemas operacionais (Windows, Linux, Mac) e browsers (IE, Firefox, Safari) em suas diferentes versões. A criticidade de adequação do novo site às variações do conjunto plataforma x browser dependerá do perfil dos usuários target do ambiente. Quer dizer, se é sabido que 99,98% dos usuários do sistema utilizam Internet Explorer, deve-se avaliar a relação custo-tempo para adequar uma funcionalidade que eventualmente não funcione em Firefox ou Safari.

A esta altura tende-se a acreditar que todos os problemas foram solucionados, mas errar é humano e certamente serão identificados diversos ajustes em um segundo momento, quando as equipes forem envolvidas para uma navegação livre, assunto a ser tratado num próximo artigo. [Webinsider]

.

1 pessoa comentou o artigo "Roteiro para controle de qualidade em projetos web"

Avisos

Os ítens com asterisco ( * ) são campos de preenchimento obrigatório.

Todos os links inseridos nos comentários possuem o atributo rel="nofollow" para impedir com que user agents (como os mecanismos de busca) sigam os links inseridos para desestimular spammers.

Todos devem se identificar através de e-mail válido.

Os e-mails dos usuários não serão divulgados no site.