De forma a começar os testes de usabilidade, foi primeiro necessário decidir qual o formato que iria ser usado. Após alguma deliberação, o grupo optou então por usar um guião cognitivo, seguido de um curto inquérito escrito pós-teste.

Guião e Inquérito

De seguida foi decida a melhor forma de analisar. Para esse feito, fez-se recurso de um programa de captura de ecrã para gravar os testes, juntamente com o áudio. Juntamente com cada um dos utilizadores estavam presentes dois membros do grupo: um para dar apoio em qualquer questão ou dificuldade encontrada, outro para ir anotando as observações em uma grelha de análise, que mais tarde foi complementada com uma análise mais completa recorrendo aos vídeos capturados.

Grelha de análise

Execução

Os testes foram executados com alguns contratempos, o primeiro de não ter havido sala disponível para o dia em que haviam sendo agendados, o segundo de termos apenas conseguido assegurar um utilizadores experiente, pelo que tivemos de usar cinco utilizadores novatos. Aqui devemos ainda agradecer à Bárbara Macedo que nos conseguiu arranjar utilizadores suficientes para termos efectivamente seis utilizadores teste.

Um outro factor importante a ter em consideração foi o facto de termos agendado os testes para a sexta-feira antes da data de entrega dos mesmos ter sido alterada, sendo nos impossível remarcar. Assim tivemos menos tempo para angariar utilizadores e assegurar as melhores condições para realizar os testes, para além de corrigir problemas encontrados anteriormente.


Resultados e Análise Final

Tendo concluído os testes foi então possível analisar os vídeos, juntamente com os inquéritos e as observações registadas durante os mesmos. A estratégia utilizada foi a de medir o tempo demorado em cada passo contra o tempo demorado por um utilizador padrão. Seguido de uma análise da quantidade de erros dada em cada passo. Com estes dois pontos esperou-se conseguir identificar as áreas problemáticas na utilização da aplicação. Por fim iria-se fazer uma análise cruzada das respostas ao inquérito, juntamente com observações registadas na grelha e em vídeo.

Neste gráfico podemos então ver o tempo demorado pelo utilizador padrão, seguindo o mesmo guião que foi dado aos utilizadores de teste.

Neste gráfico encontram-se representados os tempos demorados em cada passo pelos seis utilizadores. É importante notar que os passos 3, 5 e 7 implicam desenho, pelo que variam conforme o tempo que cada utilizador dedicou a criar o desenho.

Nesta fase não se detectou nenhum problema grave, apesar de se notarem dificuldades com o 4º passo e o 8º passo que se verifica ser por uma certa falta de feedback.

O gráfico acima mostra os erros dados por cada utilizador em cada um dos passos, assumindo-se como erros não se ter preenchido um campo essencial ou navegar para secções contrárias às indicadas pelo guião quando tentando concretizar um dos passos.

Assim conseguiu detectar-se problemas em dois dos passos, nos quais vários utilizadores deram vários erros. Os passos em que houve problemas foram o oitavo e o nono. Após a análise notou-se que os erros no 8º passo passavam por uma falha em notar o campo de captcha que era necessário preencher, enquanto que no 9º passo, adeviam de uma combinação de falta de feedback com, novamente, o campo te captcha, para além de uma falta de familiaridade com o funcionamento dos fórums.


Conclusão

Tendo finalizado os testes e a sua análise, pode-se concluir que a maioria dos problemas encontrados eram derivados, no site em geral, de uma falta de feedback que por vezes confundia os utilizadores, relativamente a se tinham tido efeito as suas acções ou para onde ir a seguir.
Por outro lado, as dificuldades com a ferramenta de desenho em si originavam não de problemas de feedback mas de uma falta de adaptação, sendo que procuravam atalhos e as ferramentas onde se esperaria de os encontrar em ferramentas de desenho vectorial locais como o Illustrator. Um facto curioso é a falta de familiaridade com fórums e a utilização do logo do site como link que redirecciona para a homepage, assumindo apenas a existência dessa funcionalidade o utilizador experiente.
Um outro bug que persistiu ao longo dos testes foi a falha ao gravar, ocasionalmente e bastante aleatoriamente recusando-se a salvar uma imagem ou alteração.


Soluções

