UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

SISTEMA INTEGRADO PARA GERENCIAMENTO DE TESTES DE SOFTWARE

Narcizo Thiago Maniçoba

São José, Dezembro de 2015

Orientador: Marcello Thiry, Dr Co-Orientadora: Anita Maria da Rocha Fernandes, Dra Área de Concentração: Engenharia de software Linha de Pesquisa: Qualidade e teste de software Palavras-chave: testes, defeitos, usabilidade Número de páginas: 132

i UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

SISTEMA INTEGRADO PARA GERENCIAMENTO DE TESTES DE SOFTWARE

Narcizo Thiago Maniçoba

São José, Dezembro de 2015

Orientador: Marcello Thiry, Dr Co-Orientadora: Anita Maria da Rocha Fernandes, Dra Área de Concentração: Engenharia de software Linha de Pesquisa: Qualidade e teste de software Palavras-chave: testes, defeitos, usabilidade Número de páginas: 132

RESUMO

Os testes são parte fundamental para garantir a qualidade de um software antes que ele seja usado pelo cliente, e documentar os planos de teste e os relatos de defeitos encontrados é tão importante quanto executá-los, pois dessa forma, dentre muitas vantagens, garante-se a padronização dos testes e a disseminação do conhecimento. Considerando as ferramentas para gestão de testes e as ferramentas para gestão de defeitos gratuitos mais utilizados atualmente, percebe-se que não há uma solução integrada e com boa usabilidade (considerando as 10 heurísticas de Nielsen (1993)) para documentar, na mesma ferramenta, os testes que foram executados e os defeitos que foram encontrados durante os testes de software. Além disso, essas ferramentas não empregam conceitos de usabilidade, então a equipe tende a não documentar ou documentar apenas uma parte dos testes e defeitos pois tem que usar, no mínimo, duas ferramentas e a usabilidade não é boa. Diante desses fatos, o objetivo deste trabalho foi desenvolver uma única ferramenta que contemple as funcionalidades essenciais presentes nas ferramentas gratuitas de gestão de testes e nas ferramentas gratuitas de gestão de defeitos disponíveis no mercado utilizando-se conceitos de usabilidade. Com uma ferramenta integrada, acredita-se que o cruzamento dos testes x defeitos fiquem mais evidentes e os dados sejam melhor aproveitados para análise posterior. Tendo uma ferramenta com boa usabilidade, busca-se despertar o interesse na equipe em documentar os testes e defeitos de maneira correta.

ii LISTA DE FIGURAS

Figura 1. Custo relativo para corrigir um defeito...... 20 Figura 2. Relação do custo da qualidade para prevenir e corrigir defeitos...... 21 Figura 3. Definição de defeito, erro e falha...... 22 Figura 4. Causas de defeitos durante o desenvolvimento do software...... 23 Figura 5. Dimensões dos testes...... 25 Figura 6. Modelo V: paralelismo entre as atividades de desenvolvimento e teste de software...... 32 Figura 7. Relação entre coisas óbvias e coisas que fazem o usuário pensar...... 35 Figura 8. Exemplo de elementos aninhados visualmente...... 36 Figura 9. Exemplo de correta aplicação da heurística Visibilidade do Estado do Sistema ...... 37 Figura 10. Exemplo de correta aplicação da heurística Compatibilidade entre Sistema e Mundo Real 37 Figura 11. Exemplo de correta aplicação da heurística Liberdade e Controle do Usuário...... 38 Figura 12. Exemplo de violação da heurística Consistência e Padrões...... 38 Figura 13. Exemplo de violação da heurística Prevenção de Erro...... 39 Figura 14. Exemplo de violação da heurística Ênfase no Reconhecimento...... 40 Figura 15. Exemplo de violação da heurística Flexibilidade e Eficiência no Uso...... 40 Figura 16. Exemplo de violação da heurística Auxílio, Diagnóstico e Recuperação de Erros...... 41 Figura 17. Popularidade das ferramentas bug trackers open source...... 45 Figura 18. Popularidade das ferramentas bug trackers open source e comerciais...... 46 Figura 19. Comparativo Bloodhound, Bug-A-Boo, BugNET, BugTracker e ...... 47 Figura 20. Comparativo Eventum, Flyspray, , JTrac e Kwok bug tracker...... 48 Figura 21. Comparativo Mantis, oops-easytrack, phpBugTracker, e ...... 48 Figura 22. Comparativo , RTH, Scarab, e WebIssues...... 49 Figura 23. Comparativo zenTrack...... 50 Figura 24. Popularidade das ferramentas de gestão de testes open source...... 52 Figura 25. Comparativo QATraq, Radi-testdir, RTH e Sitechco...... 53 Figura 26. Comparativo Tesly, Test Case Web, Testia Tarantula e Testitool...... 54 Figura 27. Comparativo TestLink, Testmaster e Testopia...... 54 Figura 28. TestLink: página principal...... 56 Figura 29. TestLink: links do menu superior representados por ícones pequenos e sem labels...... 59 Figura 30. TestLink: campo de pesquisa na barra superior é somente para casos de teste...... 60 Figura 31. TestLink: botão criar usuário posicionado após a tabela...... 61 Figura 32. TestLink: usuário precisa digitar um ID único ao cadastrar um novo projeto...... 62 Figura 33. TestLink: página de pesquisa de requisitos...... 63 Figura 34. TestLink: página de pesquisa de casos de teste...... 63 Figura 35. TestLink: página de pesquisa de casos de teste criados por usuário...... 64 Figura 36. TestLink: é necessário clicar no ícone para mostrar as opções da Suíte e Caso de teste...... 64 Figura 37. TestLink: é necessário saber o id do caso de teste antes de criar a relação...... 65 Figura 38. Testopia: página de visualização do estado das execuções dos testes...... 66 Figura 39. Testopia: menu com as operações para gestão de defeitos e testes...... 67 Figura 40. Testopia: é necessário pressionar Enter após digitar o termo de pesquisa no campo...... 68 Figura 41. Testia Tarantula: página de execução de casos de teste...... 69 Figura 42. Testia Tarantula: página de visualização dos usuários cadastrados...... 71 Figura 43. Testia Tarantula: página de adição de casos de teste ao plano de teste...... 72 Figura 44. Mantis: página principal...... 73 Figura 45. Mantis: formulários não apresentam a opção Cancelar...... 75

iii Figura 46. Mantis: permite anexar apenas um arquivo por vez no relato de defeito...... 75 Figura 47. Mantis: ações “Monitorar” e “Marcar como Pegajoso” não são óbvias para o usuário...... 75 Figura 48. Mantis: relação entre relatos de defeito obriga o usuário a saber o número do caso...... 76 Figura 49. Bugzilla: página de pesquisa de relatos de defeito...... 77 Figura 50. Bugzilla: página de seleção de projeto para pesquisa de defeitos...... 79 Figura 51. Bugzilla: página de seleção do componente do projeto para pesquisa dos defeitos...... 80 Figura 52. Bugzilla: permite anexar apenas um arquivo por vez no relato de defeito...... 80 Figura 53. Bugzilla: histórico de modificações do relato de defeito...... 81 Figura 54. Bugzilla: títulos das páginas são apresentadas acima do menu superior...... 81 Figura 55. BugNET: Página principal...... 82 Figura 56. BugNET: permite anexar apenas um arquivo por vez no relato de defeito...... 84 Figura 57. Ferramenta proposta: tela de pesquisa de projetos cadastrados...... 96 Figura 58. Ferramenta proposta: tela de execução dos casos de teste...... 97 Figura 59. Ferramenta proposta: tela de cadastro de relato de defeito...... 98 Figura 60. Ferramenta proposta: tela de visualização de relato de defeito...... 99 Figura 61. Camada Usuário da modelagem de Entidade Relacionamento do sistema...... 100 Figura 62. Camada Projeto da modelagem de Entidade Relacionamento do sistema...... 101 Figura 63. Camada Requisito da modelagem de Entidade Relacionamento do sistema...... 102 Figura 64. Camada Teste da modelagem de Entidade Relacionamento do sistema...... 103 Figura 65. Camada Defeito da modelagem de Entidade Relacionamento do sistema...... 104 Figura 66. Camada Comum da modelagem de Entidade Relacionamento do sistema...... 105 Figura 67. Visualização de um requisito cadastrado...... 106 Figura 68. Formulário de cadastro de caso de teste e a relação com requisito...... 107 Figura 69. Cadastro de plano de teste e definição de execução dos casos de teste...... 108 Figura 70. Criação de defeito através da tela de execução de caso de teste...... 109 Figura 71. Defeito registrado associado ao caso de teste executado...... 109 Figura 72. Visualização do defeito e as relações com o caso de teste e o requisito...... 110 Figura 73. Visualização do relatório Visão Geral do Plano de Teste...... 111 Figura 74. Mensagens de feedback fornecidas ao usuário...... 114 Figura 75. Validações dos campos realizada em tempo real...... 115

iv LISTA DE TABELAS

Tabela 1. Escala para classificação dos problemas de usabilidade...... 42 Tabela 2. Seleção das ferramentas de gestão de defeitos...... 43 Tabela 3. Seleção das ferramentas de gestão de testes...... 51 Tabela 4. Avaliação de requisitos das ferramentas avaliadas...... 86 Tabela 5. Colaboradores selecionados para avaliar a ferramenta Testicida...... 116 Tabela 6. Considerações dos participantes em relação ao aspecto facilidade de uso...... 116

v LISTA DE ABREVIATURAS E SIGLAS

HTML HyperText Markup Language LDAP Lightweight Directory Access Protocol PDF Portable Document Format PHP PHP: HyperText Preprocessor TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí XML eXtensible Markup Language PABX Private Automatic Branch Exchange

vi SUMÁRIO

1 INTRODUÇÃO ...... 9 1.1 PROBLEMA DE PESQUISA...... 11 1.1.1 Solução Proposta ...... 11 1.1.2 Delimitação de Escopo ...... 12 1.1.3 Justificativa ...... 12 1.2 OBJETIVOS ...... 13 1.2.1 Objetivo Geral ...... 13 1.2.2 Objetivos Específicos ...... 13 1.3 METODOLOGIA ...... 14 1.3.1 Metodologia da Pesquisa ...... 14 1.3.2 Procedimentos Metodológicos ...... 15 2 FUNDAMENTAÇÃO TEÓRICA ...... 18 2.1 TESTE DE SOFTWARE ...... 18 2.2 DEFEITOS DE SOFTWARE...... 21 2.3 DIMENSÕES DOS TESTES ...... 24 2.3.1 Técnicas de Teste ...... 25 2.3.2 Níveis de Teste ...... 26 2.3.3 Tipos de Teste ...... 28 2.4 PROCESSO DE TESTE ...... 31 2.5 USABILIDADE DE SOFTWARE ...... 34 3 FERRAMENTAS ...... 43 3.1 CRITÉRIOS PARA SELECIONAR FERRAMENTAS ...... 43 3.2 SELEÇÃO DAS FERRAMENTAS ...... 43 3.3 CRITÉRIOS PARA AVALIAR AS FERRAMENTAS ...... 55 3.4 AVALIAÇÃO DAS FERRAMENTAS ...... 55 3.4.1 TestLink Test Management Tool ...... 55 3.4.2 Testopia ...... 65 3.4.3 Testia Tarantula ...... 68 3.4.4 ...... 72 3.4.5 Bugzilla Bug-Tracking System ...... 76 3.4.6 BugNET ...... 81 4 A FERRAMENTA TESTICIDA ...... 85 4.1 LINGUAGENS DE PROGRAMAÇÃO ...... 85 4.2 ANÁLISE DE REQUISITOS ...... 86 4.3 MODELAGEM DO SISTEMA ...... 95 4.3.1 Modelagem da Interface de Usuário ...... 95 4.3.2 Modelagem Entidade Relacionamento ...... 99 4.4 IMPLEMENTAÇÃO ...... 105

7 5 AVALIAÇÃO DA FERRAMENTA TESTICIDA ...... 112 5.1 AVALIAÇÃO DOS REQUISITOS FUNCIONAIS ...... 112 5.2 AVALIAÇÃO DE USABILIDADE ...... 112 5.3 AVALIAÇÃO COM USUÁRIOS ...... 115 6 CONCLUSÃO ...... 118 6.1 TRABALHOS FUTUROS ...... 118 Apêndice A ...... 122

8 1 INTRODUÇÃO

Nos tempos atuais, praticamente ninguém consegue completar um dia, seja à trabalho ou lazer, sem recorrer ao uso de softwares. Eles estão presentes em quase todos os dispositivos usados pelas pessoas, apesar de em alguns casos passarem despercebidos. Um exemplo são os automóveis, que cada vez mais agregam o uso do software, desde o entretenimento de um sistema de rádio até o acionamento de dispositivos de segurança como os airbags. Além de estarem presentes em eletroeletrônicos, sistemas de segurança, sistemas bancários, sistemas de linhas de montagem de indústrias, sistemas de transportes, hospitais, usinas nucleares, entre outros. Portanto, a influência dos softwares no dia a dia dos seres humanos é cada vez maior, seja para proporcionar momentos de lazer ou fazer o seu trabalho de forma eficaz e eficiente. Por outro lado, possíveis defeitos presentes nos softwares podem causar- lhes frustação por não conseguirem realizar a tarefa desejada, acarretar-lhes sérios prejuízos financeiros, danos morais, danos materiais ou até mesmo mortes.

Cientes destes riscos e com o objetivo de agregar confiabilidade e qualidade aos softwares, autores como Myers, Badgett e Sandler (2011), Pressman (2006) e Pfleeger (2004), definem o processo de teste como sendo o ato de executar um software com o objetivo de encontrar defeitos e, além disso, verificar se o comportamento do software está de acordo com os requisitos levantados junto ao cliente fazendo o que deve fazer e não fazendo o que não deve fazer.

Ferramentas de gestão de teste auxiliam a equipe de software no planejamento da estratégia de teste escolhida e na gestão do processo de teste enquanto ele é conduzido. Tratam do planejamento de teste, armazenamento de teste, gestão e controle, monitoramento de requisitos, integração, monitoramento de erros e geração de relatórios. Gerentes de projeto usam-nas para suplementar as ferramentas de cronograma de projetos. Os testadores usam para planejar as atividades de teste e para controlar o fluxo de informação enquanto o processo de teste prossegue (PRESSMAN, 2006).

Tais ferramentas podem ser utilizadas para criação dos casos de teste, que descrevem condições particulares a serem testadas e são compostos por valores de entrada, restrições para a sua execução e resultados ou comportamentos esperados (CRAIG & JASKIEL, 2002).

O autor deste trabalho possui experiência de seis anos com testes de software em empresas localizadas na região da grande Florianópolis. Os dois primeiros anos em uma empresa que possuía um processo de testes mais adequado, se comparado com o que é apresentado pelos principais autores na

9 área de Engenharia de Software. Nesta empresa, os testes eram escritos na ferramenta TestLink1 e os defeitos eram registrados na ferramenta Bugzilla2. Os outros quatro anos, em uma empresa que utilizava apenas o Mantis3 para registro de defeitos encontrados e acompanhamento da resolução. A partir destas duas experiências, pode-se comentar que a primeira possuía resultado mais eficaz quanto aos testes de software do que a segunda experiência, pois, além dos defeitos encontrados, os casos de teste que deveriam ser executados também eram documentados e organizados em um plano de teste. Isto claramente minimizava a ocorrência de requisitos não serem testados corretamente e, desta forma, a maior quantidade possível de defeitos era encontrada antes do software ser liberado para produção. Vale ressaltar que o produto e mercado de atuação destas duas empresas é semelhante.

Existem ferramentas gratuitas disponíveis, mas enquanto algumas oferecem a gestão dos planos de teste, como o TestLink e o Testia Tarantula4, outras oferecem a gestão dos defeitos, como o Mantis e o Bugzilla. Estas quatro ferramentas, que são as mais populares e foram avaliadas por este trabalho com base nos 10 princípios heurísticos de usabilidade de Nielsen (1993), não apresentam boas práticas de usabilidade. Além disto, o usuário acaba tendo que usar pelo menos duas ferramentas diferentes. Nas pesquisas prévias para elaboração deste trabalho, foi encontrada a ferramenta RTH5 que oferece os dois, porém sua interface possui ausência de boas práticas de usabilidade ainda mais evidente, oferece poucas funcionalidades e não recebe atualizações há pelo menos uma década, o que pode explicar o fato desta não ser uma das ferramentas mais populares e utilizadas de acordo com as pesquisas realizadas por este trabalho.

Dentro deste contexto, a proposta desse trabalho foi desenvolver uma ferramenta que englobe o cadastro de requisitos funcionais, não funcionais e regras de negócio, gestão dos testes e gestão dos defeitos. Com esta integração busca-se aprimorar a usabilidade, utilizando-se como base os 10 princípios heurísticos de Nielsen (1993), e possibilitar o armazenamento e associação das informações dos planos de teste com os defeitos encontrados.

1 TestLink: ferramenta para gestão de testes de software 2 Bugzilla: ferramenta para gestão de defeitos. 3 Mantis: ferramenta para gestão de defeitos. 4 Testia Tarantula: ferramenta para gestão de testes de software 5 RTH: ferramenta para armazenamento de requisitos, gestão de testes e gestão de defeitos.

10 1.1 PROBLEMA DE PESQUISA

Analisando os fatos supracitados, fica evidente que o ato de executar casos de teste em um produto de software tem um objetivo bem claro: encontrar defeitos. Estes defeitos devem ser preferencialmente registrados em ferramentas, assim como os casos de teste que permitiram identificá- los também devem estar armazenados.

Existe uma relação muito próxima entre um caso de teste e um relato de defeito encontrado, mas na prática não é o que se vê na grande maioria das ferramentas gratuitas de apoio a teste de software. Normalmente tem-se uma ferramenta para gerenciar os casos de teste e outra para gerenciar os defeitos. O testador, que é geralmente o responsável por executar os testes, tem que operar duas ferramentas para executar suas atividades. E, dependendo das ferramentas utilizadas ainda se faz necessário o uso de uma terceira ferramenta (, pacote Office) para documentar procedimentos técnicos para apoio à execução dos testes como, por exemplo, a configuração de um cenário para execução dos testes, um documento complementar ou até mesmo o relatório de teste.

Além de operar duas ou mais ferramentas, existe o fato de essas ferramentas possuírem características diferentes de interface de usuário, autenticação, usabilidade. E, em se tratando de usabilidade, tem-se o segundo problema encontrado também na grande maioria das ferramentas de apoio a teste de software: a ausência de boas práticas de usabilidade com base nos 10 princípios heurísticos de Nielsen (1993).

Observou-se que ferramentas como TestLink permitem também o cadastramento de requisitos do software a ser testado, de forma básica, mas que permite o relacionamento com casos de teste que deverão ser criados.

Sendo assim, a proposta de uma ferramenta que englobe cadastro de requisitos, gestão de testes e gestão de defeitos é pertinente.

1.1.1 Solução Proposta

Este trabalho buscou desenvolver uma nova ferramenta Web gratuita que integre e relacione o cadastramento de requisitos, a gestão de testes e gestão de defeitos na mesma ferramenta.

Para alcançar o objetivo deste trabalho, pesquisou-se por ferramentas Web de gestão de testes e de defeitos com o intuito de identificar os requisitos indispensáveis para o desenvolvimento da ferramenta proposta por este trabalho. Foi avaliada também a usabilidade destas ferramentas como forma de encontrar alternativas melhores para implementar na nova ferramenta.

11 Como hipótese trabalhada nesta pesquisa tem-se: a gestão dos testes a serem executados e a gestão de defeitos encontrados integrados em uma única ferramenta com boa usabilidade pode aumentar a efetividade das empresas no que tange o processo e documentação de testes.

1.1.2 Delimitação de Escopo

A pesquisa para mapeamento dos requisitos necessários para desenvolver esta ferramenta integrada foi feita apenas por softwares gratuitos de gestão de testes e gestão de defeitos. Com base nesses requisitos, esta ferramenta terá limitações, descritas a seguir.

O módulo de gestão de testes não tem suporte à execução de casos de testes automatizados nem integração com softwares de automatização de testes. Não há suporte à integração com ferramentas de gestão de defeitos externos (bug trackers6), pois pretende-se que a ferramenta possua seu próprio módulo de gestão de defeitos integrado. Nos módulos de gestão de testes e gestão de defeitos, os relatórios disponíveis podem ser exportados apenas nos formatos (HTML) e (PDF). Quanto ao workflow para resolução de defeitos, não será possível customizar nome e quantidade das etapas. Não haverá suporte a outros idiomas além do Português (Brasil). Será desenvolvido em linguagem de programação PHP integrado a um banco de dados MySQL. Não serão suportados outros tipos de banco de dados. Haverá suporte ao protocolo LDAP apenas para autenticação dos usuários.

1.1.3 Justificativa

O primeiro relato de defeito em um sistema de computação de que se tem conhecimento, oficialmente, é datado de 9 de Setembro de 1947. Época em que o computador em questão, um Mark II da Universidade de Harvard, ainda não executava software. Seu funcionamento era eletromecânico. Grace Hopper, analista de sistemas da Marinha dos Estados Unidos, registrou a próprio punho em uma folha de caderno a operação realizada no computador e a ocorrência de um defeito. Poucas horas depois, a causa do defeito foi registrada e colada com fita adesiva. Uma mariposa foi encontrada em meio aos componentes eletrônicos causando um mau funcionamento. Um bug7 foi encontrado (RILEY; GOUCHER, 2010).

6 Bug Trackers: ferramentas que gerenciam os relatos de defeitos encontrados em projetos de desenvolvimento de software. 7 Bug: termo da língua inglesa que significa, no contexto da computação, um erro no funcionamento de um software ou hardware.

12 Os computadores atuais não são mais eletromecânicos, tampouco possuem válvulas. Portanto, as causas mais prováveis de defeitos em sistemas de computação há muito tempo deixaram de ser os insetos, mas o termo bug ainda é comumente utilizado porque os defeitos em software ainda ocorrem. O relato de quase setenta anos atrás mostra que o defeito está intimamente relacionado, presumivelmente, com o procedimento de teste que revelou o defeito, porém são informações essenciais que não são documentadas em muitos relatos de defeitos contemporâneos (RILEY; GOUCHER, 2010).

Desde aquela época, os sistemas evoluíram exponencialmente e tornaram-se cada vez mais complexos. E quanto mais complexo for o software, como um sistema distribuído ou em tempo real, maior a probabilidade do teste se tornar complexo. O grande número de pessoas envolvidas no desenvolvimento e nos testes pode tornar a coordenação difícil. Para controlar a complexidade e a dificuldade dos testes, utiliza-se uma documentação completa e cuidadosa do teste projetado (PFLEEGER, 2004).

Considerando que ferramentas populares gratuitas não oferecem a integração de requisitos, gestão de testes e gestão dos defeitos, este trabalho busca desenvolver uma ferramenta que integre e relacione a gestão destas informações na mesma ferramenta e que, sobretudo, possua boa usabilidade. Acredita-se que, com um sistema desse tipo, as empresas possam aumentar a efetividade da documentação dos testes aplicados nos softwares.

1.2 OBJETIVOS

Esta seção detalha os objetivos geral e específicos do trabalho, conforme descritos a seguir.

1.2.1 Objetivo Geral

Desenvolver uma ferramenta integrada, empregando as 10 heurísticas de usabilidade de Nielsen (1993), para gerenciamento de teste de software que contemple o armazenamento e relação dos requisitos com a gestão dos testes e a gestão dos defeitos de software.

1.2.2 Objetivos Específicos

1. Com base na avaliação a ser feita nas ferramentas existentes, mapear os requisitos de um ambiente integrado para a gestão de testes e de defeitos com foco nos Níveis de Teste de Sistema e de Aceitação utilizando a Técnica de Testes Caixa-preta;

2. Definir os requisitos funcionais, não funcionais e regras de negócio para serem incluídos na nova ferramenta de gestão de testes;

13 3. Desenvolver a ferramenta;

4. Avaliar a adequação e a usabilidade (com base nas 10 heurísticas de Nielsen (1993)) no contexto de uma organização de desenvolvimento de software.

1.3 METODOLOGIA

Nesta seção será apresentada a metodologia de pesquisa a ser utilizada por este trabalho.

1.3.1 Metodologia da Pesquisa

Este trabalho baseou-se no método indutivo. Este método considera que o conhecimento é fundamentado na experiência, não levando em conta princípios preestabelecidos. No raciocínio indutivo a generalização deriva de observações de casos da realidade concreta. As constatações particulares levam à elaboração de generalizações (GIL, 1999; LAKATOS; MARCONI, 1993).

Considerou-se este método o mais adequado, pois este trabalho se baseia na experiência oferecida por ferramentas existentes para gestão de testes e defeitos e na experiência adquirida pelo próprio autor deste trabalho com algumas delas ao longo de seis anos atuando com testes de software. Busca-se observar as funcionalidades oferecidas por tais ferramentas e seus problemas de usabilidade a fim de realizar as constatações particulares relativas à este trabalho.

Sob o ponto de vista da natureza, este trabalho utiliza a metodologia de pesquisa aplicada, por gerar conhecimentos para aplicação prática e dirigidos à solução de problemas específicos (GIL, 1999; LAKATOS; MARCONI, 1993).

A pesquisa aplicada, para este trabalho, implica na constatação de que uma ferramenta integrada para gerenciamento de testes e defeitos, com boa usabilidade, terá uma maior probabilidade de ser adotada pelas empresas em seu processo de testes do que duas ou mais ferramentas integradas. E, também, ser adotada por empresas que possuam interesse em iniciar a gestão de seus testes com o apoio de uma ferramenta.

Sob o ponto de vista da abordagem, a metodologia utilizada foi a de pesquisa qualitativa, a qual considera haver uma relação dinâmica entre o mundo real e o sujeito, isto é, um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito que não pode ser traduzido em números. Não requer o uso de métodos e técnicas estatísticas (GIL, 1999; LAKATOS; MARCONI, 1993).

A pesquisa qualitativa foi escolhida pelo fato de que este trabalho não fará um estudo estatístico com apresentação e comparação de números obtidos, e sim uma análise das ferramentas

14 existentes para avaliar seus requisitos e a usabilidade. Dessa forma, elencar os requisitos essenciais para o desenvolvimento da ferramenta almejada por este trabalho.

Sob o ponto de vista do objetivo, esta pesquisa utilizou o método exploratório, pois visa proporcionar maior familiaridade com o problema com o objetivo de construir a hipótese. E, para alcançar tal objetivo, houve um levantamento bibliográfico e estudo de caso com base na experiência do próprio autor deste trabalho com algumas destas ferramentas existentes.

1.3.2 Procedimentos Metodológicos

Para alcançar o objetivo principal deste trabalho, que foi desenvolver uma ferramenta integrada de requisitos, gestão de testes e gestão de defeitos com boa usabilidade, etapas foram estabelecidas.

Inicialmente, realizou-se uma pesquisa bibliográfica relacionada aos conceitos de teste e defeito de software na qual descobriu-se a importância dos testes para detectar a presença de defeitos em um software evitando assim que esses defeitos sejam descobertos pelo cliente ou usuário final.

Aprofundando-se um pouco mais nos conceitos referentes à testes de software, efetuou-se uma pesquisa bibliográfica para obtenção de conhecimento sobre as dimensões que o teste pode assumir ao longo do processo de desenvolvimento. Através desse conhecimento adquirido sobre os níveis, estratégias e tipos de teste que podem ser aplicados ao software, delimitou-se o escopo que a ferramenta que será construída a partir deste trabalho irá contemplar.

Após a pesquisa sobre as dimensões dos testes, iniciou-se a pesquisa sobre o processo de teste. Através desta pesquisa foi possível entender quais etapas, recursos (incluindo pessoas), artefatos, entre outros, compõem um processo. Muito útil para saber quais componentes a ferramenta precisará ter para contemplar um processo básico de teste e, sobretudo, armazenar os dados do processo.

Conceitos de usabilidade também foram pesquisados, bem como boas práticas para construir interfaces que proporcionam uma boa experiência ao usuário e critérios para avalia-las. Essa pesquisa foi de grande valia, pois serviu para a avaliação de usabilidade das ferramentas selecionadas e para a prototipação das telas da ferramenta a ser desenvolvida.

Para selecionar as ferramentas avaliadas neste trabalho, foram estabelecidos critérios. Com as ferramentas selecionadas, um conjunto de critérios para avaliação de usabilidade, sugerido por um dos autores pesquisados, foi escolhido.

Definidas as ferramentas e os critérios para avalia-las, a avaliação foi executada com dois objetivos. O primeiro, de avaliar as ferramentas para tentar identificar os problemas de usabilidade que

15 pudessem ser corrigidos na concepção da ferramenta proposta por este trabalho. Este objetivo foi alcançado, pois foram observados muitos exemplos que não devem ser seguidos. O segundo, de listar os requisitos considerados essenciais e que devem ser desenvolvidos. Também satisfeito, pois observou-se os requisitos comuns presentes nas ferramentas de gestão de testes e os requisitos comuns nas ferramentas de gestão de defeitos.

1.3.2.1 Plano de trabalho

Este trabalho abrange sete etapas, descritas a seguir:

1. Revisão Bibliográfica: esta etapa não está associada a um objetivo diretamente, porém forneceu o embasamento teórico para a execução de todas as demais etapas do trabalho.

2. Análise e identificação das ferramentas de gerenciamento de testes e de gerenciamento de defeitos gratuitas mais utilizadas: nessa etapa foi feita uma pesquisa com o objetivo de identificar quais as ferramentas gratuitas de gestão de testes e de defeitos mais utilizadas.

3. Análise e identificação das funcionalidades essenciais: foram analisadas quais as funcionalidades em comum entre as ferramentas de gestão de testes e depois entre as ferramentas de gestão de defeitos com o objetivo de identificar quais as funcionalidades essenciais extraídas desse comparativo para constituírem uma ferramenta integrada. Também foi avaliada a necessidade de incluir novas funcionalidades que fossem um diferencial da nova ferramenta integrada ou recomendada por autores, normas, entre outros.

4. Estabelecimento dos critérios considerados para mensurar a eficácia e usabilidade das funcionalidades: com base nas funcionalidades identificadas, foi adotada uma metodologia para realizar a avaliação de usabilidade das interfaces das ferramentas selecionadas.

5. Modelagem da ferramenta: foi adotada uma metodologia para descrever as características e comportamentos da nova ferramenta integrada construída.

6. Desenvolvimento e testes da ferramenta: com base na modelagem realizada, a ferramenta foi codificada. Na medida em que as unidades e módulos foram implementados, aplicaram- se testes de unidade e de integração para verificar se a construção estava em conformidade com a modelagem realizada.

7. Testes de sistema e de aceitação: nessa etapa foram executados os testes de sistema para validar as funcionalidades implementadas e, posteriormente, foram escolhidos profissionais

16 da área de teste e qualidade de software para realizarem os testes de aceitação da ferramenta.

17 2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo será detalhada a fundamentação teórica necessária para o desenvolvimento deste trabalho. Nele são apresentados a definição de teste e defeito de software, dimensão dos testes, planejamento, processo, documentação dos testes e usabilidade de software.

2.1 TESTE DE SOFTWARE

O teste de software é definido por muitos autores como sendo o processo de executar um software com o objetivo de encontrar defeitos e, além disso, verificar se o comportamento do software está de acordo com os requisitos levantados junto ao cliente (MYERS; BADGETT; SANDLER, 2011; PRESSMAN, 2006; PFLEEGER, 2004).

Myers, Badgett e Sandler (2011) acreditam que uma das principais causas de testes de aplicativos pouco eficazes dá-se pela forma com que a maioria dos programadores ou até mesmo testadores pensam sobre o objetivo dos testes. Eles podem achar que o teste é o processo de demonstração de que os defeitos não estão presentes ou que o objetivo do teste é mostrar que um software executa suas funções corretamente. Essas definições são contrárias ao objetivo do teste de software, pois este deve ser executado com o objetivo de acrescentar valor, neste caso elevando a qualidade ou a confiabilidade do software.

Aumentar a confiabilidade do software significa encontrar e remover defeitos. Portanto, um software não deve ser testado para mostrar que ele funciona, e sim considerar a suposição de que o software contém defeitos, que é uma suposição válida para quase todo software. Em seguida, testar o software para encontrar o maior número de defeitos possível. Assim, a definição mais adequada é de que o teste é o processo de execução de um software com o intuito de encontrar defeitos (MYERS; BADGETT; SANDLER, 2011).

Compreender a verdadeira definição pode fazer uma profunda diferença, pois se o objetivo é demonstrar que um software não tem defeitos, então se pode subconscientemente ser induzido para este objetivo, ou seja, a tendência é selecionar os dados de teste que têm uma baixa probabilidade de causar falhas no software. Por outro lado, se o objetivo é demonstrar que um software tem defeitos, os dados de teste terão uma maior probabilidade de detecção de defeitos (MYERS; BADGETT; SANDLER, 2011).

De acordo com Peters e Pedrycz (2001), o teste de software determina quando um sistema de software pode ser liberado. A definição deste autor aborda uma questão muito importante para o

18 processo de teste de software: quando é o momento correto para interromper os testes e liberar o software tendo-se a certeza de que todos os defeitos foram encontrados?

Para Pressman (2006), não há uma resposta definitiva para esta pergunta, contudo ele cita que uma possível resposta é de que a tarefa de teste não acaba no momento da liberação do software, ela passa da equipe de testes para os usuários finais. O software continua sendo testado a cada vez que o usuário o executa para utilizar suas funcionalidades.

Myers, Badgett e Sandler (2011) e Paula Filho (2003) reforçam esta teoria dizendo que testes exaustivos são geralmente impossíveis, mesmo para produtos relativamente simples. Por exemplo, para testar um software cuja entrada seja um texto de dez caracteres, seria necessário analisar 2610 combinações. Enquanto muitos desses testes são redundantes, a utilização de força bruta pode deixar muitos casos com alta probabilidade de defeitos sem serem descobertos, como entradas com mais de 10 caracteres. Portanto, deve-se focar nos testes que tenham a mais alta probabilidade de descobrir defeitos com o mínimo de esforço.

Outra resposta provável é de que o teste acaba quando os recursos de tempo e dinheiro também acabam (PRESSMAN, 2006).

Segundo Myers, Badgett e Sandler (2011), os custos para a correção de defeitos tende a aumentar quanto mais tarde são detectados. Isto é, um defeito detectado já em fase de produção pode custar até 1000 vezes mais que o mesmo defeito previamente detectado na fase de requisitos, como mostra a Figura 1.

19

Figura 1. Custo relativo para corrigir um defeito. Fonte: Myers, Badgett e Sandler (2011).

Portanto, quanto menos defeitos permanecerem no software, menor será o custo da sua manutenção no futuro.

Diante desses fatos, é desejável que o momento de liberação do software seja o mais assertivo possível para possibilitar que a quantidade e gravidade dos defeitos encontrados após a liberação sejam os menores possíveis.

Uma forma de definir este momento pode ser com base no custo da qualidade. O Project Management Institute (2014) define o custo da qualidade como sendo o custo total do trabalho de conformidade e do trabalho de não conformidade que deve ser executado como um esforço compensatório porque, na primeira tentativa de execução do trabalho existe a possibilidade de que parte do trabalho requerido não seja realizado ou seja executado incorretamente. Ou seja, o trabalho de conformidade ocorre enquanto o software ainda está em desenvolvimento e o trabalho de não conformidade caso correções sejam necessárias após o software ter sido liberado para o cliente. A Figura 2 mostra que conforme o tempo decorrido dos testes avança, o custo para prevenir ou corrigir

20 defeitos torna-se cada vez maior em relação a sua quantidade e gravidade. Portanto, chega um determinado momento em que é mais vantajoso para a empresa resolver uma ou outra não conformidade detectada pelo cliente do que estender demais o trabalho de tentar prevenir todas as possibilidades de não conformidades que possam ocorrer.

Figura 2. Relação do custo da qualidade para prevenir e corrigir defeitos. Fonte: Project Management Institute (2014).

Conclui-se que é impraticável, muitas vezes impossível, encontrar todos os defeitos em um software. Contudo, existem estratégias de teste que visam encontrar o maior número possível de defeitos utilizando-se do menor esforço possível. Tais estratégias serão apresentadas na Seção 2.3.

2.2 DEFEITOS DE SOFTWARE

Como foi abordado na introdução deste trabalho, o foco dos testes é a detecção de defeitos. O defeito pode ser definido como sendo um desvio de qualidade no ato de elaboração de um documento, na execução de uma atividade ou na construção de um componente de software (PFLEEGER, 2004; BARTIÉ, 2002).

São esses desvios de qualidade que produzem retrabalho, aumentam os custos do projeto, dilatam os prazos de entrega do software, diminuem a produtividade e aumentam a insatisfação do cliente (BARTIÉ, 2002).

O defeito de software também pode receber outros nomes. Pode ser chamado de erro, problema, falha, ocorrência, incidente, não conformidade e inconsistência. Também pode-se empregar palavras existentes na língua inglesa como bug, crash ou o termo abend (acrônimo de abnormal end).

21 Segundo a IEEE (IEEE 610, 1990) os termos defeito, erro e falha não são sinônimos, pois possuem significados distintos no universo de sistemas computacionais, conforme apresentado na Figura 3.

Figura 3. Definição de defeito, erro e falha. Fonte: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035

A seguir tem-se a definição destes termos, de acordo com a IEEE (IEEE 610, 1990).

 Defeito: é um ato inconsistente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema, utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto.

 Erro: é uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um software constitui um erro.

 Falha: é o comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.

Segundo Pfleeger (2004), um defeito no software, se acompanhado de certa condição, causa uma falha. Isto é, pode haver um defeito no código, mas se o código nunca for executado ou se não for executado por tempo suficiente ou em uma configuração específica para causar um problema, podemos nunca vê-lo falhar. Como o teste não pode exercitar todas as condições possíveis, o objetivo é o de encontrar os defeitos com esperança de que, no processo, eliminemos todos os que possam levar a falhas durante a utilização do sistema.

22 Mas os defeitos podem ter origem antes mesmo que se tenha começado a escrita da primeira linha de código. Para Myers, Badgett e Sandler (2011), o desenvolvimento de software é em grande parte um processo de comunicação de informações sobre o eventual software e traduzir essa informação de uma forma para outra. Em essência, ele está se movendo do conceitual para o concreto. Por esse motivo, a grande maioria dos erros de software pode ser atribuída a avarias, erros e "ruído" durante a comunicação e tradução da informação.

Esta afirmação pode ser complementada por Pfleeger (2004). Ela diz que os defeitos de software podem ser inseridos em um requisito, no projeto, em um componente de código ou na documentação, em qualquer ponto durante o desenvolvimento ou a manutenção do sistema. A Figura 4 ilustra prováveis causas de defeitos em cada atividade de desenvolvimento. Embora seja preferível encontrar e corrigir defeitos o quanto antes, o teste de sistema reconhece que os defeitos ainda podem estar presentes no sistema depois do teste de integração.

Figura 4. Causas de defeitos durante o desenvolvimento do software. Fonte: Adaptado de Pfleeger (2004)

23 Para Myers, Badgett e Sandler (2011), um erro de software ocorre quando o software não faz o que o seu usuário final espera que faça. Aplicando esta definição, mesmo que tenham sido executados testes de módulos absolutamente perfeitos, ainda assim não seria possível garantir que todos os erros do software tenham sido encontrados.

Defeitos podem ser introduzidos no sistema, seja no começo do desenvolvimento ou posteriormente, ou até mesmo quando corrige-se um defeito que foi descoberto. Por exemplo, um software com defeito pode ser resultado de defeitos nos requisitos. Se um requisito for ambíguo porque o cliente não estava seguro sobre uma necessidade ou porque interpretou-se mal o cliente, o resultado é o mesmo: um sistema que não funciona como o cliente gostaria (PFLEEGER, 2004).

2.3 DIMENSÕES DOS TESTES

Uma variedade de testes pode ser feita antes da liberação do software para o cliente, com o intuito de garantir que ele funcione apropriadamente. Alguns testes dependem do que está sendo testado: componentes, grupos de componentes, subsistemas, ou todo o software. Outros podem ser baseados em critérios para verificar se o software está funcionando de acordo com o projeto, com os requisitos ou com as expectativas do cliente. Na elaboração do planejamento do teste, uma das etapas é a elaboração da estratégia de teste. A estratégia de teste compreende a definição dos seguintes itens: o Nível de Teste, isto é, a definição da fase de desenvolvimento do software em que o teste será aplicado; a Técnica de Teste a ser utilizada; o Tipo de Teste a ser aplicado no software. (CRESPO et al, 2004; PFLEEGER, 2004).

A Figura 5 apresenta estas dimensões, porém não exibe por completo os tipos de teste devido a sua maior quantidade. As definições serão apresentadas na sequência.

24

Figura 5. Dimensões dos testes. Fonte: Adaptado de Rios (2010).

2.3.1 Técnicas de Teste

Diferentes técnicas de teste podem ser adotadas dependendo da fase de desenvolvimento do software. Tais técnicas direcionam a escolha dos critérios para geração de casos de teste, ou seja, como devem ser realizados os testes (CRESPO et al, 2004).

Apenas duas técnicas são citadas por autores como Myers, Badgett e Sandler (2011), Riley e Goucher (2010), Fournier (2009): Caixa-branca e Caixa-preta. A primeira, por vezes citada como Teste Estrutural, permite que a estrutura interna do software seja examinada. Com isso, os testes são derivados por meio da análise da lógica do código do software. Como a lógica do software pode ser analisada, é possível fazer com que cada instrução no software possa ser executada pelo menos uma vez. Pode-se dizer que o objetivo dessa técnica é análogo a executar testes de entradas exaustivas com a técnica de Caixa-preta (MYERS; BADGETT; SANDLER, 2011; RILEY; GOUCHER, 2010; FOURNIER, 2009; LEWIS; VEERAPILLAI, 2004; PFLEEGER, 2004).

A técnica de teste de Caixa-preta recebe este nome pelo simples fato de que o software é visto como uma caixa-preta. Também conhecido na literatura por Teste Funcional, seu objetivo é ser completamente indiferente sobre o comportamento interno e estrutura do software. Em vez disso, seu objetivo é encontrar circunstâncias em que o software não se comporta de acordo com as suas especificações. Portanto, nesta abordagem, os dados de teste são apenas derivados das especificações do software sem tirar proveito do conhecimento da sua estrutura interna (MYERS; BADGETT;

25 SANDLER, 2011; RILEY; GOUCHER, 2010; FOURNIER, 2009; LEWIS; VEERAPILLAI, 2004; PFLEEGER, 2004).

Uma mescla destas duas técnicas resulta em uma terceira, chamada Caixa-cinza. Esta técnica não possui características próprias, apenas busca fazer uma combinação das técnicas de caixa-preta e caixa-branca. Talvez por isso seja citada por poucos autores como Lewis e Veerapillai (2004). Na prática, o testador estuda a especificação dos requisitos e se comunica com os desenvolvedores para entender a estrutura interna do sistema. Os testes funcionais, então, são criados e executados com o conhecimento da lógica estrutural do software.

2.3.2 Níveis de Teste

Os Níveis de Teste, por sua vez, estabelecem quando os testes devem ocorrer durante a fase de desenvolvimento do software (CRESPO et al, 2004).

Em sua fase inicial, compreendendo a codificação dos módulos do sistema, pode-se aplicar os Testes de Unidade para testar individualmente subprogramas, sub-rotinas, procedimentos ou classes em um software. Mais especificamente, em vez de testar inicialmente o software como um todo, os testes são focados nos menores blocos que compõem o software. Estes testes facilitam a tarefa de depuração, que é o processo de identificar e corrigir um erro descoberto, pois quando for detectado um erro, é conhecido o módulo que o originou (MYERS; BADGETT; SANDLER, 2011; LEWIS; VEERAPILLAI, 2004; RIOS, 2010).