Para corrigir os problemas é então necessário aumentar a quantidade de feedback devolvida pela aplicação. Dar maior destaque a mensagens de erro e sucesso, esconder todos os elementos não necessários quando não em uso e tornar o captcha mais visível (algo que desde então já foi corrigido, sendo trocado por um com maior visibilidade).

Quanto ao bug de salvar estamos de momento a assumir estar resolvido, após termos colocado os quatro membros do grupo a criar imagens, utilizando diversos browsers, sistemas operativos e perfis novos e antigos, sem conseguir voltar a reproduzir o erro. Uma possibilidade no entanto é o problema não estar localizado no site em si ou na aplicação, mas sim no servidor.

O fórum também se revelou problemático devido à falta de familiaridade das pessoas, pelo que a solução poderá passar por criar um pequeno guia de utilização do mesmo, duas ou três linhas no topo, para dar alguma direcção e melhorar a legenda visto um dos erros notado foi a tentativa de clicar na legenda em vez das linhas de discussão.

A falta de familiaridade dos utilizadores com a funcionalidade do logo ser um link para a homepage também pode ser contornado, colocando um link mais visível para a página principal.

Por fim é necessário procurar resolver um bug encontrado na ferramenta de desenho, em que por vezes recusa-se a trocar a cor sem antes se clicar na palette, algo já vindo com a API do svg-edit, mas que podemos tentar resolver.


Implementações Futuras

Um dos campos do inquérito era referente a sugestões para aplicação. Uma das sugestões que se destacou era a possibilidade de criar uma resposta a um desenho, com um novo desenho, algo diferente de uma derivação, quase como competição entre os dois. É um conceito interessante e que futuramente talvez possa ser adicionado à aplicação.

Outra sugestões interessantes incluem um destaque para o melhor desenho do mês/semana (talvez uma nova criação nesse tempo que angarie o maior número de votos) e expandir a biblioteca de formas pré definidas incluídas na ferramenta de desenho.

Para os testes de compatibilidade foram utilizados os seguintes dispositivos:

1. Monitor de 24" Widescreen
2. Monitor de 19" 4:3
3. Android 3.5"
4. Magalhães
5. EeePC
6. Macbook 13"
7. iPhone 4

Tentámos abranger a maior variedade de dispositivos utilizados pelo nosso público alvo, desde dispositivos móveis com ecrãs de baixa resolução, até Desktops com grandes monitores.

Os seguintes sistemas operativos foram considerados:

1. Windows ( 7, Vista, XP)
2. Mac OSX 10.6
3. Linux Caixa Mágica

E os seguintes browsers:

1. Internet Explorer (7,8,9)
2. Mozilla Firefox
3. Google Chrome
4. Safari
5. Opera
6. Browser default do Android
7. Safari (iOS)

Para a selecção de browsers, consultámos os dados estatísticos de utilização mais recentes do site w3schools.com, de modo a saber quais os browsers mais utilizados na actualidade.

Por fim, as seguintes resoluções foram consideradas:

1. 800x600
2. 1024x768
3. 1280x800

O teste realizado consistiu no seguinte percurso:

1. Login;
2. Consulta da página de perfil;
3. Criação de um desenho na ferramenta. Gravação do mesmo;
4. Consulta do perfil de um outro utilizador. Abertura e modificação de um dos seus desenhos;
5. Comentar uma das criações de outro utilizador;
6. Logout.

Os resultados dos testes podem ser encontrados na seguinte tabela.

De maneira geral, concluiu-se que o site weDraw funciona na maioria das combinações de dispositivos utilizados actualmente. No entanto, é recomendada a utilização no Firefox ou no Chrome. É também recomendada uma resolução igual ou superior a 1024x768, já que o site é, de momento, compatível com resoluções inferiores. Também de momento a ferramenta não é compatível com dispositivos móveis (smartphones, pda's), já que a interacção e o desenho requerem as funcionalidades de um rato, não reproduzíveis em ecrãs de toque.

1. Copiar urls internos sem login para tentar aceder às páginas;
2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas;
3. Colocar valores inválidos nos campos de input e analisar a resposta do sistema;
4. Tentar aceder directamente a ficheiros e directórios;
5. Testar Captcha, submissões em massa;
6. Manter registos de tentativas falhadas;
7. Verificar encriptação na base de dados de palavras-chave. Tentar assegurar existência de salt;

• Utilizador anónimo/não registado
• Utilizador autenticado/registado
• Administrador

Sendo que o utilizador anónimo apenas tem acesso à página inicial, à ferramenta de criação e aos nós do tipo imagem, blog e fórum, embora possa apenas visualizar o conteúdo destes. A notar que na versão final haverão imagens de destaque na página inicial a que o utilizador anónimo poderá aceder. Quando às páginas de blog e de fórum, o acesso a elas será bloqueado na apenas na versão final, não se tratando no entanto de uma falha de segurança de grande gravidade.

2. Alterar parâmetros de url para tentar aceder a perfis e outras áreas exclusivas

Assim como no ponto 1, o acesso a certas funcionalidades e áreas exclusivas está limitado, tanto pelo tipo de utilizador como pela autoria e relação entre o utilizador com sessão iniciada e a página a ser visualizada. Assim, a título de exemplo, só o utilizador a que a página de perfil pertença tem acesso ao botão de edição de perfil no mesmo. Da mesma maneira, é impossível aceder à página principal de qualquer utilizador que não seja o que tem a sessão iniciada, já que o contéudo dessa é determinado pelo utilizador que tem a sessão iniciada.

3. Colocar valores inválidos nos campos de input e analisar a resposta do sistema

Este era, à partida, o ponto onde poderiam existir mais problemas. Isto devido à integração do Drupal com a ferramenta de edição e, mais especificamente, aos formulários aí presentes que poderiam não funcionar, em termos de verificação dos seus dados, ao mesmo nível de segurança dos formulários do Drupal.

Assim, testou-se a submissão de código HTML, PHP e JavaScript, tanto no formulário de login, registo e de gravação de imagem. Em todos os casos, todo o código é passada como texto simples, não havendo a hipótese de injecção de código através deste método. O mesmo acontece nos formulários nativos do Drupal.

Exemplo de tentativa de injecção de código HTML, PHP e JS.
 

4. Tentar aceder directamente a ficheiros e directórios

O acesso a directórios é impossível (o servidor retorna sempre um erro 403 - falta de permissões). Quanto a ficheiros, é possível a um utilizador que tenha conhecimento da estrutura de directórios e dos nomes dos ficheiros aceder aos mesmos, nomeadamente a todas as imagens e ficheiros svg gerados pelo editor. Contudo, há que notar que esses ficheiros são gravados com o formato nome dado à imagem pelo utilizador + timestamp unix (número único; Ex: 1306854392) + extensão do ficheiro. Assim, a menos que o utilizador tenha tido acesso ao nome do ficheiro (dentro de uma sessão iniciada, por exemplo), ser-lhe-há extremamente difícil de ganhar acesso aos ficheiros directamente. Mais, mesmo que consiga ter assim acesso aos ficheiros, não ganha com isso mais do que ganharia se fosse um utilizador registado, já que esses podem fazer download desses ficheiros de forma livre. Quando às permissões de escrita do servidor, só se encontram ligadas onde tal é necessário para o funcionamento da aplicação, como na pasta de ficheiros.

5. Testar Captcha, submissões em massa
 
(Devido a constrangimentos de tempo e de horários, não se pode testar a submissão em massa de conteudos.)

Convém notar neste ponto uma mudança importante, relativa à aplicação testada relativamente à usabilidade. O módulo usado nesses testes, captcha, foi abandonada, assim como o foi o método de captcha através de perguntas matemáticas. No seu lugar, foi adoptado o serviço anti-spam Mollom, que oferece mais opções a nível de segurança, como por exemplo:

• Verificação automática do contéudo submetido (se for considerado spam, o contéudo é automaticamente recusado. Caso o contéudo não seja obviamente spam nem contéudo genuíno, é pedido o preenchimento de um captcha);
• Personalização do tipo de verificação por formulário de submissão (permite que alguns formulários sejam controlados por captcha e outros pela análise de contéudo);
• Mais informação sobre o serviço pode ser consultada aqui.

• Injecção SQL;
• Local and Remote File Include;
• Cross-site scripting;
• Cross-site Request forgery;
• Session Security;
• Analizador de scripts (segurança de AJAX e aplicações Web 2.0);
• Teste de ferramentas de penetração;