Para Pfleeger (2004), o Teste de Unidade consiste em examinar o código, revisando-o, tentando identificar defeitos no algoritmo, nos dados e na sintaxe. O código pode até ser comparado com as especificações e seu projeto, para assegurar que todos os casos relevantes foram considerados. Em seguida, compila-se o código a fim de eliminar os defeitos de sintaxe remanescentes. Por fim, casos de teste são desenvolvidos para mostrar que a entrada é apropriadamente convertida na saída desejada.

Após a execução satisfatória dos Testes de Unidade, todos os módulos devem ser testados integrados. Nos Testes de Integração, o sistema é construído lentamente adicionando-se um ou mais módulos de uma vez a um conjunto de módulos já integrados. O objetivo é verificar, de forma integrada, se cada unidade ou módulo executa corretamente dentro de sua estrutura de controle e que as interfaces estão corretas (LEWIS; VEERAPILLAI, 2004; PFLEEGER, 2004).

O próximo nível é o Teste de Sistema, que tem como finalidade específica comparar o software com os seus objetivos originais, ou seja, com as especificações que foram definidas antes do software ser implementado. É o processo de tentativa de demonstrar que o software, como um todo, não cumpre

26 com os seus objetivos. Por definição, é impossível executá-lo se não houver um conjunto de objetivos mensuráveis, escritos para o produto. A procura de discrepâncias entre o software e seus objetivos, se concentra em erros de tradução, feitos durante o processo de elaboração da especificação externa. A operação normal do sistema é simulada, sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de produção. São usados dados de teste e situações de teste de modo a tentar evitar ocorrência de defeitos na fase de Teste de Aceitação. Isso torna o teste de sistema um processo de teste vital, porque em termos de produto, o número de erros cometidos, e a gravidade destes erros, este estágio no ciclo de desenvolvimento é geralmente o mais propenso a erros (MYERS; BADGETT; SANDLER, 2011; LEWIS; VEERAPILLAI, 2004).

Aproximando-se do fim do desenvolvimento do software, o nível de Teste de Aceitação visa comparar as necessidades iniciais do software com as necessidades atuais dos usuários finais. É um tipo incomum de teste em que, geralmente, é realizada pelo cliente ou usuário final do software e, normalmente, a execução não é considerada de responsabilidade da organização de desenvolvimento, apenas o acompanhamento e suporte. No caso de um software contratado, a organização contratante (usuário) realiza o teste de aceitação, comparando a operação do software ao contrato original. Como é o caso de outros tipos de testes, a melhor maneira de fazer isso é criar casos de teste que tentam mostrar que o software não atende ao contrato; se esses casos de teste não forem bem sucedidos, o software é aceito (MYERS; BADGETT; SANDLER, 2011; LEWIS; VEERAPILLAI, 2004; PFLEEGER, 2004).

Pfleeger (2004) complementa dizendo que o teste visa garantir que o sistema corresponda ao que os usuários finais entendem dos requisitos, o que pode ser diferente daquilo que os desenvolvedores entendem. Enfim, este teste assegura aos clientes que o sistema solicitado é o que foi construído. O teste pode ser executado no ambiente real de funcionamento, mas frequentemente é realizado em um ambiente de teste diferente do local em que será instalado.

Outro nível de teste é citado por autores como Myers, Badgett e Sandler (2011), Pfleeger (2004). O Teste de Instalação. Segundo eles, o propósito desse teste não é encontrar erros do software, e sim encontrar os erros que podem ocorrer durante o processo de instalação. Muitos eventos podem ocorrer durante a instalação de sistemas de software como, por exemplo, arquivos e bibliotecas devem ser alocados e carregados e configurações de hardware, acesso à rede de computadores local ou internet devem estar disponíveis, se necessário. Portanto, a organização que produziu o sistema deve desenvolver os testes de instalação, que devem ser entregues como parte do sistema, e executados após a instalação do sistema. Os casos de teste devem verificar, entre outras coisas, que um conjunto

27 compatível de opções tenha sido selecionado, a existência de todas as partes do sistema, que todos os arquivos foram criados com os conteúdos necessários e que a configuração de hardware é apropriada.

2.3.3 Tipos de Teste

Os Tipos de Teste referem-se às características do software que podem ser testadas com base nos seus requisitos. Assim é definido por Crespo et al (2004) e Pfleeger (2004). Segundo Myers, Badgett e Sandler (2011), não é obrigatório aplicar todos os tipos de teste ao projetar os casos de teste, mas, para que não ocorram negligências, é recomendável explorar o maior número de tipos possível.

Testes de Regressão: este teste é realizado depois que o software passa por uma melhoria funcional ou correção de defeitos. Sua finalidade é determinar se a alteração regrediu outros aspectos do software. Geralmente executa-se novamente subconjuntos de casos de teste do software. O teste de regressão é recomendado devido ao fato de que as mudanças e correções de erros tendem a ser muito mais propenso a erros do que o código do software original (MYERS; BADGETT; SANDLER, 2011; LEWIS; VEERAPILLAI, 2004).

Para Pfleeger (2004), estes testes são requeridos quando o software que está sendo testado irá substituir um software existente. O teste, então, garante que o desempenho do novo sistema é, pelo menos, tão bom quanto o do sistema antigo. Os testes de regressão são sempre utilizados durante o desenvolvimento em fases.

Testes de Estresse: nos testes de estresse, o software é submetido a uma carga excessiva de dados ou atividades em um curto espaço de tempo e de forma simultânea. Este tipo de teste é recomendado para softwares que operam sob diversas cargas, como por exemplo, softwares de tempo real, interativos e controle de processos (MYERS; BADGETT; SANDLER, 2011; PFLEEGER, 2004; LEWIS; VEERAPILLAI, 2004).

Testes de Carga ou Volume: consiste em submeter o software a grandes volumes de dados. Em outras palavras, a finalidade deste teste é possivelmente mostrar que o software não consegue lidar com o volume de dados especificado em seus requisitos (MYERS; BADGETT; SANDLER, 2011; PFLEEGER, 2004; LEWIS; VEERAPILLAI, 2004).

Testes de Usabilidade: o objetivo do teste de usabilidade é determinar o quão bem o usuário estará apto para usar e entender o sistema. Isso inclui as funções do sistema, publicações, texto de ajuda e procedimentos para garantir que o usuário interaja com o sistema confortavelmente. Estes testes devem ser realizados tão cedo quanto possível durante o desenvolvimento e devem ser concebidos para o sistema (LEWIS; VEERAPILLAI, 2004; PFLEEGER, 2004). Para Myers, Badgett e

28 Sandler (2011), consiste em testar o software em um ambiente do mundo real com os usuários finais de uma aplicação.

Testes de Segurança: o teste de segurança é o processo de tentar elaborar casos de teste que subvertam as verificações de segurança do software. Neste tipo de teste, por exemplo, pode-se formular casos de teste que tentam contornar um mecanismo de proteção de memória de um sistema operacional ou acesso ao sistema de banco de dados (MYERS; BADGETT; SANDLER, 2011; LEWIS; VEERAPILLAI, 2004, PFLEEGER, 2004).

Testes de Compatibilidade: o objetivo do teste de compatibilidade é testar a compatibilidade do aplicativo com outros aplicativos ou sistemas. Este teste é necessário quando um sistema faz interface com outros sistemas. Por exemplo, se o sistema deve se comunicar com um sistema de banco de dados a fim de obter informações, um teste de compatibilidade examina a velocidade e precisão dos dados recebidos. (LEWIS; VEERAPILLAI, 2004; PFLEEGER, 2004). Para Myers, Badgett e Sandler (2011), o objetivo do Teste de Compatibilidade é garantir, por exemplo, que a nova versão de um banco de dados é compatível com os dados existentes na versão anterior ou que um aplicativo de processamento de textos suporta os seus formatos de arquivos das versões anteriores.

Testes de Recuperação: softwares como sistemas operacionais, sistemas de gerenciamento de banco de dados e softwares de teleprocessamento geralmente têm objetivos de recuperação que indicam como o sistema seja para se recuperar de erros de programação, falhas de hardware e erros de dados. Um dos objetivos deste teste é mostrar que essas funções de recuperação não funcionam corretamente. Falhas de hardware, tais como erros de paridade de memória ou erros de dispositivos de entrada/saída, erros de dados como ruído na linha de comunicações, a falta repentina de energia elétrica ou erros de programação são exemplos que podem ser propositadamente injetados no sistema para determinar se pode se recuperar a partir deles (MYERS; BADGETT; SANDLER, 2011; PFLEEGER, 2004; LEWIS; VEERAPILLAI, 2004).

Testes de Armazenamento: softwares ocasionalmente podem possuir objetivos de armazenagem que, por exemplo, indicam a quantidade de memória que o software usará do sistema e o tamanho dos arquivos temporários ou de logs. O objetivo deste teste é verificar se o software pode controlar o uso de memória do sistema para que não impacte negativamente outros processos em execução. O mesmo vale para arquivos físicos no sistema de arquivos, pois uma unidade de disco cheia pode causar perda de tempo significativo (MYERS; BADGETT; SANDLER, 2011).

Testes de Facilidade: consiste em determinar se cada facilidade mencionada nos objetivos foi realmente implementada. O procedimento é verificar os objetivos frase por frase, e quando uma frase

29 especifica o que a facilidade deve fazer, determinar que o sistema satisfaz esse objetivo. Este tipo de teste pode muitas vezes ser realizado sem um computador, limitando-se apenas à comparação dos objetivos com a documentação do usuário (MYERS; BADGETT; SANDLER, 2011).

Testes de Performance: muitos sistemas têm objetivos específicos de desempenho ou eficiência que indicam como deve ser o seu comportamento referente a tempo de resposta e taxas de transferência, sob certas condições de carga de trabalho e de configuração. Portanto, o objetivo do teste é demonstrar que o sistema cumpre com os objetivos de desempenho (MYERS; BADGETT; SANDLER, 2011).

Testes de Configuração: softwares como sistemas operacionais, sistemas de gerenciamento de banco de dados suportam uma variedade de configurações de hardware, incluindo vários tipos e números de dispositivos de I/O, linhas de comunicação ou diferentes tamanhos de memória. Em muitos casos, o número de configurações possíveis é muito grande para testar cada uma, mas o teste deve ser realizado pelos menos com cada tipo de dispositivo de hardware e com a configuração mínima e máxima (MYERS; BADGETT; SANDLER, 2011).

Testes de Instalação: o teste de instalação é um dos mais importantes para softwares cujo procedimento de instalação é complexo. O objetivo deste teste é testar o procedimento de instalação do sistema, que nesses casos é geralmente automatizado, evitando dessa forma que o usuário final tenha uma má experiência ao se deparar com uma falha logo no primeiro contato com o sistema, fazendo com que o usuário tenha pouca confiança no processo de validação ou procure outro sistema (MYERS; BADGETT; SANDLER, 2011).

Testes de Manutenção: o sistema pode possuir objetivos relacionados às características de facilidade de manutenção. O propósito deste teste é verificar, por exemplo, a coleta e armazenamento de eventos para auxiliar no diagnóstico de uma falha, o tempo médio para depurar a falha, os procedimentos de manutenção, bem como a qualidade da documentação lógica interna (MYERS; BADGETT; SANDLER, 2011; PFLEEGER, 2004).

Testes de Documentação: este teste verifica a exatidão da documentação do usuário. A principal maneira de realizar este teste é usar a documentação para determinar a representação prévia dos casos de teste. Ou seja, a documentação do usuário é utilizada com um guia para a elaboração dos casos de teste. Além disso, a documentação do usuário em si deve ser objeto de uma inspeção para verificar se há precisão e clareza. Quaisquer ilustrações de exemplo devem ser convertidas em casos de teste para testar o sistema (MYERS; BADGETT; SANDLER, 2011; PFLEEGER, 2004).

30 Outros tipos de teste podem existir, apesar de menos comuns, como os citados por Pfleeger (2004): testes de tempo, testes de ambiente, testes de qualidade. Myers, Badgett e Sandler (2011), citam também: testes de procedimento, testes de confiabilidade.

2.4 PROCESSO DE TESTE

Para que um produto de software receba uma cobertura de testes satisfatória, de forma a encontrar a maior quantidade possível de defeitos, faz-se necessário a adoção de um processo de testes para padronizar os trabalhos e ampliar a organização e controle dos projetos de testes. Este processo integra métodos de projeto de casos de teste em uma série bem planejada de passos, que resultam na construção bem-sucedida de software. O processo fornece um roteiro que descreve os passos a serem conduzidos como parte do teste, quando esses passos são planejados e depois executados, quanto de esforço, tempo e recursos serão necessários. Assim, qualquer processo de teste deve incorporar planejamento de teste, projeto de casos de teste, execução dos casos de teste e a resultante coleta e avaliação de dados (PRESSMAN, 2006).

Para Bartié (2002), a etapa de planejamento dos testes caracteriza-se pela definição de uma proposta de testes baseada nas expectativas do cliente em relação à prazos, custos e qualidade esperada, possibilitando dimensionar a equipe e estabelecer um esforço de acordo com as necessidades apontadas pelo cliente. Tal planejamento pode ser composto de muitas atividades, mas, basicamente, consideram-se as seguintes:

Estudo do projeto: o projeto deve ser estudado a fim de verificar os requisitos ou as possíveis modificações de requisitos ou arquitetura do software. Estudam-se as lições aprendidas dos projetos de testes anteriores, as expectativas de custos, prazos e os riscos envolvidos no projeto e seus impactos.

Avaliação de impacto: avalia-se a necessidade de criar ou modificar casos de teste. Se houverem casos de teste automatizados, deve ser verificado se existe a necessidade de adequar o código e ferramentas ou até mesmo adquirir novas ferramentas.

Análise de esforço interno e externo: estima-se o esforço interno para condução das atividades. Métricas de projetos anteriores podem ser avaliadas para auxiliar na elaboração das estimativas. Se houver necessidade de terceirar parte do serviço, faz-se necessário avaliar a disponibilidade de espaço físico e infraestrutura e especificar as métricas de qualidade e produtividade esperadas.

31 Definição de cenários possíveis: avalia-se a lista de projetos de teste em andamento e a serem iniciados com o objetivo de verificar a disponibilidade de recursos internos para alocação no projeto. Após isto, a proposta será enviada para aprovação pelo cliente interno ou externo.

Aprovação do planejamento: com a aprovação da proposta apresentada, o planejamento pode ser divulgado aos colaboradores internos ou externos.

Normalmente, os papéis envolvidos no planejamento dos testes são Coordenador de Testes, Líder de Testes e Arquiteto de Testes (BARTIÉ, 2002).

Craig e Jaskiel (2002) acreditam que o planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software.

Dessa forma, o planejamento e projeto dos testes devem ocorrer de cima para baixo, ou seja:

1. Inicialmente é planejado o Teste de Aceitação a partir do documento de requisitos;

2. Após isso é planejado o Teste de Sistema a partir do projeto de alto nível do software;

3. Em seguida ocorre o planejamento dos Testes de Integração a partir do projeto detalhado; e

4. Por fim, o planejamento dos testes a partir da codificação.

Já a execução ocorre no sentido inverso, como pode ser observado na Figura 6.

Figura 6. Modelo V: paralelismo entre as atividades de desenvolvimento e teste de software. Fonte: Craig e Jaskiel (2002).

32 A visão de Myers, Badgett e Sandler (2011) quanto ao planejamento dos testes é semelhante, com exceção da adição de outras duas etapas: Teste de Função, que está relacionado a etapa do processo de design de Especificação Externa e o Teste de Instalação, que não está associado a nenhuma das etapas do processo de design, pois seu objetivo não é o de encontrar erros do software e sim os possíveis erros que podem ocorrer durante o processo de instalação do software.

Concluído o planejamento, a próxima etapa é a Especificação dos Testes. Nesta etapa são identificados os casos de teste que deverão ser construídos ou modificados com base nos requisitos do software. Nesta etapa é realizada a análise dos novos requisitos ou modificação dos existentes, juntamente com os casos de uso, com o objetivo de garantir que todos serão cobertos por casos de teste (BARTIÉ, 2002).

Caso de teste: um caso de teste descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.

Procedimento de teste: um caso de teste ou um grupo de casos de teste pode requerer um procedimento de teste que descreva os passos necessários para executá-los (CRAIG & JASKIEL, 2002).

Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto (ROCHA et al., 2001). Os critérios de teste podem ser utilizados como;

Critério de Cobertura dos testes: permitem a identificação de partes do software que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS & WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessários por um critério de teste que foram executados pelo conjunto de casos de teste.

Critério de Adequação de Casos de Teste: quando, a partir de um conjunto de casos de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critério. Ou seja, este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função (ROCHA et al., 2001).

Critério de Geração de Casos de teste: quando o critério é utilizado para gerar um conjunto de casos de teste T adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente (ROCHA et al., 2001).

33 Especifica-se, caso necessário, a adequação das ferramentas existentes ou novas ferramentas e códigos de testes automatizados. Analistas de teste avaliam o nível de cobertura alcançado pelos casos de teste e sugerem melhorias até que seja alcançado um patamar satisfatório. Os papéis envolvidos nesta etapa normalmente são Coordenador de Testes, Líder de Testes, Analista de Testes, Arquiteto de Testes e Automatizador de Testes (BARTIÉ, 2002).

O projeto dos casos de teste é a chave para um teste bem-sucedido. Se os casos de teste não forem representativos e não envolverem todas as possibilidades de exercício das funções que demonstram a correção e a validade do sistema, então, o restante do processo de testes é inútil. Portanto, a execução de um teste começa com a revisão dos casos de teste, a fim de verificar se estão corretos, se são viáveis, se fornecem o grau desejado de cobertura e se demonstram a funcionalidade pretendida. Uma vez que essas verificações tenham sido feitas, pode-se realmente executar os testes (PFLEEGER, 2004).

A etapa seguinte é a de execução dos casos de teste com o objetivo de conferir os testes planejados, de forma a garantir que o comportamento do aplicativo permanece em conformidade com os requisitos contratados pelo cliente. Cada defeito descoberto durante os testes deve ser documentado para ajudar no registro desses defeitos. Um relato de problema é gerado quando um procedimento de teste dá origem a um evento que não pode ser explicado pelo testador. O relato do problema documenta os detalhes do evento e inclui, pelo menos, esses itens: Identificação do problema; Autor; Versão da Release/Build; Data de abertura; Data de encerramento; Área do problema; Defeito ou melhoria; Ambiente de teste; Tipo de defeito; Quem detectou; Como detectou; Atribuído à; Prioridade; Severidade; Estado (BARTIÉ, 2002).

2.5 USABILIDADE DE SOFTWARE

A usabilidade é um atributo de qualidade relacionado à facilidade de uso de algo. Mais especificamente, refere-se à rapidez com que os usuários podem aprender a usar coisas, a eficiência deles ao usá-la, a facilidade de memorização, seu grau de propensão a erros, quanto se sentem seguros ao utilizar e o quanto gostam de utilizá-la (NIELSEN; LORANGER, 2007; BENYON, 2011; PREECE, 2005).

Utilidade é outro atributo de qualidade importante, pois se refere a funcionalidade do projeto: “Faz o que os usuários precisam?”. Portanto, usabilidade e utilidade são igualmente importantes e juntos podem determinar se a interface é útil: Pouco importa a interface ser fácil de usar, se não faz o que os usuários querem. Também não é boa se o sistema pode hipoteticamente fazer o que quiser, mas os usuários não podem fazer isso acontecer pelo fato de a interface ser difícil de usar. Para estudar

34 utilidade de um projeto, você pode usar os mesmos métodos de pesquisa do usuário que melhoram a usabilidade (NIELSEN, 2012).

A primeira lei da usabilidade para Krug (2006) é: “Não me faça pensar”. Dentro do que é humanamente possível, o usuário deve olhar para uma página WEB autoexplicativa. Óbvia. Deve ser capaz de entender o seu propósito e como usá-la sem gastar qualquer esforço em pensar nisso.

Para tornar isso possível, o autor sugere dicas básicas: dar nomes óbvios às coisas como, por exemplo, o identificador de um campo para buscar um item no site deve ser “Buscar” ao invés de “Busca Rápida”; um link para serviço de classificados de empregos deve ser “Empregos” e não “Emp” ou “Oportunidades de emprego”; fazer com que algo feito para clicar pareça obviamente com algo que se possa clicar, conforme ilustrado na Figura 7.

Figura 7. Relação entre coisas óbvias e coisas que fazem o usuário pensar. Fonte: Adaptado de Krug (2006).

Krug (2006) acredita que a maioria dos usuários de páginas WEB não leem seu conteúdo e sim as exploram visualmente. Portanto, o ideal é criar uma hierarquia visual clara em cada página tirando vantagem das convenções já construídas ao longo da história da WEB, garantindo deste modo que o usuário veja e entenda o site o máximo possível. Uma hierarquia visual clara é constituída de três características, descritas a seguir e ilustradas na Figura 8.

35 1. Quanto mais importante uma coisa é, mais proeminente deve ser. Por exemplo, os títulos mais importantes devem ser maiores ou mais destacados ou com uma cor distinta ou mais perto do topo da página ou uma combinação destes;

2. Coisas logicamente relacionadas também devem ser relacionadas visualmente. Por exemplo, coisas semelhantes podem ser agrupadas com um estilo visual semelhante sob um mesmo título ou coloca-las em uma área claramente definida;

3. As coisas devem estar aninhadas visualmente para mostrar o que é parte do que. Por exemplo, um título de seção "Livros de Computação" deve aparecer acima do título de um livro específico sobre usabilidade de software, abrangendo visualmente toda a área de conteúdo da página, pois o livro é parte da seção. E o título deste livro, por sua vez, abrange os elementos que o descrevem.

Figura 8. Exemplo de elementos aninhados visualmente. Fonte: Adaptado de Krug (2006).

Outras coisas simples podem ser aplicadas para que os usuários de uma página WEB não gastem seu tempo pensando. Uma delas é a informação conhecida por migalhas de pão8. Essa informação deve estar presente em todas as páginas indicando ao usuário em que página está, precedido pelo caminho completo que a leva desde a página inicial.

Nielsen (1993) define 10 princípios heurísticos de usabilidade inspirados no que chama de propriedades comuns às interfaces usáveis:

8 uma alusão à trilha de migalhas de pão que Hansel fez na floresta para que ele e Gretel pudessem encontrar o caminho de volta para casa no conto de fadas dos irmão Grimm.

36 1 - Visibilidade do Estado do Sistema: O sistema deve sempre manter o usuário informado sobre o que está acontecendo através do fornecimento de feedback apropriado dentro de tempos razoáveis. Como exemplo, a Figura 9 apresenta uma operação de upload de vários arquivos. O sistema está apresentando o estado de cada um dos envios, ou seja, o usuário saberá quais já foram enviados, qual está sendo enviado e quais ainda não foram enviados.

Figura 9. Exemplo de correta aplicação da heurística Visibilidade do Estado do Sistema Fonte: Raposo (2014).

2 - Compatibilidade entre Sistema e Mundo Real: O sistema, ao invés de termos relacionados com o software, deve utilizar a linguagem do usuário, com palavras, frases e conceitos familiares a ele. O sistema deve seguir as convenções do mundo real, fazendo a informação aparecer na ordem lógica e natural, como pode ser visto na Figura 10.

Figura 10. Exemplo de correta aplicação da heurística Compatibilidade entre Sistema e Mundo Real Fonte: Raposo (2014).

3 - Liberdade e Controle do Usuário: Os usuários geralmente cometem enganos ao escolher opções do sistema. Neste caso, precisam de uma saída de emergência evidente, que lhes permita deixar o

37 estado indesejado sem ter que passar por diálogos extensos. Recursos recomendáveis para estas situações são, por exemplo, as opções de desfazer e refazer, como exemplificado na Figura 11.

Figura 11. Exemplo de correta aplicação da heurística Liberdade e Controle do Usuário. Fonte: Raposo (2014).

4 - Consistência e Padrões: Os usuários não devem ter que adivinhar se diferentes palavras, situações ou ações têm o mesmo significado. Recomenda-se, neste caso, o uso de um conjunto definido de convenções. A Figura 12 apresenta um exemplo em que esta heurística é violada, pois o termo “Save as” permite que o usuário crie uma pasta, porém o botão “Cancel” não cancela toda a operação. Ou seja, caso uma pasta tenha sido criada, ela não será removida.

Figura 12. Exemplo de violação da heurística Consistência e Padrões. Fonte: Raposo (2014).

5 - Prevenção de Erro: O projeto da interação deve privilegiar a prevenção de erros. Nielsen (1993) afirma que o projeto cuidadoso que previne o problema de acontecer a primeira vez é ainda melhor que fornecer boas mensagens de erros. Uma violação desta heurística pode ser vista no exemplo da Figura 13. O usuário criou uma pasta e, ao acessar o menu “Edit”, é apresentada a opção “Undo Delete”, ou seja,

38 desfazer uma operação de delete, mas a última operação do usuário foi criar uma pasta, e não apagar uma pasta.

Figura 13. Exemplo de violação da heurística Prevenção de Erro. Fonte: Raposo (2014).

6 - Ênfase no Reconhecimento: O projeto deve dar ênfase no reconhecimento e preterir que o usuário tenha que relembrar aspectos relativos à interação. Isto pode ser conseguido fazendo-se objetos, ações e opções visíveis. Definitivamente, o usuário não deve ser obrigado a relembrar de uma parte do diálogo para poder dar sequência à interação. Instruções para o uso do sistema devem ser visíveis e facilmente recuperáveis. A Figura 14 apresenta um exemplo de violação desta heurística, pois a função “Sort”, para ordenar a lista selecionada, está associada ao menu “Table”.

39

Figura 14. Exemplo de violação da heurística Ênfase no Reconhecimento. Fonte: Raposo (2014).

7 - Flexibilidade e Eficiência no Uso: Aceleradores, invisíveis aos usuários novatos, podem oferecer maior velocidade de interação para os usuários mais experimentados. Este recurso permite que o sistema seja igualmente apropriado para usuários novatos ou mais experientes. Além deste recurso, deve-se proporcionar ao usuário mecanismos para criar atalhos para ações frequentes. Na Figura 15, a única forma de acessar as abas é clicando com o mouse, então este é um exemplo de violação desta heurística.

Figura 15. Exemplo de violação da heurística Flexibilidade e Eficiência no Uso. Fonte: Raposo (2014).

8 - Estética e Projeto Minimalistas: Segundo Nielsen (1993), os diálogos não devem conter informação irrelevante ou raramente necessária. Qualquer unidade extra de informação em um diálogo compete com unidades relevantes, diminuindo a visibilidade relativa. Um exemplo pode ser visto na mesma Figura 15, da heurística anterior, em que o excesso de figuras e cores podem causar distração.

40

9 - Auxílio ao Reconhecimento, Diagnóstico e Recuperação de Erros: As mensagens de erro devem ser expressas em linguagem por extenso, sem códigos e de maneira clara. O teor da mensagem deve indicar o problema com precisão e sugerir uma solução construtiva. A Figura 16 apresenta uma mensagem de erro que menciona algo semelhante a “Ação abortada devido a um erro de especificação”. Isto é um exemplo de violação desta heurística, pois o usuário não obteve uma informação detalhada sobre o que causou o erro e como fazer para contorna-lo.

Figura 16. Exemplo de violação da heurística Auxílio, Diagnóstico e Recuperação de Erros. Fonte: Raposo (2014).

10 - Ajuda e Documentação: Embora seja melhor que o sistema possa ser usado sem documentação, pode ser necessário providenciá-la, bem como pode ser necessário providenciar helps.

Os problemas de usabilidade encontrados através do uso destas dez heurísticas podem ser classificados para auxiliar na tomada de decisão sobre quanto de recurso precisará ser alocado para corrigir os problemas mais graves e se o produto pode ou não ser lançado. Se as classificações de gravidade indicam que diversos problemas de usabilidade desastrosos estão presentes na interface de um produto, provavelmente será desaconselhável liberá-lo. Por outro lado, pode-se decidir ir em frente com o lançamento de um produto de software com vários problemas de usabilidade se eles foram todos classificados como estéticos. Para auxiliar na classificação da severidade de um problema de usabilidade, é necessário a análise da combinação de três fatores:

1. Frequência com que o problema ocorre: se é comum ou raro de ocorrer. 2. Impacto do problema: se vai ser fácil ou difícil para os usuários superarem tal problema. 3. Persistência do problema: se ocorre apenas uma vez e os usuários conseguem superá-lo facilmente ou os usuários serão repetidamente incomodados pelo problema.

41 Com isso pode-se medir o grau de severidade do problema, usando-se a escala demonstrada na Tabela 3.

Tabela 1. Escala para classificação dos problemas de usabilidade. Grau da Tipo Descrição severidade 0 Sem importância Não é, totalmente, um problema de usabilidade. 1 Estético Não necessita ser corrigido, a menos que haja tempo extra disponível no projeto. 2 Simples Necessita ser corrigido com baixa prioridade. 3 Grave Necessita ser corrigido com alta prioridade. 4 Catastrófico Imprescindível ser corrigido antes da liberação do produto.

42 3 FERRAMENTAS

Este capítulo tem o objetivo de apresentar as ferramentas de gestão de testes e de defeitos encontradas através de pesquisas na internet realizadas no primeiro semestre de 2015. Serão explicados os critérios adotados para selecionar e avaliar as ferramentas que servirão de base para a elicitação dos requisitos necessários para o desenvolvimento da ferramenta desejada por este trabalho.

3.1 CRITÉRIOS PARA SELECIONAR FERRAMENTAS Os critérios adotados para selecionar as ferramentas são que elas devem ser Web e gratuitas, sem limitação de quantidade de usuários e projetos. O código fonte pode ser aberto ou não. Satisfeitos esses critérios, serão selecionadas três ferramentas de gestão de defeitos e três de gestão de testes mais utilizadas.

3.2 SELEÇÃO DAS FERRAMENTAS Iniciando a pesquisa pelas ferramentas de gestão de defeitos, foram encontradas ferramentas específicas para gestão de defeitos, ferramentas de gestão de testes que possuem o módulo de gestão de defeitos e ferramentas de gestão de projetos que surgiram nas buscas por possuírem o módulo de gestão de defeitos, embora os filtros de pesquisa não contivessem os termos gestão de projetos. A Tabela 4 apresenta a seleção das ferramentas usando os critérios iniciais, ou seja, ferramentas baseadas na Web, gratuitas sem limite de usuários e projetos.

Tabela 2. Seleção das ferramentas de gestão de defeitos. Nome Web Gratuita Site oficial AdminiTrack Sim Não www.adminitrack.com Airbrake Sim Não www.airbrake.io Sim Não www.assembla.com Sim Para até 10 usuários www.axosoft.com Bloodhound Sim Sim bloodhound.apache.org Bontq Sim Não www.bontq.com Boto Sim Não www.botoapp.com Brimir Sim Para até 1 usuário www.getbrimir.com Bug-A-Boo Sim Sim www.bug-a-boo.org BugDigger Sim Não www.bugdigger.com BugHerd Sim Não www.bugherd.com Bugify Sim Não www.bugify.com BugNET Sim Sim www.bugnetproject.com BUGtrack Sim Não www.bugtrack.net Bugs Sim Sim pixeline.github.io/bugs BugTracker.NET Sim Sim www.ifdefined.com Bugzilla Sim Sim www.bugzilla.org Clarizen Sim Não www.clarizen.com

43 DoneDone Sim Não www.getdonedone.com eTraxis Sim Para até 5 usuários www.etraxis.com Eventum Sim Sim www.launchpad.net/eventum Flyspray Sim Sim www.flyspray.org FogBugz Sim Para até 2 usuários www.fogcreek.com Fossil Sim Sim www.fossil-scm.org Gemini Sim Não www.countersoft.com Sim Não www.atlassian.com JTrac Sim Sim www.jtrac.info Kayako Sim Não www.kayako.com Kwok Sim Sim www.kwoksys.com Lighthouse Sim Não www.lighthouseapp.com Mantis Sim Sim www.mantisbt.org oops-easytrack Sim Sim www.oops-easytrack..net phpBugTracker Sim Sim www.github.com/a-v-k/phpBugTracker Pivotal Sim Para até 3 usuários www.pivotaltracker.com qTest Sim Não www.qasymphony.com Redmine Sim Sim www.redmine.org Request Tracker Sim Sim www.bestpractical.com Roundup Sim Sim www.roundup.sourceforge.net RTH Sim Sim www.requirementsandtestinghub. wordpress.com Scarab Sim Sim www.memocomp.de/scarab/1.0.22 Sifter Sim Não www.sifterapp.com Snowy Evening Sim Para até 3 usuários www.snowy-evening.com The Bug Genie Sim Não www.thebuggenie.com TISYM Sim Para até 5 usuários www.tisym.com Trac Sim Sim www.trac.edgewall.org Unfuddle Sim Não www.unfuddle.com VersionOne Sim Não www.versionone.com WebIssues Sim Sim webissues.mimec.org Youtrack Sim Para até 10 usuários www..com zenTrack Sim Sim sourceforge.net/projects/ zentrack Das ferramentas citadas, as que atenderam aos critérios foram: Bloodhound, Bug-A-Boo, BugNET, BugTracker.NET, Bugzilla, Eventum, Flyspray, Fossil, JTrac, Kwok, Mantis, oops-easytrack, phpBugTracker, Redmine, Request Tracker, Roundup, RTH, Scarab, Trac, WebIssues e zenTrack.

Com a seleção dessas ferramentas, a próxima etapa foi tentar encontrar pesquisas que apontassem as três ferramentas mais utilizadas. Foi encontrado um artigo elaborado pela revista Testing Experience que se baseou em uma discussão criada no Linkedin9 pelo engenheiro de testes

9 Linkedin é uma rede social utilizada por profissionais e empresas de qualquer área de atuação.

44 Chakradhara Pernumarthi no grupo Software Testing & Quality Assurance. Ele perguntou se alguém conhecia uma boa ferramenta de gerenciamento de testes e de defeitos open source10. O tópico recebeu 120 comentários dos membros do grupo. Esta pesquisa foi iniciada em Abril de 2010 e foi motivada por outra discussão criada anteriormente neste mesmo grupo intitulada “qual sua ferramenta de bug tracker preferida?” a qual teve 260 comentários. O resultado da pesquisa pode ser visto na Figura 17.

Figura 17. Popularidade das ferramentas bug trackers open source. Fonte: Testing Experience (2010).

As duas discussões proporcionaram a oportunidade de avaliar a popularidade não somente das ferramentas open source, mas também as comerciais que também foram citadas por membros. A Figura 18 apresenta outro gráfico, dessa vez incluindo as ferramentas comercias citadas nas discussões na rede social (em azul) e comparando com os resultados obtidos de uma outra pesquisa, a Open Source Developer Report 2010, conduzida pela comunidade (em vermelho).

10 Open source é o termo usado para definir que um software possui seu código fonte aberto e que pode ser modificado.

45

Figura 18. Popularidade das ferramentas bug trackers open source e comerciais. Fonte: Testing Experience (2010).

Analisando os resultados da discussão no Linkedin e a pesquisa realizada pela comunidade Eclipse, a revista chegou a conclusão que as ferramentas de bug tracker mais populares foram Bugzilla, Jira, Mantis e Trac, sendo que o Jira é uma ferramenta comercial.

Com o intuito de confirmar os resultados apresentados por esta revista em 2010 e verificar se houve mudança de popularidade nestes últimos 5 anos, optou-se por utilizar o Google Trends11 para

11 Google Trends é uma ferramenta do Google que mostra os termos mais populares buscados ao longo do tempo. Permite comparar até cinco termos por vez, através de gráficos. O eixo horizontal do gráfico representa o tempo (a partir de 2004), e o vertical é com que frequência é procurado um termo, globalmente.

46 realizar um comparativo de popularidade de busca por estas ferramentas. Partiu-se do pressuposto que as mais buscadas são as mais populares, logo as mais utilizadas.

As pesquisas com o Google Trends foram realizadas no dia 1 de Maio de 2015. O filtro de país foi configurado com a opção “Todo o mundo”, pois a pesquisa com o filtro “Brasil” apresentava mensagem: “não há volume de pesquisas suficiente para exibir os resultados”. O período da aferição de 2004 até a data de realização do comparativo. Catetoria “Todas as categorias”. O canal de buscas selecionado foi “Pesquisa na Web do Google”. Os termos utilizados para a comparação foram o nome da ferramenta sucedidas pelo termo bug tracker.

A Figura 19 apresenta o comparativo entre as ferramentas Bloodhound, Bug-A-Boo, BugNET, BugTracker e Bugzilla. Pode-se perceber que apenas o Bugzilla apresentou o gráfico de volume de pesquisas.

Figura 19. Comparativo Bloodhound, Bug-A-Boo, BugNET, BugTracker e Bugzilla.

A Figura 20 apresenta o comparativo entre as ferramentas Eventum, Flyspray, Fossil, JTrac e Kwok bug tracker. Nenhuma delas apresentou volume de pesquisas suficiente para exibir gráficos.

47

Figura 20. Comparativo Eventum, Flyspray, Fossil, JTrac e Kwok bug tracker.

A Figura 21 apresenta o comparativo entre as ferramentas Mantis, oops-easytrack, phpBugTracker, Redmine e Request Tracker. Pode-se perceber que o Mantis apresentou um volume de pesquisas maior, enquanto que Redmine apresentou um volume bem inferior.

Figura 21. Comparativo Mantis, oops-easytrack, phpBugTracker, Redmine e Request Tracker.

48 A Figura 22 apresenta o comparativo entre as ferramentas Roundup, RTH, Scarab, Trac e WebIssues. Nota-se que somente Trac apresentou volumes de pesquisas, mas não em todos os anos.

Figura 22. Comparativo Roundup, RTH, Scarab, Trac e WebIssues.

A Figura 23 mostra que a ferramenta zenTrack não possuía volume de pesquisas suficiente para exibir gráficos.

49

Figura 23. Comparativo zenTrack.

Os mesmos comparativos foram feitos com o nome da ferramenta sucedida também pelo termo bug tracking, issue tracker e issue tracking. Diante dos resultados concluiu-se que Bugzilla, Mantis, Redmine e Trac são as ferramentas para gestão de defeitos mais populares. Comparando esta pesquisa com a pesquisa realizada pela revista Testing Experience, chegou-se à mesma conclusão: Bugzilla e Mantis têm uma representação mais expressiva de popularidade, provavelmente por serem ferramentas específicas para gestão de defeitos e por isso oferecem mais recursos que ferramentas como Trac e Redmine, que, apesar de aparecerem nos resultados, tem uma representação bem menor por não serem ferramentas com foco em gestão de defeitos e sim em gerenciamento de projetos, por isso possuem recursos básicos para gestão de defeitos. Analisando esses fatos, as ferramentas Bugzilla e Mantis já foram escolhidas para serem avaliadas. Como as pontuações das ferramentas a partir da terceira posição não tiveram grande expressividade, buscou-se a próxima ferramenta que apresentasse mais recursos e boas práticas de usabilidade baseadas nos 10 princípios heurísticos de Nielsen (1993) e outras apresentadas por Krug (2006). Portanto, agregaria mais valor ao levantamento de requisitos para desenvolver a ferramenta proposta por este trabalho. Com isso, a ferramenta BugNET foi escolhida por ser específica para gestão de defeitos e possuir recursos semelhantes ao Bugzilla e Mantis. Além disso, por possuir interface de usuário com usabilidade aparentemente melhor que as duas primeiras. Então, as três ferramentas de gestão de defeitos que serão avaliadas são Bugzilla, Mantis e BugNET.

Partiu-se então para a busca por ferramentas de gestão de testes, mantendo-se os mesmos critérios adotados na busca por ferramentas de gestão de defeitos. Foram encontradas ferramentas

50 específicas para gestão de casos de testes e outras que possuíam outros módulos como gestão de defeitos e cadastro de requisitos. A Tabela 5 apresenta as ferramentas encontradas.

Tabela 3. Seleção das ferramentas de gestão de testes. Nome Web Gratuita Site oficial ALTM Sim Não www.bstriker.com ApTest Sim Não www.aptest.com Aqua Não Não www.andagon.com Silk Central Sim Não www.borland.com CodeBeamer Sim Não www.codebeamer.com Enterprise Tester Sim Não www.catchsoftware.com Gemini Sim Não www.countersoft.com Quality Center Sim Não www.hp.com Rational Quality Manager Sim Não www-03.ibm.com InformUP Sim Não www.informup.com Jira Zephyr Sim Não www.getzephyr.com Klaros Sim Não www.klaros-testmanagement.com Microsoft Test Manager Sim Não www.visualstudio.com Occygen Sim Não www.occygen.com Overlook Sim Não www.overlook.io PractiTest Sim Não www.practitest.com QAComplete Sim Não www.smartbear.com QATraq Sim Sim sourceforge.net/projects/qatraq QMetry Sim Não www.qmetry.com qTest Sim Não www.qasymphony.com Radi-testdir Sim Sim radi- testdir.sourceforge.net/radi_home.html Rainforest QA Sim Não www.rainforestqa.com RTH Sim Sim requirementsandtestinghub. wordpress.com Sitechco Sim Sim www.sitechco.com SmarteQM Sim Não www.smartesoft.com SpiraTest Sim Não www.inflectra.com Tematoo Sim Sim até 1 www.tematoo.com projeto e 5 usuários Test Case Web Sim Sim tcw.sourceforge.net Test Collab Sim Não www.testcollab.com Tesly Sim Sim tesly.sourceforge.net Testersuite Sim Não www.testersuite.com Testia Tarantula Sim Sim www.tarantula.fi Testitool Sim Sim www.majordojo.com Testlab Sim Não www.melioratestlab.com TestLink Sim Sim www.testlink.org TestLodge Sim Não www.testlodge.com TestLog Sim Não www.testlog.com Testmaster Sim Sim testmaster.sourceforge.net

51 Testpad Sim Não ontestpad.com TestRail Sim Não www.gurock.com/testrail TestRun Sim Não www.runtestrun.com Testopia Sim Sim sourceforge.net/projects/testopia TestTrack Sim Não www.seapine.com Testuff Sim Não www.testuff.com TestWave Sim Não www.testwave.co.uk Tricentis Sim Não www.tricentis.com VersionOne Sim Não www.versionone.com XORICON TestLab Sim Não www.xoricon-testlab.com XQual Sim Sim até 10 www.xqual.com usuários Zephyr Sim Não www.getzephyr.com Das ferramentas citadas, as que atenderam aos critérios foram: QATraq, Radi-testdir, RTH Sitechco, Test Case Web, Tesly, Testia Tarantula, Testitool, TestLink, Testmaster e Testopia.

Para definir as três ferramentas de gestão de testes mais utilizadas, recorreu-se à pesquisa apresentada pela revista Testing Experience. O resultado da pesquisa de popularidade das ferramentas de gestão de testes open source é apresentado na Figura 24.

Figura 24. Popularidade das ferramentas de gestão de testes open source. Fonte: Revista Testing Experience (2010).

52 O Google Trends foi utilizado para comprovar o resultado apresentado pela revista e verificar se houve mudança de popularidade desde que a pesquisa foi realizada em 2010. Da mesma forma que foi feito com as ferramentas de gestão de defeitos, partiu-se do pressuposto que as ferramentas de gestão de testes mais buscadas são as mais populares, logo as mais utilizadas.

As pesquisas com o Google Trends foram realizadas no dia 1 de Maio de 2015. O filtro de país foi configurado com a opção “Todo o mundo”, pois a pesquisa com o filtro “Brasil” apresentava mensagem: “não há volume de pesquisas suficiente para exibir os resultados”. O período da aferição de 2004 até a data de realização do comparativo. Catetoria “Todas as categorias”. O canal de buscas selecionado foi “Pesquisa na Web do Google”. Os termos utilizados para a comparação foram o nome da ferramenta sucedidas pelo termo test management.

A Figura 25 apresenta o comparativo entre as ferramentas QATraq, Radi-testdir, RTH e Sitechco. Pode-se notar que nenhuma das ferramentas apresentou volume de pesquisas suficiente para exibir gráficos.

Figura 25. Comparativo QATraq, Radi-testdir, RTH e Sitechco.

A Figura 26 apresenta o comparativo entre as ferramentas Tesly, Test Case Web, Testia Tarantula e Testitool. Pode-se notar que nenhuma das ferramentas apresentou volume de pesquisas suficiente para exibir gráficos.

53

Figura 26. Comparativo Tesly, Test Case Web, Testia Tarantula e Testitool.

A Figura 27 apresenta o comparativo entre as ferramentas TestLink, Testmaster e Testopia. Pode-se perceber que somente TestLink apresentou volume de pesquisas e, mesmo assim, apenas nos últimos anos.

Figura 27. Comparativo TestLink, Testmaster e Testopia.

54 De todas as ferramentas de gestão de testes usadas na pesquisa, apenas TestLink apresentou um pequeno volume de interesse. Somando-se ao fato de que a pesquisa realizada pela revista Testing Experience apontou TestLink como sendo a ferramenta mais popular, então esta ferramenta de gestão de testes já foi definida como uma das três a serem avaliadas. Como as outras ferramentas não tiveram representação nas pesquisas do Google Trends, passou-se a considerar apenas os resultados apresentados pela revista. Esta apontou que a segunda ferramenta mais popular foi Testopia, um plugin que pode ser instalado ao bug tracker Bugzilla para adicionar funcionalidades de gestão de testes. Então, esta ferramenta também será avaliada neste trabalho. A terceira ferramenta citada na pesquisa foi Redmine, que não será avaliada por este trabalho por ser uma ferramenta para gestão de projetos e não possuir funcionalidades específicas para gestão de testes. A próxima ferramenta citada foi RTH que é uma ferramenta que integra requisitos, gestão de defeitos e de testes, porém já está a quase dez anos sem receber atualizações. Na sequência, XQual Studio possui uma versão gratuita, mas limitada a 10 usuários, 1000 testes e poucos recursos. Como as pontuações das ferramentas a partir da terceira posição não tiveram grande expressividade, buscou-se a próxima ferramenta que apresentasse mais recursos e boas práticas de usabilidade baseadas nos 10 princípios heurísticos de Nielsen (1993) e outras apresentadas por Krug (2006). Portanto, agregaria mais valor ao levantamento de requisitos para desenvolver a ferramenta proposta por este trabalho. Com isso, a ferramenta Testia Tarantula foi escolhida por ser específica para gestão de testes e possuir recursos semelhantes ao TestLink. Apesar de possui menos recursos, possui interface de usuário com usabilidade aparentemente melhor que TestLink. Portanto, as três ferramentas de gestão de testes que serão avaliadas neste trabalho serão Testlink, Testopia e Testia Tarantula.

3.3 CRITÉRIOS PARA AVALIAR AS FERRAMENTAS

Para avaliar as ferramentas, optou-se por utilizar os 10 princípios heurísticos e a classificação de severidade dos problemas de usabilidade, ambas de Nielsen (1993) e cujas definições e exemplos foram apresentados no Capítulo 2.

3.4 AVALIAÇÃO DAS FERRAMENTAS

Neste capítulo serão apresentadas cada uma das seis ferramentas selecionadas para serem avaliadas por este trabalho, suas funcionalidades e avaliação de usabilidade.

3.4.1 TestLink Test Management Tool É um software web desenvolvido para gerenciamento de teste de software que visa facilitar a organização dos testes a serem aplicados e a divisão destes entre os testadores que irão executá-los. É

55 gratuito, possui código aberto, desenvolvido e mantido por uma comunidade de desenvolvedores e teve sua primeira versão liberada em Outubro de 2003. Permite a criação de requisitos, projetos de teste, planos de teste, casos de teste e permite integração com bug trackers como Mantis, Bugzilla, Jira, Redmine, entre outros.

Esta integração resume-se apenas a adicionar um link no caso de teste com o qual foi encontrado o defeito para o relato de defeito cadastrado nas ferramentas externas, ou seja, o TestLink não possui seu próprio gerenciador de defeitos. Conta com suporte para relatórios e estatísticas. Permite definir perfis de acesso e os papéis no projeto de forma personalizada para cada usuário. É desenvolvido em linguagem de programação PHP e possui suporte nativo para os bancos de dados MySQL e PostgreSQL. Suporta autenticação no sistema através do protocolo LDAP. Está disponível em 17 idiomas diferentes, dentre eles o Português (Brasil). A versão avaliada foi a 1.9.13 datada de 07/02/15 e sua página principal é apresentada na Figura 28.

Figura 28. TestLink: página principal.

3.4.1.1 Funcionalidades

Cadastrar usuários: permite que sejam cadastrados usuários com os seguintes atributos: login, nome, sobrenome, senha, e-mail, perfil de acesso, idioma.

Ativar e desativar usuários: permite ativar ou desativar usuários.

56 Autenticação LDAP: permite a autenticação de usuários no sistema por meio de consulta a uma base LDAP externa.

Log de operações do usuário: apresenta os registros de todas as operações feitas por cada usuário no sistema.

Visualizar usuários cadastrados: permite que sejam visualizados em uma tabela os usuários cadastrados no sistema. As colunas da tabela permitem a ordenação crescente e decrescente.

Perfis de usuários: permite editar os perfis padrão do sistema, como o guest, tester, admin, leader ou criar novos perfis personalizados que definem quais operações o usuário poderá realizar no sistema.

Exportar usuários cadastrados: permite que os usuários cadastrados sejam exportados para um arquivo no formato XML. É possível definir o nome do arquivo.

Cadastrar projetos de teste: permite cadastrar projetos com os seguintes atributos: nome, descrição,

Clonar projetos de teste: permite cadastrar um novo projeto a partir de outro já cadastrado.

Definir projetos de teste ativo ou inativo: define se o projeto está ativo ou inativo no sistema.

Definir projetos de teste privado ou público: define se o projeto poderá ser visualizado por qualquer usuário do sistema ou apenas por usuários com perfil de acesso.

Atribuir papéis do projeto de teste: permite que sejam definidos de maneira personalizada para cada projeto de teste, quais os perfis de acesso que os usuários terão.

Integrar o projeto de testes com gerenciador de defeitos: permite configurar a integração do projeto softwares do tipo bug trackers como Bugzilla, Mantis, entre outros.

Cadastrar requisitos: permite cadastrar requisitos com os seguintes atributos: número de identificação, título, escopo, estado (esboço, revisão, retrabalho, entre outros), tipo (informacional, característica, caso de uso, entre outros) e número de casos de teste necessários.

Relação entre requisitos: permite criar uma relação entre requisitos cadastrados: pai de, filho de, entre outros.

Anexar arquivo ao requisito: permite que sejam anexados arquivos aos requisitos. É possível inserir uma descrição para o anexo.

57 Exportar requisitos: permite importar requisitos a partir de um arquivo no formato XML. Permite definir ações para requisitos congelados e duplicados.

Importar requisitos: permite importar requisitos a partir de um arquivo no formato XML. Permite definir ações para requisitos congelados e duplicados.

Pesquisar requisitos: permite pesquisar usando como critérios qualquer um dos atributos do requisito.

Cadastrar plano de teste: permite cadastrar planos de teste com os seguintes atributos: nome, descrição.

Clonar plano de teste: permite cadastrar um novo plano de teste a partir de outro já cadastrado.

Definir plano de teste ativo ou inativo: define se o plano de teste está ativo ou inativo no sistema.

Definir plano de teste privado ou público: define se o plano de teste poderá ser visualizado por qualquer usuário do sistema ou apenas por usuários com perfil de acesso.

Atribuir papéis do plano de teste: permite que sejam definidos de maneira personalizada para cada plano de teste, quais os perfis de acesso que os usuários terão.

Cadastrar baselines: permite cadastrar baselines (releases) para o plano de teste com os seguintes atributos: título, descrição, se está ativo ou inativo, se está aberto ou fechado e data do release.

Cadastrar marcos: permite cadastrar marcos com os seguintes atributos: nome, data alvo, data de início, e porcentagem da prioridade.

Cadastrar casos de teste: permite que sejam cadastrados casos de teste com os seguintes atributos: título, objetivo do teste, pré-condições, estado, prioridade (baixa, média, alta), tipo de execução (manual ou automatizado), tempo de duração estimada (min), associação de palavras-chave, passos e resultados esperados.

Relação entre casos de teste: permite criar uma relação entre casos de teste cadastrados: pai de, filho de, entre outros.

Anexar arquivo ao caso de teste: permite que sejam anexados arquivos aos casos de teste. É possível inserir uma descrição para o anexo.

58 Pesquisar casos de teste: permite pesquisar usando como critérios qualquer um dos atributos do caso de teste.

Adicionar casos de teste ao plano de teste: permite adicionar casos de teste a um plano de teste.

Adicionar casos de teste para execução: permite associar, individualmente, os casos de teste para um ou mais usuários executarem.

Executar casos de teste: permite ao usuário visualizar os passos e resultados esperados de cada caso de teste e gravar resultado passou, com falha ou bloqueado. Permite adicionar comentários.

Criação de campos personalizados: permite que seja criado um novo campo do tipo: string, numeric, checkbox, entre outros, e o label que será apresentado para o campo. Pode ser criado para as telas Baseline, Suíte de Teste, Plano de Teste, Caso de Teste, Especificação de Requisitos e Requisito.

Relatórios: permite visualizar e imprimir relatórios do plano de teste com tipos como: estado geral do plano de teste, resultados por testador.

3.4.1.2 Avaliação de usabilidade Na barra de menu superior, à esquerda, estão localizados os links para as páginas “Projeto”, “Especificar Requisitos”, “Especificar Testes”, “Executar Testes”, “Relatórios”, “Administração” e “Eventos”. Os links são representados por ícones pequenos e sem labels12 para identificá-los. Por muitas vezes o usuário irá recorrer aos tooltips13 para identificar a função de cada um, como pode ser visto na Figura 29. Uma solução seria associar um label para cada ícone para representar a sua função e aumentar o seu tamanho dando assim maior destaque.

Figura 29. TestLink: links do menu superior representados por ícones pequenos e sem labels.

12 Label é um elemento da linguagem HTML que fornece uma legenda para identificar a função de outros elementos HTML presentes na interface. 13 Tooltip é um elemento da linguagem HTML que fornece uma explicação adicional, em forma de moldura pop-up, que abre quando o usuário posiciona o mouse sobre um elemento da interface.

59 Ao lado encontra-se um campo de busca que também não possui label, apenas utiliza o atributo placeholder14para apresentar o valor “1-” dentro do input text15conforme Figura 30. O usuário terá que fazer uma tentativa de busca, provavelmente incorreta, para descobrir que esta pesquisa limita-se apenas aos casos de teste, por isso o prefixo “1-”, pois os casos de teste cadastrados possuem um prefixo para identificar a qual plano de teste estão associados.

Figura 30. TestLink: campo de pesquisa na barra superior é somente para casos de teste.

No canto superior direito encontra-se a combobox 16 com o label “Projeto de Teste”. Este é o elemento mestre, pois os demais links, principalmente os ícones na mesma barra de menus à esquerda, ao serem clicados, irão buscar os dados relacionados a esse projeto. Neste caso, uma solução de melhoria seria inverter as posições na barra de menus superior, colocando a seleção do “Projeto de Teste” à esquerda e o grupo de links que contém “Especificar requisitos”, “Especificar Testes” à direita. Assim, a seleção do projeto será um dos primeiros elementos que o usuário verá na tela.

Abaixo do menu superior, há um menu do lado esquerdo e outro do lado direito, como foi apresentado na Figura 28. Um usuário pouco familiarizado com a ferramenta terá que percorrer um menu e depois o outro no outro lado da tela, pois estão visualmente distantes.

Na tela “Administração de Usuários”, há campos e botões posicionados abaixo da tabela, como o botão para criar novos usuários e o campo para acessar um usuário diretamente pelo seu login. A medida que os usuários são cadastrados e esta lista aumenta, os botões somem do campo de visão do usuário fazendo com que em um primeiro momento não os encontre e depois tenha que rolar a página até o final para poder encontra-los, como mostra a Figura 31.

14 Placeholder é um atributo da linguagem HTML que permite fornecer ao usuário uma dica de contexto auxiliando-o sobre como preencher determinado campo. 15 Input text é um elemento da linguagem HTML para entrada de dados no qual o usuário pode preencher com letras, números ou caracteres especiais. 16 Combo box é um elemento da linguagem HTML que permite apresentar ao usuário uma lista de opções para que possa selecionar uma delas.

60

Figura 31. TestLink: botão criar usuário posicionado após a tabela.

Na tela “Gerenciar Projeto de Teste” é possível criar um novo projeto, mas após fazer isso a ferramenta não apresenta mensagem confirmando o sucesso da operação. Também não apresenta links para as próximas operações que o usuário provavelmente irá desejar fazer, como criar um Plano de Teste ou Caso de Teste, por exemplo.

Na criação de um projeto, a ferramenta TestLink solicita o preenchimento de um ID17 para associar aos casos de teste pertencentes a ele, como mostra a Figura 32. Este ID não pode ser igual a outros já cadastrados em outros projetos. Como o usuário não tem a informação, nesta tela, de quais já estão cadastrados, ele terá que arriscar um id que ainda não esteja cadastrado ou ir até a tela de visualização dos projetos cadastrados. Uma solução melhor seria o sistema oferecer a opção de gerar o ID automaticamente e se o usuário optar por digitar um prefixo, que o sistema exiba em tempo real uma lista apresentando se os caracteres que estão sendo digitados já existem.

17 ID é a sigla para Identity, que em Português significa identidade. Em computação, é um atributo geralmente utilizado para identificar de forma única um registro em um banco de dados.

61

Figura 32. TestLink: usuário precisa digitar um ID único ao cadastrar um novo projeto.

Se um projeto de teste selecionado não possui nenhum plano de teste cadastrado, o ícone “Executar Testes” no menu superior não é exibido. O ícone “Especificar requisitos” também não é apresentado se, no cadastro do projeto, não tiver sido habilitada a opção “Habilitar a funcionalidade de Requisitos”. As opções poderiam estar visíveis para o usuário, porém desabilitadas. Outra alternativa seria deixar os ícones habilitados, mas apresentar uma mensagem informando ao usuário o porque que tais funcionalidades não estão disponíveis.

A ferramenta permite realizar a pesquisa avançada de requisitos (Figura 33), pesquisa avançada de casos de teste (Figura 34) e pesquisa avançada de casos de teste por usuário (Figura 35). As pesquisas possuem campos semelhantes, entretanto estão em telas separadas e, além do mais, os formulários possuem padrões diferentes. Para melhorar, poderia ser criado uma única tela contemplando estas três pesquisas e adicionar um campo em que o usuário selecione se quer pesquisar por requisitos ou casos de teste.

62 Figura 33. TestLink: página de pesquisa de requisitos.

Figura 34. TestLink: página de pesquisa de casos de teste.

63

Figura 35. TestLink: página de pesquisa de casos de teste criados por usuário.

Na tela “Especificar Testes” é possível criar Suítes de Teste e Casos de Teste, mas as opções representadas por ícones, como mostrado na Figura 36, ficam ocultas e somente são exibidas ao clicar- se no ícone de “roda dentada” logo acima. Toda vez que o usuário desejar executar uma das opções disponíveis como criar, editar excluir, importar, exportar casos ou suítes de teste, terá que primeiro clicar no ícone para exibir as opções e depois tentar descobrir qual a opção desejada por meio dos ícones apresentados. Seria melhor se as opções estivessem sempre visíveis e tivessem labels associados ao ícones para fácil identificação do usuário.

Figura 36. TestLink: é necessário clicar no ícone para mostrar as opções da Suíte e Caso de teste.

Na edição de um caso de teste é possível criar relações com outros casos de teste, como pode ser visto na Figura 37. Para criar as relações é necessário digitar no campo de texto o prefixo (identificação do projeto), “-” e o id (identificação do caso de teste), forçando, provavelmente, o usuário a ter que sair dessa tela ou abrir outra por conta própria para descobrir qual a identificação do caso de teste que deseja criar a relação. Uma forma de melhorar a usabilidade seria trocar o campo de

64 texto por um combo box de seleção de caso de teste com opção de auto completar o que está sendo digitado.

Figura 37. TestLink: é necessário saber o id do caso de teste antes de criar a relação.

A ferramenta não apresenta a visualização dos planos de teste em andamento, nem mesmo nos relatórios. Poderia exibir na tela principal a visão geral dos planos de teste em andamento.

Outros problemas, de menor gravidade, foram percebidos. O idioma Português Brasil foi configurado para o usuário, porém muitos labels não foram traduzidos e eram apresentados em Inglês.

3.4.2 Testopia Testopia é uma extensão para o Bugzilla que provê recursos de gerenciamento de casos de teste. Foi projetado para ser uma ferramenta genérica para rastreamento de casos de teste, permitindo às equipes de teste integrarem relatos de erros resultantes da execução dos casos de teste. A versão avaliada foi a 2.0 e uma amostra de sua interface é mostrada na Figura 38.

65

Figura 38. Testopia: página de visualização do estado das execuções dos testes.

3.4.2.1 Funcionalidades

Cadastrar plano de teste: permite cadastrar planos de teste com os seguintes atributos: nome, descrição.

Clonar plano de teste: permite cadastrar um novo plano de teste a partir de outro já cadastrado.

Definir plano de teste ativo ou inativo: define se o plano de teste está ativo ou inativo no sistema.

Definir plano de teste privado ou público: define se o plano de teste poderá ser visualizado por qualquer usuário do sistema ou apenas por usuários com perfil de acesso.

Cadastrar builds: permite cadastrar baselines (releases) para o plano de teste com os seguintes atributos: título, descrição, se está ativo ou inativo, se está aberto ou fechado e data do release.

Cadastrar casos de teste: permite que sejam cadastrados casos de teste com os seguintes atributos: título, objetivo do teste, pré-condições, estado, prioridade (baixa, média, alta), tipo de execução (manual ou automatizado), tempo de duração estimada (min), associação de palavras-chave, passos e resultados esperados.

66 Relação entre casos de teste: permite criar uma relação entre casos de teste cadastrados: depende de, bloqueia.

Anexar arquivo ao caso de teste: permite que sejam anexados arquivos aos casos de teste. É possível inserir uma descrição para o anexo.

Pesquisar casos de teste: permite pesquisar usando como critérios qualquer um dos atributos do caso de teste.

Adicionar casos de teste ao plano de teste: permite adicionar casos de teste a um plano de teste.

Adicionar casos de teste para execução: permite associar, individualmente, os casos de teste para um ou mais usuários executarem.

Executar casos de teste: permite ao usuário visualizar os passos e resultados esperados de cada caso de teste e gravar resultado passou, com falha ou bloqueado.

Relatórios: permite visualizar e imprimir relatórios do plano de teste com tipos como: estado geral do plano de teste, resultados por testador.

3.4.2.2 Avaliação de usabilidade

O Testopia é um plugin que pode ser instalado no Bugzilla para agregar funcionalidades de gestão de testes à gestão de defeitos, e isso é percebido na interface. Na Figura 39 é possível visualizar o menu de opções do Testopia posicionado abaixo do menu do Bugzilla. Como resultado dessa adição de funções ao Bugzilla, fica evidente que existem dois sistemas funcionando em um só. O menu do Bugzilla possui a opção “Search”. O Testopia também. Os dois menus também possuem um campo para pesquisa, mas enquanto um possui o botão identificado como “Search” o outro possui o botão identificado como “Find”. Além do mais, os botões possuem estilos diferentes.

Figura 39. Testopia: menu com as operações para gestão de defeitos e testes.

Nas tabelas que apresentam registros, há campos de pesquisa, mas não há botão associado para executar a pesquisa, pois a tecla “Enter” deve ser pressionada, como pode ser vista na Figura 40. O

67 usuário terá que descobrir isto por conta própria, pois não tem informação ou dica e há diferença de padrão em relação ao campo de pesquisa do menu superior.

Figura 40. Testopia: é necessário pressionar Enter após digitar o termo de pesquisa no campo.

3.4.3 Testia Tarantula É um software web desenvolvido para gerenciamento de teste de software em projetos ágeis que visa facilitar a organização dos testes a serem aplicados e a divisão destes entre os testadores que irão executá-los. É o mais atual das três ferramentas de gestão de testes e possui uma interface com aparência mais moderna. É gratuito, possui código aberto e teve sua primeira versão liberada em 2008. Permite a criação de requisitos, projetos de teste, planos de teste, casos de teste e permite integração com os bug trackers Bugzilla e Jira. Esta integração resume-se apenas a adicionar um link no caso de teste com o qual foi encontrado o defeito para o relato de defeito cadastrado nas ferramentas externas, ou seja, o Testia Tarantula não possui seu próprio gerenciador de defeitos. Conta com suporte para relatórios e estatísticas. É desenvolvido em linguagem de programação . A versão avaliada foi a 2012.45.0 e sua página principal é apresentada na Figura 41.

68

Figura 41. Testia Tarantula: página de execução de casos de teste.

3.4.3.1 Funcionalidades

Cadastrar usuários: permite que sejam cadastrados usuários com os seguintes atributos: login, nome, e-mail, telefone e se o usuário terá perfil admin ou não.

Visualizar usuários cadastrados: permite que sejam visualizados em uma lista os usuários cadastrados no sistema.

Cadastrar projetos de teste: permite cadastrar projetos com os seguintes atributos: nome, descrição.

Atribuir papéis do projeto de teste: permite que sejam definidos de maneira personalizada para cada projeto de teste, quais os perfis de acesso que os usuários terão.

Integrar o projeto de testes com gerenciador de defeitos: permite configurar a integração do projeto softwares do tipo bug trackers como Bugzilla, Jira, entre outros.

Cadastrar requisitos: permite cadastrar requisitos com os seguintes atributos: nome, data, identificação, prioridade, data de modificação, tags, áreas de teste e descrição.

Anexar arquivo ao requisito: permite que sejam anexados arquivos aos requisitos. É possível inserir uma descrição para o anexo.

69 Cadastrar plano de teste: permite cadastrar planos de teste com os seguintes atributos: nome, data, prioridade (baixa, normal, alta) e tags.

Cadastrar casos de teste: permite que sejam cadastrados casos de teste com os seguintes atributos: título, data, prioridade, duração estimada, áreas de teste, duração média, tags, objetivo, dados de teste, pré-condições, comentário, passos e resultados esperados.

Anexar arquivo ao caso de teste: permite que sejam anexados arquivos aos casos de teste. É possível inserir uma descrição para o anexo.

Adicionar casos de teste ao plano de teste: permite adicionar casos de teste a um plano de teste.

Adicionar casos de teste para execução: permite associar, individualmente, os casos de teste para um ou mais usuários executarem.

Executar casos de teste: permite ao usuário visualizar os passos e resultados esperados de cada caso de teste e gravar resultado passou, com falha, pular ou não implementado. Permite adicionar comentários.

Relatórios: permite visualizar e imprimir relatórios do plano de teste com tipos como: estado geral do plano de teste, resultados por testador.

3.4.3.2 Avaliação de usabilidade

As telas que possuem cadastros, como Usuários, Requisitos, Projetos, Casos de teste, não utilizam tabelas para apresentar os registros. Ao invés disso, apresenta uma lista dos registros na lateral esquerda, ou seja, não é possível ordenar os registros nem visualizar alguns de seus atributos sem ter que selecioná-los. Acima das listas existe um campo, sem qualquer identificação, que serve para pesquisar um registro específico, mas não há filtros de pesquisa pré-definidos, nem básicos nem avançados, como pode ser visto na Figura 42.

70 Figura 42. Testia Tarantula: página de visualização dos usuários cadastrados.

Para incluir casos de teste ao plano de teste, o usuário deve selecionar o caso na área “Cases” e arrastar para a área “Included Cases”, como mostrado na Figura 43. O problema é que o usuário pode demorar a descobrir que deve fazer isso, pois não há nenhuma informação na tela. Uma simples frase “Arraste os casos de teste para cá” já resolveria tal problema.

71

Figura 43. Testia Tarantula: página de adição de casos de teste ao plano de teste.

3.4.4 Mantis Bug Tracker

Ferramenta Web, gratuita e de código aberto que foi disponibilizada ao público pela primeira vez em Novembro de 2000. Esta ferramenta para gestão de defeitos permite o gerenciamento dos relatos de defeitos encontrados durante o desenvolvimento e testes de um software. Oferece workflow para o acompanhamento do defeito desde a sua criação, atribuição ao responsável para correção e outras etapas até o seu fechamento. Possui configuração de perfis de acesso personalizado para cada usuário, garantindo assim controle de acesso aos projetos. Os usuários com permissão de acesso ao projeto podem incluir comentários em um relato de defeito enquanto este estiver aberto. E-mails podem ser enviados automaticamente pelo sistema para informar os usuários sobre mudanças realizadas nos relatos em que estão associados. É desenvolvida em linguagem PHP e conta com suporte aos bancos de dados MySQL, MS SQL, PostgreSQL e DB2. Está disponível em 53 idiomas diferentes, dentre eles o Português (Brasil). A versão avaliada foi a 1.2.19 datada de 26/01/15 e sua página principal é apresentada na Figura 44.

72

Figura 44. Mantis: página principal.

3.4.4.1 Funcionalidades

Cadastrar usuários: permite cadastrar usuários com os seguintes atributos: nome de usuário, nome verdadeiro, e-mail e senha.

Ativar e desativar usuários: permite ativar ou desativar usuários.

Perfis de usuários: permite definir níveis de acesso aos usuários do sistema como visualizador, relator, atualizador, desenvolvedor, gerente, administrador.

Suporte a autenticação através do protocolo LDAP: permite a autenticação de usuários no sistema por meio de consulta a uma base LDAP externa.

Cadastrar projetos para relato de defeitos: permite cadastrar projetos para relatos de defeitos.

Cadastrar subprojeto ou categorias: permite cadastrar categorias e associar a um projeto de defeito existente.

Definir projetos de defeitos ativo ou inativo: permite definir se o projeto está ativo ou inativo

Definir projetos de defeitos privado ou público: permite definir a visibilidade do projeto como público ou privado.

73 Perfil de acesso, personalizado por usuário, para cada projeto cadastrado: permite definir perfis de acesso aos projetos, por usuário.

Cadastrar relato de defeito: permite que o usuário cadastre relatos de defeito com os seguintes atributos: categoria do projeto, frequência, gravidade, prioridade, atribuir a, resumo, descrição, passos para reproduzir, informações adicionais.

Anexar arquivos ao relato de defeito: permite anexar arquivos ao relato de defeito.

Definir relato de defeito público ou privado: permite definir se a visibilidade do relato será publica ou privada.

Adicionar comentários a um relato de defeito: permite aos usuários adicionar comentários no relato de defeito.

Clonar relato de defeito: permite criar um novo relato a partir de outro já existente.

Monitorar relato de defeito: permite que o usuário receba e-mails notificando sobre qualquer modificação realizada no relato.

Definir caso como pegajoso: permite que o caso seja sempre apresentado no topo da lista.

Criar relação entre relatos de defeitos cadastrados: permite criar relação com outros defeitos cadastrados.

Pesquisar relatos de defeitos cadastrados: permite que os relatos sejam listados e possam ser utilizados filtros para pesquisar relatos de defeito.

Notificações por e-mail: permite que os usuários possam receber notificações por e-mail sobre modificações no relato.

Fluxo de trabalho para resolução de um caso de defeito (Workflow): permite que sejam definidos o estado e atribuição do defeito a um usuário para resolução.

Histórico de mudanças efetuadas no relato: apresenta os registros de todas as operações feitas por cada usuário no sistema.

Criação de campos personalizados: permite criar campos personalizados.

3.4.4.2 Avaliação de usabilidade

Em várias telas em que o usuário iniciou um cadastro, não é apresentada a opção cancelar, como apresentado na Figura 45. O usuário tem que clicar no botão voltar do navegador ou simplesmente clicar em um item do menu para ir para outra tela.

74

Figura 45. Mantis: formulários não apresentam a opção Cancelar.

Se o usuário está com o formulário preenchido e clica em outra opção do menu, o sistema não pergunta se o usuário deseja realmente sair da tela atual e perder as informações.

A ferramenta permite anexar arquivos ao relato de defeito, porém somente um por vez, como pode ser visto na Figura 46. Se o usuário tiver mais que um arquivo para anexar, terá que anexar um no momento em que envia o relato de defeito e os demais acessando o relato do defeito, sempre um por vez.

Figura 46. Mantis: permite anexar apenas um arquivo por vez no relato de defeito.

A ferramenta oferece funcionalidades para os casos de teste, como mostrado na Figura 47. As funções “Monitorar” e “Marcar como Pegajoso” estão entre elas, mas suas ações não são tão óbvias para o usuário, ou seja, o que irá acontecer após clicar nesses botões. A funcionalidade “Monitorar” permite ao usuário acompanhar quaisquer modificações no caso através de notificações por e-mail, além de ser apresentado na tela “Visão Geral”, na área “Monitorados por mim”. Já a funcionalidade “Marcar como pegajoso” faz com que o caso sempre apareça no topo da lista de visualização de defeitos. O recurso tooltip poderia ser utilizado para apresentar uma breve descrição ao usuário quando este posicionar o ponteiro do mouse sobre estes botões.

Figura 47. Mantis: ações “Monitorar” e “Marcar como Pegajoso” não são óbvias para o usuário.

A ferramenta permite criar a relação de relatos de defeito como sendo “pai”, “filho”, “duplicado” e “relacionado” de um outro relato. O usuário seleciona o tipo de relação e em seguida deve digitar no campo o número do relato com o qual deseja-se criar a relação, mas não há label no

75 campo para deixar isto claro, como mostrado na Figura 48. Como não há uma lista para selecionar qual o relato, o usuário deve ter o número na memória, caso contrário, se digitar um número não cadastrado ou caracteres não numéricos e clicar em “Adicionar”, ele será levado para outra tela em que será dito que o caso não foi encontrado. O campo poderia ter um label indicando o que deve ser digitado e validar em tempo real o que o usuário digitou para informa-lo se o número é válido ou uma lista para selecionar o relato.

Figura 48. Mantis: relação entre relatos de defeito obriga o usuário a saber o número do caso.

3.4.5 Bugzilla Bug-Tracking System

Lançada em Agosto de 1998, é uma ferramenta para rastreamento de defeitos que permite a uma equipe de desenvolvimento manter o controle dos bugs encontrados em seus produtos de software. É Web, gratuita e de código aberto. Esta ferramenta oferece funcionalidades semelhantes ao Mantis como: cadastrar relatos de defeitos, pesquisar os relatos cadastrados, gerenciar o workflow com as etapas para resolução dos defeitos com envio de e-mails. O diferencial desta ferramenta é permitir a instalação do plugin Testopia, que adiciona as funcionalidades de gerenciamento de casos de teste. Disponível em 10 idiomas, mas não em Português. Suporta os bancos de dados MySQL, PostgreSQL, Oracle e SQLite. A versão avaliada foi a 4.4.9 datada de 15/04/15 e uma amostra de sua interface é apresentada na Figura 49.

76

Figura 49. Bugzilla: página de pesquisa de relatos de defeito.

3.4.5.1 Funcionalidades

Cadastrar usuários: permite cadastrar usuários com os seguintes atributos: nome de usuário, nome verdadeiro, e-mail e senha.

Ativar e desativar usuários: permite ativar ou desativar usuários.

Perfis de usuários: permite definir níveis de acesso aos usuários do sistema como visualizador, relator, atualizador, desenvolvedor, gerente, administrador.

Suporte a autenticação através do protocolo LDAP: permite a autenticação de usuários no sistema por meio de consulta a uma base LDAP externa.

Cadastrar projetos para relato de defeitos: permite cadastrar projetos para relatos de defeitos.

Cadastrar subprojeto ou categorias: permite cadastrar categorias e associar a um projeto de defeito existente.

Definir projetos de defeitos ativo ou inativo: permite definir se o projeto está ativo ou inativo

Definir projetos de defeitos privado ou público: permite definir a visibilidade do projeto como público ou privado.

77 Cadastrar build/versão do projeto: permite que sejam cadastradas versões de software que o projeto possui.

Definir a disponibilidade de build/versão: permite definir se determinada versão não deve ser exibida.

Perfil de acesso, personalizado por usuário, para cada projeto cadastrado: permite definir perfis de acesso aos projetos, por usuário.

Cadastrar relato de defeito: permite que o usuário cadastre relatos de defeito com os seguintes atributos: categoria do projeto, frequência, gravidade, prioridade, atribuir a, resumo, descrição, passos para reproduzir, informações adicionais.

Alternar formulário de relato entre básico e avançado: permite que seja alterado o modo de exibição do formulário entre básico (informações essenciais) e avançado (informações adicionais).

Anexar arquivos ao relato de defeito: permite anexar arquivos ao relato de defeito.

Definir relato de defeito público ou privado: permite definir se a visibilidade do relato será publica ou privada.

Adicionar comentários a um relato de defeito: permite aos usuários adicionar comentários no relato de defeito.

Clonar relato de defeito: permite criar um novo relato a partir de outro já existente.

Monitorar relato de defeito: permite que o usuário receba e-mails notificando sobre qualquer modificação realizada no relato.

Definir caso como pegajoso: permite que o caso seja sempre apresentado no topo da lista.

Pesquisar relatos de defeitos cadastrados: permite que os relatos sejam listados e possam ser utilizados filtros para pesquisar relatos de defeito.

Notificações por e-mail: permite que os usuários possam receber notificações por e-mail sobre modificações no relato.

Fluxo de trabalho para resolução de um caso de defeito (Workflow): permite que sejam definidos o estado e atribuição do defeito a um usuário para resolução.

Histórico de mudanças efetuadas no relato: apresenta os registros de todas as operações feitas por cada usuário no sistema.

Criação de campos personalizados: permite criar campos personalizados.

78 3.4.5.2 Avaliação de usabilidade

A ferramenta deixa o usuário um pouco confuso ao acessá-la, pois a tela de autenticação não é a primeira a ser apresentada. A autenticação pode ser realizada pelo link “Log in” localizado sem nenhum destaque entre os links do menu superior. Outra forma é clicando na opção “New” para relatar um defeito, que irá apresentar a tela de autenticação.

Na tela de pesquisa de relatos de defeitos, acessada pelo link “Browse”, o usuário encontra uma lista com os projetos cadastrados na qual precisa encontrar o projeto desejado como mostrado na Figura 50. Quanto maior esta lista, maior a probabilidade de o usuário demorar para encontrar o produto desejado.

Figura 50. Bugzilla: página de seleção de projeto para pesquisa de defeitos.

Após clicar no produto desejado, será apresentada a página com a lista dos componentes pertencentes a este produto, como pode ser visto na Figura 51. Mesmo problema citado na escolha do produto. Uma solução seria ter na tela anterior uma combo box para escolha do produto e do componente, com a opção de auto completar o que está sendo digitado.

79

Figura 51. Bugzilla: página de seleção do componente do projeto para pesquisa dos defeitos.

Para relatar defeitos, o usuário deve clicar em “New” e, novamente, é apresentada a página para seleção do produto antes de acessar a página em que vai preencher o relato. É possível anexar arquivos ao relato, como mostra a Figura 52, mas somente um por vez, seja no cadastro ou na edição. Na edição, ao clicar no anexo para visualizá-lo (caso seja uma figura), o usuário é levado para outra página onde é apresentada a figura e não há botões ou links para voltar para o relato de defeito. O usuário então tem que clicar no botão voltar do navegador para voltar para o relato. O mesmo acontece quando o usuário deseja inserir um novo anexo ao relato. Quando clica no link, é levado para outra página e, da mesma forma, não há link para retornar ao relato e tem que recorrer ao botão do navegador.

Figura 52. Bugzilla: permite anexar apenas um arquivo por vez no relato de defeito.

A visualização do histórico de modificações do relato de defeito é acessada através do link “History” no qual o usuário também é levado para outra página como mostrado na Figura 53.

80

Figura 53. Bugzilla: histórico de modificações do relato de defeito.

Os títulos das páginas correntes são apresentados acima do menu superior, fora da área do conteúdo que o usuário está visualizando como pode ser visto na Figura 54.

Figura 54. Bugzilla: títulos das páginas são apresentadas acima do menu superior.

3.4.6 BugNET Este software gerenciador de defeitos possui as principais características e funcionalidades encontradas nas ferramentas Bugzilla e Mantis. Seu maior diferencial em relação às outras duas é sua interface, com aparência mais atual. Possui também outros diferenciais como permitir a personalização para cada projeto de estados, prioridades, classificação dos defeitos. Sua primeira versão foi lançada em Setembro de 2011. A avaliação foi realizada com a versão 1.5.99 de Agosto de 2014. A Figura 55 apresenta sua página principal.

81

Figura 55. BugNET: Página principal.

3.4.6.1 Funcionalidades

Cadastrar usuários: permite cadastrar usuários com os seguintes atributos: nome de usuário, nome verdadeiro, e-mail e senha.

Ativar e desativar usuários: permite ativar ou desativar usuários.

Perfis de usuários: permite definir níveis de acesso aos usuários do sistema como visualizador, relator, atualizador, desenvolvedor, QA, administrador.

Suporte a autenticação através do protocolo LDAP: permite a autenticação de usuários no sistema por meio de consulta a uma base LDAP externa.

Cadastrar projetos para relato de defeitos: permite cadastrar projetos para relatos de defeitos.

Cadastrar subprojeto ou categorias e associar a um projeto de defeitos existente: permite cadastrar categorias e associar a um projeto de defeito existente.

Definir projetos de defeitos ativo ou inativo: permite definir se o projeto está ativo ou inativo

Definir projetos de defeitos privado ou público: permite definir a visibilidade do projeto como público ou privado.

82 Anexar imagem ao projeto: permite anexar uma imagem qualquer para ser apresentada junto ao nome do projeto, auxiliando assim na identificação do mesmo.

Perfil de acesso, personalizado por usuário, para cada projeto cadastrado: permite definir perfis de acesso aos projetos, por usuário.

Suporte à integração do projeto de defeito com Subversion: permite configurar integração com servidor de versionamento de código.

Cadastrar relato de defeito: permite que o usuário cadastre relatos de defeito com os seguintes atributos: título, estado, usuário que criou, prioridade, marcos afetados, atribuído à, categoria, data de vencimento, tipo do defeito, porcentagem concluída, marcos, estimação, resolução, descrição.

Anexar arquivos ao relato de defeito: permite anexar arquivos ao relato de defeito.

Definir relato de defeito público ou privado: permite definir se a visibilidade do relato será publica ou privada.

Adicionar comentários a um relato de defeito: permite aos usuários adicionar comentários no relato de defeito.

Monitorar relato de defeito: permite que o usuário receba e-mails notificando sobre qualquer modificação realizada no relato.

Criar relação entre relatos de defeitos cadastrados: permite criar relação com outros defeitos cadastrados.

Pesquisar relatos de defeitos cadastrados: permite que os relatos sejam listados e possam ser utilizados filtros para pesquisar relatos de defeito.

Notificações por e-mail: permite que os usuários possam receber notificações por e-mail sobre modificações no relato.

Fluxo de trabalho para resolução de um caso de defeito (Workflow): permite que sejam definidos o estado e atribuição do defeito a um usuário para resolução.

Histórico de mudanças efetuadas no relato: apresenta os registros de todas as operações feitas por cada usuário no sistema.

Criação de campos personalizados: permite que seja criado um novo campo do tipo: string, integer, double, date, currency, e o label que será apresentado para o campo.

83 3.4.6.2 Avaliação de usabilidade

Logo na página inicial, como foi mostrado na Figura 55, é possível identificar a ausência de boas práticas de usabilidade. O menu superior, onde encontram-se as opções, possui fonte pequena, na cor cinza claro sobre fundo preto. Dependendo do ajuste de brilho/contraste da tela, isso dificulta a legibilidade das opções. A ferramenta apresenta a relação de todos os projetos cadastrados, porém, na página inicial, não há como ordenar por ordem alfabética, data de criação/atualização.

Em relação a anexar arquivos, a ferramenta possui a mesma limitação que outras avaliadas, permite apenas um arquivo por vez, como pode ser visto na Figura 56.

Figura 56. BugNET: permite anexar apenas um arquivo por vez no relato de defeito.

Em comparação com as outras ferramentas, a BugNET sem dúvidas apresenta interface mais atual e passa a impressão de ferramenta mais moderna que as outras avaliadas até aqui. De modo geral, foram encontradas boas práticas de usabilidade em todas as telas visitadas. Certamente fornecerá boas ideias para a implementação da ferramenta proposta por este trabalho.

84 4 A FERRAMENTA TESTICIDA

Este capítulo apresenta o trabalho implementado. O nome dado à ferramenta foi Testicida. Serão apresentadas as linguagens de programação a serem utilizadas, o levantamento de requisitos, a modelagem do sistema e a avaliação a ser aplicada para testar e avaliar a execução do trabalho e o desenvolvimento das etapas referentes ao TCC I.

4.1 LINGUAGENS DE PROGRAMAÇÃO

Serão adotadas para a implementação deste trabalho, as linguagens de programação PHP e MySQL.

PHP e MySQL estão disponíveis sem nenhum custo, sob licença de código-fonte aberto, permitindo assim que sejam feitas as alterações e melhorias necessárias.

São linguagens de fácil aprendizagem e utilização. A sintaxe do PHP é baseada em outras linguagens de programação, principalmente e . Portanto, para desenvolvedores que conhecem estas e outras linguagens como C++ e Java, provavelmente não haverá dificuldades em aprendê-la.

Um código PHP escrito de forma correta, conforme especificado em seu manual oficial, normalmente funcionará, sem ser necessário alterá-lo, em sistemas operacionais do tipo gratuitos como o e o FreeBSD, versões comerciais do Unix como Solaris e IRIX, ou em versões diferentes do . O MySQL também pode ser utilizado em diferentes sistemas operacionais baseados em Unix e Windows.

A versão 5 do PHP possui, de forma mais completa que nas versões 3 e 4, recursos e sintaxes orientados a objetos, tais como herança, atributos e métodos privados e protegidos, classes e métodos abstratos, interfaces, construtores e destrutores. O PHP tem conexões nativas disponíveis para muitos sistemas de banco de dados. Além do MySQL, é possível conectar-se diretamente a bancos de dados PostgreSQL, mSQL, Oracle, dbm, FilePro, HyperWave, Informix, InterBase e SyBase, entre outros. Como o PHP é projetado para utilização na WEB, ele tem muitas funções integradas para realizar tarefas úteis, tais como, gerar imagens GIF instantâneas, conectar-se a outros serviços de rede, enviar e-mail, trabalhar com cookies e gerar documentos PDF.

Os sites oficiais das linguagens PHP e MySQL disponibilizam uma vasta documentação para uso de seus recursos. Além disso, é fácil encontrar mais informações e exemplos de uso em inúmeros livros, sites, blogs e fóruns na internet.

85 4.2 ANÁLISE DE REQUISITOS

A Tabela 6 apresenta o comparativo dos requisitos identificados e avaliados nas três ferramentas de gestão de defeitos e nas três ferramentas de gestão de testes. A sigla AT significa atende totalmente, AP atende parcialmente e NA não atende. A coluna “Testicida” representa a ferramenta desenvolvida com a indicação dos requisitos já implementados (AT), os que ainda estão em desenvolvimento (ED) e os que não serão implementados (NA) nessa primeira versão da ferramenta.

Tabela 4. Avaliação de requisitos das ferramentas avaliadas. Testia Requisitos TestLink Testopia Bugzilla Mantis BugNET Testicida Tarântula Cadastrar usuário AT AT NA AT AT AT AT Definir a disponibilidade de um usuário AT NA NA AT AT AT AT Definir o perfil de acesso do usuário AT AP NA AT AT AT AT Armazenar operações realizadas por usuário. AT NA NA AT AT AT AT Exportar os usuários cadastrados para um arquivo AT NA NA NA NA NA ED formato .xml Cadastrar projeto de teste AT AT NA NA NA NA AT Definir os papéis dos usuários no projeto de teste AT AT NA NA NA NA AT Definir a disponibilidade de um projeto de teste AT NA NA NA NA NA AT Definir a visibilidade de um projeto de teste AT NA NA NA NA NA AT Clonar projeto de teste AT NA NA NA NA NA ED Cadastrar plano de teste AT AT AT NA NA NA AT Definir os papéis dos usuários no plano de teste AT NA AT NA NA NA AT Definir a disponibilidade de um plano de teste AT NA AT NA NA NA AT Definir a visibilidade de um plano de teste AT NA AT NA NA NA AT Clonar plano de teste AT NA AT NA NA NA ED Cadastrar build/versão AT NA AT AT NA AT AT Definir a disponibilidade de um build/versão AT NA AT AT NA AT AT Cadastrar marco AT NA AT AT NA AT AT Cadastrar suíte de teste AT AT NA NA NA NA ED Cadastrar caso de teste AT AT AT NA NA NA AT Atribuir suíte de teste a um plano de teste AT AT NA NA NA NA ED Atribuir caso de teste a um plano de teste AT AT AT NA NA NA AT Atribuir suíte e caso de teste a usuários para AT AT AP NA NA NA AT execução Permitir que o usuário insira o resultado do caso de AT AT AT NA NA NA AT teste como passou, falhou ou bloqueado. Associar, no caso de teste, um link para o relato de AT AT NA NA NA NA AT defeito Importar / exportar suítes de teste AT NA NA NA NA NA ED Importar / exportar casos de teste AT NA AT NA NA NA ED Mover / copiar casos de teste e suítes de teste AT AP AP NA NA NA ED Visualizar histórico de testes executados. AT AT AT NA NA NA AT Relacionar caso de teste com caso de teste AT NA AP NA NA NA AT Cadastrar requisitos AT AT NA NA NA NA AT Relacionar requisito com caso de teste AT AT NA NA NA NA AT

86 Relacionar requisito com requisito AT NA NA NA NA NA AT Relatórios AT AT AT AT AT AT AT Integração com Bug Trackers AP AP AP NA NA NA NA Integração com Selenium AP NA NA NA NA NA NA Cadastrar projetos para relato de defeitos e sugestões NA NA NA AT AT AT AT Cadastrar subprojeto e associar a um projeto de NA NA NA AT AT AT ED defeitos existente. Definir projetos de defeitos ativo ou inativo NA NA NA AT AT AT AT Definir projetos de defeitos privado ou público NA NA NA AT AT AT AT Cadastrar relato de defeito NA NA NA AT AT AT AT Clonar um relato de defeito NA NA NA AT AT NA ED Monitorar relato de defeito NA NA NA AT AT AT ED Criar relação entre relatos de defeitos cadastrados NA NA NA NA AT AT AT Alternar formulário de relato de defeito entre básico NA NA NA AT NA NA NA e avançado Anexar arquivos a um relato de defeito NA NA NA AP AP AP AT Pesquisar relatos de defeitos cadastrados NA NA NA AT AT AT AT Adicionar comentários a um relato de defeito NA NA NA AT AT AT AT Notificações por e-mail AP NA NA AT AT AT AT Fluxo de trabalho para resolução de um caso de NA NA NA AT AT AT AT defeito (Workflow) Histórico de mudanças efetuadas no relato NA NA NA AP AT AT AT Suporte a autenticação através do protocolo LDAP AT NA NA AT AT AT NA Criação de campos personalizados AT NA NA AT AT AT NA Validações de preenchimento dos campos AP AP AP AP AP AP AT Interface responsiva NA NA NA NA NA NA AT Apresenta versão AT AP AP AT AP AT AT Suporte à multiplos idiomas AT NA AT AT AT NA NA Ajuda e Documentação AT AP AP AT AP AT ED

A avaliação das ferramentas encontradas, em especial as apresentadas na Tabela 6, que foram avaliadas mais detalhadamente, reforçaram os dois problemas que motivaram a realização deste trabalho: não oferecem a integração de requisitos, gestão dos testes e gestão dos defeitos em uma mesma ferramenta; e a ausência de boas práticas de usabilidade é evidente. Percebeu-se também que o fato de usar duas ferramentas diferentes agrava o problema da usabilidade porque, por exemplo, os projetos, usuários, permissões precisam ser cadastrados nas duas ferramentas. As interfaces, operações, requisitos e regras de negócio das ferramentas são diferentes. Algumas ferramentas de gestão de testes oferecem integração com ferramentas de gestão de defeitos, mas talvez o termo integração esteja empregado de forma equivocada, de tão simples que é, não elimina a necessidade das duplicidades de cadastros citados, o que eleva a probabilidade de inconsistência entre os dados.

A seguir serão apresentados os requisitos funcionais, não funcionais e as regras de negócio. Nesta seção, o termo “cadastrar” compreende as operações de inclusão, edição, exclusão e consulta.

87 Regras de negócio genéricas:

 O formato padrão para uma data é dd/mm/aaaa.

 Qualquer atributo de data deve ser verificado em relação ao calendário.

 Qualquer atributo de e-mail deve ser verificado se é válido.

 A data dos cadastros deve ser gerada pela própria ferramenta e não deve ser editável.

 O tamanho máximo permitido para anexos, por padrão, é de 10MB.

 O atributo disponibilidade pode assumir os valores ativo ou inativo. Qualquer entidade só poderá ser desativada se estiver com o estado ativo e só poderá ser ativada se estiver com o estado inativo. O valor padrão será ativo.

 O atributo visibilidade pode assumir os valores público ou privado. O valor padrão será público.

Requisitos não funcionais:

 As senhas devem ser criptografadas com o algoritmo sha1.

 A interface da ferramenta deve ser responsiva de forma que seja visualizada corretamente em desktops, notebooks, tablets e smartphones.

 O preenchimento dos campos deve ser validado em tempo real com a utilização da linguagem JavaScript.

 O sistema deve ter suporte à autenticação de usuários através de uma consulta a um servidor LDAP, além da autenticação na base de dados local.

Módulo Usuários

Requisito: o sistema deve permitir que um Administrador possa cadastrar usuários.

Regras de negócio:

 Um usuário deve ter as seguintes informações: nome real (string > 1 e <= 64, obrigatório), nome de usuário (string > 1 e <= 32, obrigatório, único), senha (string >= 4 e <= 32, obrigatório), e-mail (string >= 5 e <= 64, obrigatório), perfil de acesso (obrigatório), disponibilidade (obrigatório).

88  Com relação aos perfis de acesso, serão apresentados os cadastrados na tela Perfis de Acesso.

 As opções de consulta devem ser por: nome real, nome de usuário, e-mail, perfil de acesso e disponibilidade.

 A exclusão de um usuário só deve ser permitida quando este usuário não tiver outras informações relacionadas com ele.

Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade de um usuário.

Requisito: o sistema deve permitir que um Administrador possa exportar os usuários cadastrados para um arquivo e importar a partir do arquivo.

Regras de negócio:

 O arquivo deve ser gerado no formato XML

Requisito: o sistema deve armazenar os registros das operações realizadas por cada usuário no sistema.

Regras de negócio:

 para cada operação devem ser armazenadas as informações: data e hora, usuário, entidade, operação realizada, detalhe da operação realizada.

Módulo Projetos

Requisito: o sistema deve permitir que um Administrador possa cadastrar projetos.

Regras de negócio:

 Um projeto deve ter as seguintes informações: nome (string > 1 e <= 64, obrigatório, único), descrição (string <= 2000), disponibilidade (obrigatório) e visibilidade (obrigatório).

 Um projeto dispõe de três módulos: requisitos, testes e defeitos. Deve ser possível definir a disponibilidade e visibilidade de cada módulo, de forma independente.

 As opções de consulta devem ser por: nome, descrição, disponibilidade e visibilidade.

89  A exclusão de um projeto só deve ser permitida quando este projeto não tiver outras informações relacionadas com ele.

Requisito: o sistema deve permitir que um Administrador possa cadastrar subprojetos em um projeto.

Regras de negócio:

 Não é obrigatório que um subprojeto seja cadastrado para um projeto e não há limite de quantidade de subprojetos por projeto.

 As informações que um subprojeto deve ter são as mesmas de um projeto. Adicionalmente, deverá ter um campo em que possa ser criada a relação com o projeto ao qual pertence.

Requisito: o sistema deve permitir que um Administrador possa atribuir papéis dos usuários no projeto.

Regras de negócio:

 o sistema deve permitir que um Administrador possa definir os papéis dos usuários para cada projeto e subprojeto, de forma independente.

Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade de um projeto e subprojeto.

Requisito: o sistema deve permitir que um Administrador possa definir a visibilidade de um projeto e subprojeto.

Requisito: o sistema deve permitir que um Administrador possa clonar projetos.

Regras de negócio:

 Deverá ser apresentado o formulário preenchido com os dados do projeto de origem, exceto o campo nome, que deverá ser preenchido para que o projeto clonado possa ser salvo.

 Casos de teste executados, relatos de defeito e relatórios não serão clonados.

Requisito: o sistema deve permitir que um Administrador possa cadastrar versões de software (builds) para o projeto.

Regras de negócio:

90  Uma versão de software deve ter as seguintes informações: nome(string > 1 e <= 64, obrigatório, único), descrição(string <= 2000), disponibilidade(obrigatório), data(obrigatório).

Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade de uma versão de software.

Módulo Requisitos

Requisito: o sistema deve permitir que um Administrador possa cadastrar requisitos.

Regras de negócio:

 Um requisito deve ter as seguintes informações: identificador (string > 1 e <= 32, obrigatório), título (string > 1 e <= 128, obrigatório), descrição (string <= 2000), estado (obrigatório) e tipo (obrigatório).

 O estado de um requisito pode ser: esboço, revisão, retrabalho, finalizado, implementado, válido, não testável e obsoleto.

 O tipo de um requisito pode ser: informacional, característica, caso de uso, interface, não funcional, função do sistema.

 Após a inclusão de um novo requisito, este será definido como versão 1.

Requisito: o sistema deve permitir que um Administrador possa anexar arquivos a um requisito.

Requisito: o sistema deve permitir que um Administrador possa criar um caso de teste automaticamente a partir de um requisito.

Regras de negócio:

 Após criar, o caso de teste será automaticamente relacionado ao requisito.

Requisito: o sistema deve permitir que um Administrador possa criar uma nova versão de um requisito.

Requisito: o sistema deve permitir que um Administrador possa criar uma relação de um requisito com um caso de teste.

Requisito: o sistema deve permitir que um Administrador possa criar uma relação entre requisitos.

91 Regras de negócio:

 os requisitos podem ter a seguinte relação: é pai de, é filho de, bloqueia, depende de, é relacionado a.

Módulo Plano de Teste

Requisito: o sistema deve permitir que um Administrador possa cadastrar um plano de teste.

Regras de negócio:

 um plano de teste deve ter as seguintes informações: nome (string > 1 e <= 128, obrigatório), descrição (string <= 128), disponibilidade (obrigatório), visibilidade (obrigatório).

Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade um plano de teste.

Requisito: o sistema deve permitir que um Administrador possa definir a visibilidade de um plano de teste.

Requisito: o sistema deve permitir que um Administrador possa clonar um plano de teste.

Requisito: o sistema deve permitir que um Administrador possa cadastrar um marco para o plano de teste.

Requisito: o sistema deve permitir que um Administrador possa ativar ou desativar um marco para o plano de teste.

Módulo Caso de Teste

Requisito: o sistema deve permitir que um Administrador possa cadastrar uma suíte de teste.

Requisito: o sistema deve permitir que um Administrador possa exportar uma suíte de teste para um arquivo e importar a partir de um arquivo.

Regras de negócio:

 O arquivo deve ser gerado no formato XML.

Requisito: o sistema deve permitir que um Administrador possa cadastrar um caso de teste.

Regras de negócio:

 um caso de teste deve ter as seguintes informações: título (), objetivo (), pré- condições (), estado (), prioridade (), tempo de execução estimada ().

92  um caso de teste pode possuir um ou mais passos para execução. Cada um desses passos deve ter as seguintes informações: número do passo (string ), ações do passo (), resultado esperado ().

Requisito: o sistema deve permitir que um Administrador possa exportar um caso de teste para um arquivo e importar a partir de um arquivo.

Regras de negócio:

 O arquivo deve ser gerado no formato XML.

Requisito: o sistema deve permitir que um Administrador possa criar uma relação entre casos de teste.

Regras de negócio: os casos de teste podem ter a seguinte relação: é pai de, é filho de, bloqueia, depende de, é relacionado a.

Requisito: o sistema deve permitir que um Administrador possa atribuir um caso de teste ou uma suíte de testes à um plano de teste.

Requisito: o sistema deve permitir que um Administrador possa atribuir um caso de teste ou uma suíte de testes à um usuário para execução.

Regras de negócio:  ao atribuir o caso de teste a um usuário, o sistema deve automaticamente definir o estado como não executado.

Requisito: o sistema deve permitir que um Testador visualize os casos de teste atribuídos a ele para execução.

Regras de negócio:

 o sistema deve apresentar o estado de cada caso de teste com seus estados e permitir que o testador possa filtrar por estes estados.

Requisito: o sistema deve permitir que um Testador possa definir um resultado para a execução de um caso de teste.

Regras de negócio:

 Os resultados são: passou, falhou ou bloqueado.

Requisito: o sistema deve permitir que um Testador possa relatar um defeito a partir de um link localizado em qualquer um dos passos de execução do caso de teste.

93 Regras de negócio:

 ao clicar no link deve ser apresentada a tela de relato de defeito com as seguintes informações preenchidas: componente, build, etapa. O campo descrição deve conter o texto “Defeito encontrado durante execução do caso de teste , no passo ”. Apesar de preenchidos automaticamente, o usuário poderá editar qualquer um desses campos. Após o envio do relato, deverá ser associado no caso de teste um link para o relato com o número e título.

Módulo Defeitos

Requisito: o sistema deve permitir que um Testador possa cadastrar um relato de defeito.

Regras de negócio:

 Um relato de defeito deve ter as seguintes informações: componente (), build (), etapa (), frequência (), gravidade (), prioridade (), atribuir à (), visibilidade (), título (), descrição ().

 Após a inclusão de um novo relato, este será definido com o estado Novo.

 O sistema deve enviar, automaticamente, uma notificação via e-mail para o usuário cujo relato foi atribuído.

Requisitos: o sistema deve permitir que um Testador possa anexar arquivo a um relato de defeito.

Requisito: o sistema deve permitir que sejam atribuídos estados que indiquem a etapa da resolução de um relato de defeito (workflow).

Regras de negócio:

 os estados podem ser: novo, admitido, confirmado, resolvido, pronto para teste, fechado.

 O sistema deve enviar, automaticamente, uma notificação via e-mail sobre a atualização do relato para os usuários envolvidos, exceto para o usuário que efetuou a modificação.

Requisito: o sistema deve permitir que um Administrador possa clonar um relato de defeito.

94 Requisito: o sistema deve permitir que um Administrador possa cadastrar comentários em um relato de defeito.

Regras de negócio:

 os comentários não poderão ser inseridos quando o relato estiver com o estado fechado.

Requisito: o sistema deve permitir que um usuário possa monitorar um relato de defeito.

Regras de negócio:

 O sistema deve enviar, automaticamente, notificações via e-mail para o usuário sobre qualquer atualização efetuada no relato de defeito.

Requisito: o sistema deve permitir que um Administrador possa criar uma relação entre relatos de defeito.

Regras de negócio:

 os relatos de defeito podem ter a seguinte relação: é pai de, é filho de, é duplicado de, possui duplicado, está relacionado a.

Requisito: o sistema deve permitir que os usuários visualizem o histórico de atualização do relato de defeito.

Regras de negócio:

 o histórico deve apresentar as seguintes informações: data e hora, nome de usuário, campo alterado e detalhe da alteração.

Módulo Relatórios

Requisito: o sistema deve gerar relatórios da execução dos planos de teste, casos de teste e defeitos de um projeto.

4.3 MODELAGEM DO SISTEMA

4.3.1 Modelagem da Interface de Usuário

A seguir serão apresentadas amostras da modelagem da interface de usuário a ser desenvolvida (Figuras 57 à 60). As demais telas modeladas podem ser encontradas no Apêndice A.

95

Figura 57. Ferramenta proposta: tela de pesquisa de projetos cadastrados.

96

Figura 58. Ferramenta proposta: tela de execução dos casos de teste.

97

Figura 59. Ferramenta proposta: tela de cadastro de relato de defeito.

98

Figura 60. Ferramenta proposta: tela de visualização de relato de defeito.

4.3.2 Modelagem Entidade Relacionamento

A seguir será apresentada a modelagem de Entidade Relacionamento do banco de dados (Figuras 61 à 66).

99

Figura 61. Camada Usuário da modelagem de Entidade Relacionamento do sistema.

100

Figura 62. Camada Projeto da modelagem de Entidade Relacionamento do sistema.

101

Figura 63. Camada Requisito da modelagem de Entidade Relacionamento do sistema.

102

Figura 64. Camada Teste da modelagem de Entidade Relacionamento do sistema.

103

Figura 65. Camada Defeito da modelagem de Entidade Relacionamento do sistema.

104

Figura 66. Camada Comum da modelagem de Entidade Relacionamento do sistema.

4.4 IMPLEMENTAÇÃO

A modelagem e desenvolvimento da ferramenta Testicida recebeu uma atenção especial em relação ao banco de dados e a interface de usuário com o intuito de oferecer uma ferramenta realmente integrada e com boa usabilidade. Pensando nisso, ao implementar a interface, percebeu-se que o menu ficaria melhor se posicionado no topo, ao contrário do que foi modelado e apresentado na seção 4.3.1 Modelagem da Interface de Usuário. Dessa forma, o espaço para conteúdo pode ser melhor aproveitado. Por exemplo, mais colunas podem ser mostradas em uma tabela de pesquisa de registros.

Começando pelo banco de dados, o módulo principal é o projeto. É a base para os módulos requisitos, testes e defeitos. Desta forma, o módulo projeto concentra e compartilha as mesmas informações pertencentes a ele como, por exemplo, versões de software, categorias, papéis dos usuários com os outros três módulos. Isso garante a consistência nas informações e poupa tempo.

A preocupação com a modelagem do banco de dados pode ser notada na interface de usuário. A ferramenta oferece flexibilidade na criação de um projeto ao permitir a escolha dos módulos que serão habilitados. Claro que a proposta da ferramenta de unir requisitos, testes e defeitos é de oferecer uma solução integrada e com boa usabilidade e com isso estimular o aumento da efetividade das empresas no que tange o processo e documentação dos testes, porém essa configuração personalizada atenderá também aos usuários que necessitam somente do módulo requisitos ou testes ou defeitos. Podem existir situações temporárias tal qual uma empresa que já utiliza um software de gestão de defeitos e pretende fazer a transição para a Testicida em um período de tempo planejado. Neste cenário

105 hipotético, a ferramenta Testicida poderá servir inicialmente para a gestão dos casos de teste e ter seu módulo defeitos habilitado posteriormente até que os colaboradores estejam treinados, familiarizados e aptos a utilizarem apenas a ferramenta Testicida.

O módulo Requisitos, nesta primeira versão da ferramenta, oferece a possibilidade de cadastrar requisitos apenas com as informações título, descrição, tipo, estado e anexos. Contudo, tais informações, se descritas de forma adequada, podem servir para orientar a equipe de testes a criarem bons casos de teste. Além do mais, foi observado que as ferramentas avaliadas não ofereciam muito mais do que isso. Na visualização do requisito é possível visualizar os casos de teste relacionados. Se o usuário desejar visualizar o caso de teste, basta clicar sobre o registro desejado. Se desejar criar (requer permissão), há um botão “Criar” que levará o usuário até o formulário de cadastro de caso de teste. A Figura 67 apresenta a visualização de um requisito cadastrado.

Figura 67. Visualização de um requisito cadastrado.

O módulo Testes permite a criação dos casos de teste e planos de teste. No formulário de cadastro de um caso de teste, há uma combobox que lista os requisitos existentes para que se possa

106 relaciona-los. Caso o usuário tenha acessado o cadastro de caso de teste através do atalho localizado no requisito, este campo será automaticamente preenchido com o requisito que estava sendo visualizado. As demais informações do caso de teste são o título, descrição, tempo de execução estimado, pré- condições, passos (ações e resultados esperados), pós-condições e anexo. Assim como no formulário de cadastro de requisito, junto ao botão “Enviar”, há uma opção que pode ser marcada para realizar cadastros em sequência, como pode ser visto na Figura 68.

Figura 68. Formulário de cadastro de caso de teste e a relação com requisito.

Após os casos de teste serem cadastrados, o plano de teste pode então ser criado. O formulário contém campos como nome, descrição, anexo e quais casos de teste farão parte do plano e quem serão os usuários que irão executá-los. A Figura 69 mostra um exemplo de cadastro no qual os casos de teste serão atribuídos para dois testadores executarem. A prioridade de execução também pode ser definida individualmente.

107

Figura 69. Cadastro de plano de teste e definição de execução dos casos de teste.

Ao testador que acessar o plano de teste, serão exibidos os casos de teste que estiverem atribuídos para si. Por padrão, os casos de teste apresentarão o estado “Não executado”. Quando clicar em um dos casos de teste, logo abaixo serão exibidas suas informações, principalmente os passos e resultados esperados. Se o caso de teste foi executado com sucesso, o testador poderá clicar no botão “Passou”. O caso de teste será marcado como executado e apresentará estado “passou”. Se o testador encontrou um defeito durante a execução do caso de teste, então pressionará “Defeito”. Ao fazer isto, logo abaixo do caso de teste, será apresentado o formulário para registrar o defeito encontrado, como mostra a Figura 70. O testador preencherá informações sobre o defeito e, após o envio, continuará na mesma tela de execução dos casos de teste.

108

Figura 70. Criação de defeito através da tela de execução de caso de teste.

O caso de teste em que o defeito foi encontrado irá apresentar o estado “defeito” e também a relação com o defeito cadastrado, como mostra a Figura 71. Caso o usuário queira mais informações, basta clicar sobre o link disponível.

Figura 71. Defeito registrado associado ao caso de teste executado.

109 Caso o usuário clique no link, será direcionado para a visualização do defeito, que faz parte do módulo Defeito, como mostra a Figura 72. Além das informações do registro do defeito, a ferramenta apresenta as relações com o caso de teste que originou o defeito e o requisito que originou o caso de teste. Com isso, o desenvolvedor que for designado para resolver o defeito poderá acessar o caso de teste e o requisito, caso tenha dúvidas sobre a coerência do relato de defeito.

Figura 72. Visualização do defeito e as relações com o caso de teste e o requisito.

No módulo Relatório, está disponível, por enquanto, um tipo de geração de relatório. O relatório “Visão Geral do Plano de Teste” exibe o estado atual da execução do plano de teste. Neste relatório é possível visualizar os papéis no plano de teste, o total de casos de teste e a quantidade para cada estado “Passou”, “Defeito”, “Bloqueado” e “Não executado”. O gráfico de barras empilhadas apresenta as mesmas informações, mas de forma diferenciada com o objetivo de facilitar a leitura sobre o andamento da tarefa. Se há defeitos, exibe as quantidades por severidade e por categorias do projeto. Um exemplo deste relatório pode ser visto na Figura 73.

110

Figura 73. Visualização do relatório Visão Geral do Plano de Teste.

Outra vantagem está na possibilidade de geração de relatórios mais claros e completos, pois poderá relacionar as informações de todos os módulos. Além disso, poderá oferecer relatórios extras como, por exemplo, defeitos sem casos de teste relacionados. Relatórios como esse poderão auxiliar a equipe a tomada de decisão quanto a necessidade de cadastrar um novo caso de teste para este defeito encontrado com a intenção de detectá-lo em um próximo plano de testes a ser executado. Outros exemplos de relatórios podem ser casos de teste que mais geram defeitos e os que menos geram ou nada geram. Isso pode apontar casos de teste que precisam ser revisados e melhorados, caso seja necessário.

A ferramenta está disponível para avaliação no endereço abaixo. Para acessar, utilize usuário/senha demo/demo12 ( http://188.93.231.189/~nsoftwar/testicida/view/login.).

111 5 AVALIAÇÃO DA FERRAMENTA TESTICIDA

Esta seção apresenta três métodos de avaliação aplicados após a ferramenta ter sido implementada. A primeira avaliação faz um comparativo de funcionalidades entre esta ferramenta com as ferramentas avaliadas por este trabalho. A segunda teve foco na avaliação de usabilidade da ferramenta. A terceira avaliação foi feita por usuários que trabalham em uma empresa desenvolvedora de software e atuam de forma direta ou indireta no processo de testes.

5.1 AVALIAÇÃO DOS REQUISITOS FUNCIONAIS

O objetivo desta avaliação foi de comparar os requisitos implementados na Testicida com os das ferramentas avaliadas por este trabalho. Dos requisitos apresentadas na Tabela 6 da seção 4.2, a maioria das funcionalidades já estão implementadas. As que estão em desenvolvimento são: importar/exportar, copiar e mover entidades como usuário, projeto, requisito, caso de teste, plano de teste e defeito. São consideradas funções úteis, porém funções extras, cuja falta delas não impediu a realização de avaliações com os usuários.

Por não haver tempo hábil, nesse período destinado à realização do trabalho, para pesquisa e desenvolvimento de todos os requisitos da Tabela 6, decidiu-se por não implementar funcionalidades que demandariam maior esforço, com pesquisa mais aprofundada para definição dos requisitos e implementação mais complexa. São estes, a criação de campos personalizados, autenticação de usuários em base de dados usando o protocolo LDAP, internacionalização das informações da interface de usuário, integração com ferramentas de controle de versão e ferramentas de automatização de testes. Porém, a ausência destas funcionalidades não tem impacto na integração de requisitos, gestão de testes e gestão de defeitos que é o objetivo proposto para este trabalho. Entretanto, estas funcionalidades são importantes e, preferencialmente, devem ser implementadas na sequência para que a ferramenta possa atender as necessidades do maior número possível de usuários interessados.

5.2 AVALIAÇÃO DE USABILIDADE

A avaliação de usabilidade aplicada nas ferramentas avaliadas neste trabalho foram realizadas utilizando-se as 10 heurísticas de Nielsen (1993) e boas práticas citadas por Krug (2006). Portanto, não poderia ser diferente, a Testicida também foi avaliada com os mesmos critérios.

Para Krug (2006), a primeira lei da usabilidade é “Não me faça pensar”. Ou seja, um página WEB deve ser autoexplicativa ao ponto de o usuário ser capaz de entender o seu propósito e como usá- la sem gastar qualquer esforço em pensar nisso. Acredita que a maioria dos usuários de páginas WEB

112 não leem seu conteúdo e sim as exploram visualmente. Portanto, o ideal é criar uma hierarquia visual clara em cada página tirando vantagem das convenções já construídas ao longo da história da Web. A heurística número 6 de Nielsen (1993), diz que o projeto deve dar ênfase no reconhecimento e preterir que o usuário tenha que relembrar aspectos relativos à interação. A heurística número 8 deste mesmo autor fala sobre estética e projeto minimalistas em que os diálogos não devem conter informação irrelevante ou raramente necessária. Outra heurística, número 2, prevê que o sistema deve utilizar a linguagem do usuário, com palavras, frases, conceitos familiares e seguir as convenções do mundo real, fazendo a informação aparecer na ordem lógica e natural. A heurística 4 fala sobre consistência e padrões para que se tenha um conjunto definido de convenções, evitando assim que o usuário tenha que adivinhar se diferentes palavras, situações ou ações têm o mesmo significado. Avaliando sobre estes aspectos, a interface da Testicida apresenta apenas as informações e elementos essenciais, organizados de maneira a facilitar o entendimento visual do usuário. Na barra superior, mais à esquerda, está presente a seleção do projeto. À sua direita encontram-se as opções relacionadas ao projeto selecionado. O primeiro é a Visão Geral, na qual o usuário poderá visualizar uma página indicando sua relação com tarefas atribuídas para si, ou que esteja envolvido, em cada um dos módulos habilitados. Ao lado da opção Visão Geral, na ordem, estão os módulos Requisitos, Testes e Defeitos. A sequência segue a lógica de um ciclo de testes de software: os requisitos são necessários para criar os testes que provavelmente encontrarão os defeitos. Por último, o menu Relatório dispõe de opções de relatório que relacionam e apresentam as informações geradas ao longo do processo. Acima deste menu, caso o usuário tenha permissões de administrador, será apresentado o menu Administração contendo as opções para gerenciar Usuários, Projetos e Perfis de Acesso. Ao lado, o menu Notificações apresentará notificações importantes como mudanças no estado ou anotações adicionadas em um defeito que esteja envolvido. Ao lado direito, a identificação do usuário autenticado no sistema. As opções contidas dentro dos menus também possuem linguagem clara, como “Criar Requisito”, “Criar Caso de Teste”, “Pesquisar Defeitos”, “Pesquisar Planos de Teste”. As telas que possuem formulários para cadastro e edição seguem o mesmo padrão visual, componentes e nomenclaturas, assim como as telas de pesquisa que apresentam tabelas padronizadas. A interface apresenta recursos Web atuais, o que possibilitará se adaptar automaticamente à resoluções diferentes de tela, incluindo tablets e até mesmo celulares com maior resolução.

A heurística 9 de Nielsen (1993), diz que as mensagens de erro devem ser expressas em linguagem clara, sem códigos, indicar o problema com precisão e sugerir uma solução construtiva. A Figura 74 mostra uma situação de erro ao tentar excluir uma informação. A mensagem apresenta que o erro ocorreu no banco de dados e fornece instruções ao usuário sobre como proceder para tentar

113 resolver o problema. Na mesma Figura 74, também é possível visualizar outras mensagens que são exibidas ao usuário. Isto cumpre com outra heurística de Nielsen (1993), à de número 1, que fala sobre o sistema sempre manter o usuário informado sobre o que está acontecendo através do fornecimento de feedback apropriado dentro de tempos razoáveis.

Figura 74. Mensagens de feedback fornecidas ao usuário.

A heurística 5 de Nielsen (1993), aborda a prevenção de erros. Fala que é mais importante prevenir um erro de acontecer do que mostrar boas mensagens de erro. Todos os formulários da ferramenta possuem o indicativo de campos obrigatórios (*). Além disso, caso o usuário tente submeter o formulário contendo campos de preenchimento obrigatório, vazios ou preenchidos incorretamente, os campos são imediatamente destacados com uma mensagem informando que os campos requerem correto preenchimento. O campo “E-mail”, por exemplo, só é aceito se o endereço informado estiver no formato válido. O campo “Tempo de execução estimado”, presente no cadastro de caso de teste, possui máscara (--:--), o que permite que sejam inseridos apenas quatro caracteres numéricos. Estes exemplos são apresentados na Figura 75.

Em relação a heurística 3, que trata da “Liberdade e controle do usuário”, neste momento a Testicida não atende, pois, a ferramenta deveria prover ao usuário a possibilidade de reverter uma operação equivocada, como, por exemplo, a exclusão de um registro.

Quanto à heurística 7, que fala sobre “Flexibilidade e eficiência no uso”, considera comandos e atalhos que possam fornecer aos usuários mais experientes maior eficiência no uso. Quanto à este item

114 ficou a dúvida se a ferramenta atende, pois não é possível executar operações por comandos de teclado, mas, por outro lado, a ferramenta permite que um defeito seja registrado durante a execução de um caso de teste, sem o usuário precisar sair da tela em que está, o que torna a atividade mais eficiente e aumenta a produtividade.

A heurística 10, “Ajuda e documentação”, ainda não foi contemplada. Apesar de a interface ter sido concebida para ser intuitiva o suficiente para não precisar de manual para operá-la, ainda sim são necessários recursos de ajuda (tooltips), em pontos específicos, para fornecer informações complementares quando necessário. Falta também o manual técnico descrevendo os requisitos e o procedimento de instalação da ferramenta em ambiente Web.

Figura 75. Validações dos campos realizada em tempo real.

Com base nestas demonstrações, foi possível constatar que a Testicida já cumpre, até este momento, ao menos 7 das 10 heurísticas propostas por Nielsen (1993).

5.3 AVALIAÇÃO COM USUÁRIOS

Esta avaliação foi realizada com o objetivo de obter feedback de usuários. O objetivo foi verificar principalmente os requisitos de usabilidade e suas funcionalidades. A avaliação ocorreu no contexto de uma empresa que atua na área de telecomunicações. Foram selecionados 10 colaboradores

115 que atuam em diferentes atividades do ciclo de vida de desenvolvimento, conforme apresentado na Tabela 7.

Tabela 5. Colaboradores selecionados para avaliar a ferramenta Testicida. Quantidade de Papel/Cargo Experiência colaboradores (anos) 3 Marketing de Produto (MP) 2 (média) 2 Analista e Engenheiro de desenvolvimento (AE) 4 (média) 4 Técnico e Analista de confiabilidade (TA) 3 (média) 1 Gestão de Projetos (GP) 6

A maior parte destes colaboradores já utilizam a ferramenta Mantis há pelo menos três anos para gerenciar os defeitos. Um deles, TA, também utiliza TestLink, e outro, TA, Redmine, mas já trabalhou em outra empresa com TestLink e Bugzilla. Portanto, a avaliação também foi feita com base nos requisitos oferecidos por estas ferramentas. Algumas delas apresentadas na Tabela 3.

A avaliação iniciou com os colaboradores de MP e com os AE. Como responsáveis por propor, discutir e implementar os requisitos de um produto, estes colaboradores cadastraram três novos projetos, com seus respectivos requisitos: central telefônica PABX, roteador Wireless e Terminal Inteligente para PABX. Na sequência, os colaboradores TA (responsáveis pelos testes) cadastraram os casos de teste a partir dos requisitos cadastrados, criaram planos de teste e executaram os casos. Cada caso foi marcado como “Passou” ou “Defeito”. Para aqueles marcados como “Defeito” os usuários cadastraram os relatos de defeito e atribuíram aos responsáveis para correção. Os colaboradores AE acessaram os defeitos atribuídos a eles, alteraram o estado para “Admitido”, incluíram anotações, alteraram estado para “Resolvido” e depois atribuíram ao relator do defeito para validar a correção e fechar o relato de defeito. O colaborador de GP envolveu-se na decisão de etapas como criação dos planos de teste e acompanhamento através de relatórios.

A percepção destes usuários foi avaliada a partir de um questionário previamente definido. O objetivo foi verificar suas expectativas em relação a dois aspectos: conclusão da tarefa desejada e nível de dificuldade encontrado para realiza-la.

Em relação ao primeiro aspecto, todos os participantes conseguiram concluir a tarefa desejada. As considerações sobre o segundo aspecto são apresentadas na Tabela 8.

Tabela 6. Considerações dos participantes em relação ao aspecto facilidade de uso. Item Consideração Entrevistados 1 (+) A inclusão de requisitos foi rápido, sendo simples, objetivo e muito 1 MP, 1 TA

116 bem organizado. 2 (+) A disposição dos campos chamou a atenção pela facilidade que a 1 MP, 1 TA ferramenta poderá agregar no dia-a-dia. 3 (+) Bem intuitivo, e boa organização na sequência das tarefas. 2 TA 4 (+) A interface mais moderna, limpa e de melhor usabilidade facilita para 1 TA que o aprendizado de seu uso seja mais rápido, colaborando para que os profissionais usufruam rapidamente de suas features. 5 (+) Interligando o caso de teste com o defeito ficou muito fácil e ágil de 1 TA realizar e verificar inconsistências no teste. 6 (+) O grande ponto positivo é unir 3 etapas importantes de um projeto em 2 TA um lugar. Tudo fica fácil de ser encontrado e de ser relacionado para fazer algum tipo de consulta e a possibilidade de realizar rastreabilidade bidirecional (requisitos > testes > bugs, bugs > testes > requisitos). 7 (+) O cadastro de defeitos pela ferramenta durante a execução dos testes 1 TA é excelente, pois dá mais agilidade. 8 (-) O ponto negativo é que todas as pessoas envolvidas nestas 3 etapas 1 TA tem que fazer o seu papel na ferramenta, pois todas as informações são interligadas em uma cadeia. Exemplo: se alguém não escrever o requisito já fica complicado para a área de testes escrever os casos de testes. 9 (-) Senti falta apenas de um mini help, para apresentar informações 1 MP adicionais. Sobre o item 8, embora o usuário tenha classificado como negativo, pode ser considerado como positivo do ponto de vista do processo de teste. A proposta da ferramenta é evidenciar a falta de requisito, teste e/ou defeitos e fazer com que as pessoas se cobrem para fazê-los. Inicialmente, a ferramenta não irá impedir que sejam cadastrados casos de teste sem requisitos relacionados, pois a ferramenta pretende oferecer flexibilidade para atender o nível de maturidade atual de cada organização que queira adota-la.

Quanto ao item 9, vale ressaltar que este recurso já está no backlog da ferramenta, mas ainda não estava disponível no momento da avaliação.

As percepções dos usuários reforçam a avaliação de usabilidade realizada na seção 5.2 em que a Testicida demonstrou estar alinhada com as boas práticas de usabilidade. Considerando que foi o primeiro contato dos usuários com a ferramenta e que não receberam treinamento ou explicações detalhadas sobre a interface, percebeu-se que os usuários, em pouco tempo, estavam familiarizados com a interface e a localização dos componentes e conseguiam dar sequência nas atividades sem demora.

117 6 CONCLUSÃO

A proposta de integrar requisitos, gestão dos testes e gestão dos defeitos em uma ferramenta que ofereça boa usabilidade e seja gratuita, tem como objetivo principal ser uma boa opção para estimular o aumento da efetividade das empresas desenvolvedoras de software no que tange o processo e documentação de testes. Apesar de não haver garantias de que isso realmente venha a acontecer com expressividade, todas as etapas pré-estabelecidas nos objetivos específicos foram cumpridas a fim de tornar isso realidade. Cerca de cem ferramentas gratuitas, entre gestão de testes e gestão de defeitos, foram encontradas nas buscas realizadas na Internet. Aplicando os critérios de seleção, identificou-se as seis mais populares, que foram avaliadas mais detalhadamente. Estas avaliações confirmaram a suposição que motivou a realização deste trabalho. Durante as avaliações, aproveitou-se para mapear os requisitos que estas ferramentas possuem e que deveriam ser implementadas na ferramenta Testicida. Com os requisitos essenciais já desenvolvidos, a avaliação da Testicida foi realizada por usuários que atuam em uma equipe desenvolvedora de software. Embora a quantidade de avaliadores tenha sido pequena, cerca de dez, são profissionais que vivenciam o processo de desenvolvimento e testes e, em sua maioria, utilizam ferramentas que foram avaliadas neste trabalho. Os feedbacks obtidos deixaram bastante claro que a ferramenta causou uma boa primeira impressão e tem potencial para atingir o objetivo desejado.

6.1 TRABALHOS FUTUROS

Levando-se em conta que o tempo disponível para o cumprimento deste trabalho pode ser considerado relativamente pequeno perante ao que pretendia-se realizar, foram priorizadas na Testicida as implementações essenciais, com base em requisitos encontrados na maioria das ferramentas avaliadas. Porém, tem-se consciência de que, se a Testicida quer ser a melhor escolha dentre as demais ferramentas existentes, outros requisitos também devem ser contemplados. Por exemplo, a integração com ferramentas de controle de versão, automatização de testes. A criação de campos personalizados pode ser imprescindível para empresas, portanto, deve ser tido como necessário. A internacionalização também deve ser considerada importante para um usuário determinar a escolha de uma ferramenta. Os idiomas Inglês e Espanhol, se acrescentados como opção, certamente atrairão maior número de interessados que queiram adota-la. O módulo requisitos, já implementado na ferramenta, poderá ser evoluído para tornar-se gestão de requisitos. E não podem ser esquecidos os requisitos não-funcionais: desempenho, segurança. Tudo isso precisa ser muito bem testado. Enfim, muitas ideias e funcionalidades devem ser ponderadas e mais pesquisas e avaliações serão necessárias para definir o

118 que mais a ferramenta deverá oferecer antes de ser disponibilizada aos profissionais de testes de software.

119 REFERÊNCIAS BIBLIOGRÁFICAS

BARTIÉ, A. Garantia da Qualidade de Software. 5. ed. Rio de Janeiro: Elsevier, 2002.

BENYON, David. Interação Humano-Computador. 2. ed. São Paulo: Pearson Prentice Hall, 2011

CRAIG, R. D.; JASKIEL, S. P. Systematic Software Testing. Artech House Publishers, Boston, 2002.

CRESPO, Adalberto Nobiato et al. Uma metodologia para teste de Software no Contexto da Melhoria de Processo. Simpósio Brasileiro de Qualidade de Software, p. 271-285, 2004.

FOURNIER, Greg. Essential Software Testing: A Use-Case Approach. Boca Raton: Auerbach Publications, 2009.

GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999.

IEEE Standard 610-1990: IEEE Standard Glossary of Software Engineering Terminology, IEEE Press.

KRUG, Steve. Don't Make Me Think! A Common Sense Approach to Web Usability. 2. ed. Berkeley, CA, 2006.

LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Fundamentos de metodologia científica. São Paulo: Atlas, 1993.

LEWIS, Willian E.; VEERAPILLAI, Gunasekaran. Software Testing and Continuous Quality Improvement. 2. ed. Boca Raton: Auerbach Publications, 2004.

MYERS, Glenford J; BADGETT, Tom; SANDLER, Corey. The Art of Software Testing. Editora John Wiley & Sons, New Jersey, USA, 2011.

NIELSEN, Jakob. Usability Engineering. Editora Academic Press, Boston, 1993.

NIELSEN, Jakob; LORANGER, Hoa. Usabilidade na Web – Projetando Websites com qualidade. Rio de Janeiro: Elsevier, 2007.

NIELSEN, Jakob. Usability 101: Introduction to Usability 2012. Disponível em: < http://www.nngroup.com/articles/usability-101-introduction-to-usability/>. Acesso em: 01 mar. 2015.

PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2. Ed. Rio de Janeiro: Editora LTC, 2003.

PETERS, J. F.; PEDRYCZ, W. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

PREECE, Jennifer; ROGERS, Yvonne; SHARP, Helen. Design de interação – Além da interação homem-computador. Porto Alegre: Bookman, 2005.

120 PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 6th ed, Nova York, NY, 2005.

PRESSMAN, Roger S. Engenharia de software. 6ª ed. Porto Alegre: Bookman, 2006.

PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®). 5. ed. Saraiva, 2014.

RAPOSO, Alberto Barbosa. Introdução a Interação Humano-Computador – Avaliação Heurística. Disponível em: . Acesso em: 11 de Maio 2015.

RAPPS, S.; WEYUKER, E.J. Data Flow analysis techniques for test data selection, In: International Conference on Software Engineering, p. 272-278, Tokio, Sep. 1982.

RILEY, Tim.; GOUCHER, Adam. Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice). Sebastopol, CA: O’Reilly, 2010.

RIOS, Emerson. Documentação de Teste de Software: Dissecando o padrão IEEE 829. 2. ed. Rio de Janeiro: Imagem, 2010.

ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. et al., Qualidade de software – Teoria e prática, Prentice Hall, São Paulo, 2001.

WELLING, Luke; THOMSON, Laura. PHP & MySQL desenvolvimento Web. 3. ed. Rio de Janeiro: Elsevier, 2005.

(Artigo Engenharia de Software – Introdução a Teste de Software. . Acesso em: 31 de Agosto 2014).

(Artigo Engenharia de Software – Does anyone know a good open source tool for test management and bug tracking. . Acesso em: 6 de Março 2015).

121 Apêndice A

122

123

124

125

126

127

128

129

130

131

132