RETORNO DO INVESTIMENTO (ROI)

Conforme Boehm (1976), quanto mais tarde um defeito for identificado mais caro fica para corrigi-lo e mais ainda, os custos de descobrir e corrigir defeitos no software aumentam exponencialmente na proporção que o trabalho evolui através das fases do projeto de desenvolvimento (RIOS e MOREIRA, 2006).

Segundo (RIOS e MOREIRA, 2006):

·         Manutenção contabiliza quase 67% dos custos totais de software;

·         20% do orçamento de manutenção é para corrigir defeitos;

·         25% é gastos para adaptar programas a um novo hardware e software;

·         6% é gasto para corrigir documentações;

·         4% é gasto na resolução de problemas de performance;

·         42% é gasto fazendo mudanças solicitadas pelos usuários.

Com base nestas informações que se justificam todos os investimentos em qualidade, e o retorno não serão possíveis de se mensurar, pois “...a qualidade deixa de ser um diferencial competitivo e passa a ser um item básico de sobrevivência, uma necessidade permanente, na qual uma empresa que forneça bens e/ou serviços com baixa qualidade corre um sério risco de ser descartada pelo mercado consumidor.”

CRIANDO OS TESTES

Neste capítulo são propostos os modelos de documentos para planejar, documentar, tabular o processo de teste.

Abaixo temos a situação do Brasil no que se trata em planejamento de testes, ou seja, criação do Plano de testes, segundo pesquisa do Ministério de Ciência e Tecnologia apenas 37,8 % das empresas tem um planejamento formal dos Testes (MINISTÉRIO DE CIÊNCIA E TECNOLOGIA, 2009).

Plano de teste - Definições

Planejamento de teste é um processo. Plano de teste é o resultado prático desse planejamento, é o seu fruto e artefato (MOLINARI, 2006).

O Plano de teste é o documento que contém o projeto ou o desenho lógico do processo de teste e está alinhado com a estratégia de testes correspondente e nele começam a ser delineados os casos de testes. Este documento define os objetivos gerais e as expectativas do projeto de teste (RIOS e MOREIRA, 2006).

Etapas para criação do documento

Em gera os planos de testes possuem as seguintes etapas:

·         Definição do escopo: define o que se deve testar de forma abrangente, um tipo de objetivo geral;

·         Definição dos requisitos: Com base no projeto ou em outros documentos é definido como o item a ser testado deve funcionar;

·         Casos de testes: é definido os casos de testes que sejam necessários para testar os requerimentos definidos;

·         Definição da estratégia:  definição das técnicas de testes que será utilizadas, como:

·         Tipos de testes: testes de performance, de estresse, volume e etc;

·         Critérios de aceitação: define os requisitos para aprovação do item testado.

·         Definição dos recursos: quem fará o que e o que será utilizado, como:

·         Equipe de teste;

·         Hardware;

·         Softwares;

·         Ferramentas.

·         Cronograma;

Checklists

Com base nas informações obtidas pelos meios pesquisados (observação, pesquisa e bibliografias) é recomendado a utilização de “Checklists”, como uma importante ferramenta para complementar e orientar os testes definidos no plano de testes.

Um exemplo de checklist genérico em planilha eletrônica, para testes de novas partes em um servidor de rede:

·         Pesquisar sobre problemas referentes à utilização deste hardware;

·         Ler o datasheet/manual do hardware;

·         Checar os releases de correções disponibilizados;

·         Teste de performance;

·         Testes de estabilidade:

·         Burning de 72 horas.

Para responder a cada item do checklist, pode se adotar os estados:

·         Conforme: quando o item atendeu completamente os requisitos;

·         Não conforme: quando identificado alguma divergência com relação aos requisitos;

·         Não será realizado: por algum motivo este item não será realizado o teste, por exemplo, pode ocorrer um problema em um item acima que não permite realizar este teste;

·         Testador: profissional responsável pelo teste;

·         Observações gerais: comentário, número do registro de solicitação para correção (bug), etc.

Relatórios

Sempre que são executados testes baseados em um plano de teste é necessário um relatório formal com os resultados obtidos e anexado ao plano de teste.

Em alguns casos os planos de testes são criados para a realização de testes uma única vez, ou rodada, este caso o relatório deve fazer parte do próprio plano de testes, porém alguns planos de testes são realizados diversas vezes, neste caso o relatório de conclusão, é um documento separado e com controle de versão conforme a necessidade da empresa.

Softwares de gestão

Projetos

Neste capítulo apresenta sugestões de ferramentas para melhor gestão dos projetos e tarefas realizadas no desenvolvimento de aplicações e em seus testes.

Redmine 

Redmine é um flexível sistema de gestão de projetos usando recursos Web.  Escrito usando framework “Ruby on Rails”, é multi-plataforma e suporta diversos bancos de dados. Redmine é open source e liberado sob os termos da GNU General Public License v2 (GPL).

Abaixo são algumas das principais características:

• Suporte a vários projetos;

• Controle de acesso baseado em sistema de emissão;

• Acompanhamento gráfico de Gantt e calendário;

• Notícias, documentos e arquivos de Feeds;

• Gestão e notificações por e-mail;

• Wiki e Fóruns por projeto;

• Monitoramento de tempo/prazos;

• Campos personalizados para as questões, tempo entradas, projetos e usuários;

• Integração SCM (SVN, CVS, Git, Mercurial, Bazaar e Darcs);

• Integração com sistemas de arquivos para autenticação (Microsoft Active Directory, LDAP e Novell).

Microsoft Project®

O Microsoft Project é um sistema de gestão de projetos desenvolvido pela Microsoft, tendo atualmente as versões Professional e a Server, vejamos alguns detalhes de cada versão:

Microsoft Project® Professional

Versão para se instalar nas estações de trabalho tem melhorias no Visual Project 2010 fazer uma gestão mais eficiente do que nunca (MICROSOFT CORPORATION, 2011).

Os principais de benefícios são:

• Visual familiar e intuitivo;

• Poupe tempo e esforço;

• Flexível e poderoso;

• Mais fácil de ver e compartilhar;

• Controle e entrega;

• Melhore o desempenho.

• Gestão de Recursos Conectado;

• Integração com Microsoft SharePoint® Server 2010.

Microsoft Project® Server

Versão corporativa voltada para empresas com capacidades inovadoras trazer ganhos de eficiência de gestão de carteira e de projeto para indivíduos, equipes e empresas com o Project 2010 (MICROSOFT CORPORATION, 2011).

Os principais benefícios são:

• Unificação de projetos em única gestão;

• Criada na plataforma  Microsoft SharePoint® Server 2010;

• Projeto de iniciação e desenvolvimento de processo de negócios;

• Seleção do portfólio;

• Editando Projeto Web-Based;

• Fluent User Interface ™;

• Reportagem melhorias Tempo;

• Integração do Exchange Server;

• Relatórios avançados e Business Intelligence;

• Administração Simplificada e interoperabilidade prolongado.

Open Proj

OpenProj é um gerenciador de projetos desenvolvido como alternativa ao Microsoft Project. Com código aberto licenciado CPAL license, oferece várias opções para a inclusão e administração de todas as atividades co-relacionadas ao desenvolvimento das atividades, apresentando os resultados, em especial, sob o formato de Gráficos de Gantt (SERENA SOFTWARE INCORPORATED, 2008).

Com uma interface amigável e repleta de recursos, temos uma tabela é apresentada e você deve atribuir os nomes das ações e tempo de duração das tarefas. Com isto, o programa gera automaticamente as redes, que são pequenas caixas de opções possíveis de serem interligadas, formando-se fluxogramas é possível acompanhar os RBS ou “Risk Breakdown Structure”, fazendo uma gerencia de riscos relacionados ao projeto. A parte de Estrutura Analítica de Projetos (EAP) também pode ser visualizada no programa, bem como você conseguirá emitir relatórios, avaliar histogramas, graficos e etc.

Controle de Bugs (bugtrack)

Bugzilla

Bugzilla iniciado pelo Dave Miller é uma ferramenta baseada em Web e e-mail que dá suporte ao desenvolvimento do projeto Mozilla, rastreando defeitos e servindo também como plataforma para pedidos de recursos. Como projeto de Software Livre, é mantido por voluntários, sendo utilizado por diversos outros projetos e empresas, de código aberto ou proprietário, como a NASA, a NBC e a Wikipédia.

Características:

• A estrutura do banco de dados otimizado para aumentar a performance e escalabilidade;

• Excelente segurança para proteger a confidencialidade;

• Ferramenta de consulta avançada, que pode recordar suas pesquisas e-mail;

• Capacidades de integração;

• Perfis personalizados de usuário e abrangente preferências e-mail;

• Permissões do sistema global.

Benefícios:

• Melhorar a comunicação e aumentar a qualidade do produto;

• Melhorar a satisfação do cliente;

• Garantir a responsabilização;

• Aumentar a produtividade;

• Bugzilla podem se adaptar a várias situações.

Flyspray

Flyspray: The Bug Killer é uma simples ferramenta de bugtracker (registro de bugs, tarefas e chamados), sistema baseado na web escrito em PHP para ajudar com desenvolvimento de software. Foi originalmente concebido quando o Psi Jabber Client não conseguia encontrar um bugtracker que se adequava às suas necessidades, e foi disponibilizada para que todos possam usar para seus próprios projetos.

Flyspray é um software livre, distribuído sob a GNU Lesser General Public Licence versão 2.1. Isto significa basicamente que você pode começar Flyspray e usá-lo gratuitamente. O código fonte está disponível, e você está convidado a modificá-lo para atender às suas necessidades.

As características incluem:

• Baseado na web, independente de plataforma;

• Suporte de banco de dados múltiplos, atualmente MySQL e PGSQL;

• Fácil instalação;

• Fácil de usar;

• Suporta a utilização em vários projetos simultaneamente;

• Alertas de tarefas, com notificação de alterações (e-mail ou Jabber);

• Histórico de tarefas abrangente;

• Anexos de arquivos;

• Avançados recursos de pesquisa;

• Atom / RSS feeds;

• Duas opções de sintaxe para descrição de tarefas (Dokuwiki / texto simples);

• Gráficos de dependência.

Esta disponível uam versão demo para visualização no link http://demo.flyspray.org/

OcoMon

O Ocomon surgiu em Março de 2002 como projeto pessoal do programador Franque Custódio, tendo como características iniciais o cadastro, acompanhamento, controle e consulta de ocorrências de suporte e tendo como primeiro usuário o Centro Universitário La Salle (UNILASALLE). A partir de então, o sistema foi assumido pelo Analista de Suporte Flávio Ribeiro que adotou a ferramenta e desde então a tem aperfeiçoado e implementado diversas características buscando atender a questões de ordem prática, operacional e gerencial de áreas de suporte técnico como Helpdesks e Service Desks. Em Maio de 2003 surgiu a primeira versão do módulo de inventário (Invmon), e a partir daí e todas as informações de atendimentos começaram as estar vinculadas ao respectivo equipamento, acrescentando grande praticidade e valor ao sistema de atendimento. Com a percepção da necessidade crescente de informações mais relacionadas com à questão de qualidade no suporte, no início de 2004 foram adicionadas características de gerenciamento de SLAs, mudando de forma sensível a maneira como o gerenciamento de chamados vinha acontecendo e obtendo crescente melhoria da qualidade final de acordo com os indicadores fixados para os serviços realizados (RIBEIRO, 2011).

Atualmente é possível responder questões como:

• Volume de chamados por período;

• Tempo médio de resposta e solução para os chamados;

• Percentual de chamados atendidos e resolvidos dentro do SLA;

• Tempo dos chamados decomposto em cada status de atendimento;

• Usuários mais ativos;

• Principais problemas;

• Reincidência de chamados por equipamento;

• Estado real do parque de equipamentos;

• Como e onde estão distribuídos os equipamentos;

• Vencimento das garantias dos equipamentos.

Além de uma série outras questões pertinentes à gerência pró-ativa do setor de suporte.

No início de 2005, os dois sistemas: Ocomon e Invmon foram finalmente 100% integrados ganhando um novo layout e permanecendo com o nome único de OCOMON. Tendo então sua utilização baseada em dois módulos principais: 

• Módulo de Ocorrências;

• Módulo de Inventário.

Principais funções do módulo de ocorrências:

• Abertura de chamados de suporte por área de competência;

• Vínculo do chamado com a etiqueta de patrimônio do equipamento;

• Busca rápida de informações referentes ao equipamento (configuração, localização, histórico de chamados, garantia..) no momento da abertura do chamado;

• Envio automático de e-mail para as áreas de competência;

• Acompanhamento do andamento do processo de atendimento das ocorrências;

• Encerramento das ocorrências;

• Controle de horas válidas;

• Definições de níveis de prioridades para os setores da empresa;

• Gerenciamento de tempo de resposta baseado nas definições de prioridades dos setores;

• Gerenciamento de tempo de solução baseado nas definições de categorias de problemas;

• Controle de dependências para o andamento do chamado;

• Base de conhecimento;

• Consultas personalizadas;

• Relatórios gerenciais;

• Controle de SLAs.

Principais funções do módulo de inventário:

• Cadastro detalhado das informações (configuração) de hardware do equipamento;

• Cadastro de informações contábeis do equipamento (valor, centro de custo, localização, reitoria, fornecedor..);

• Cadastro de modelos de configuração para carga rápida de informações de novos equipamentos;

• Cadastro de documentações relacionadas aos equipamentos (manuais, termos de garantia, mídias);

• Controle de garantias dos equipamentos;

• Histórico de mudanças (de localidades) dos equipamentos;

• Controle de licenças de softwares;

• Busca rápida das informações de chamados de suporte para o equipamento;

• Busca rápida de informações dos equipamentos;

• Buscas por histórico de mudanças (localização);

• Consultas personalizadas;

• Estatísticas técnicas e gerenciais do parque de equipamentos;

• Relatórios gerenciais. 

Questões técnicas:

O Ocomon foi concebido sob a visão de software opensource sob o modelo GPL de licenciamento, utilizando tecnologias e ferramentas livres para o seu desenvolvimento e manutenção.

Abaixo listo as principais questões técnicas do sistema:

• Linguagem: PHP versão: a partir da 4.3x até a 5x , HTML, CSS, Javascript;

• Banco de dados: MySQL versão: A partir da 4.1x;

• Autenticação de usuários: a autenticação de usuários pode ser feita tanto na própria base do sistema quanto através de uma base LDAP em algum ponto da rede.

Novas funcionalidades têm sido acrescentadas ao sistema ao longo do tempo e o objetivo é torná-lo cada vez mais aderente às boas práticas relacionadas tanto à operacionalização quanto à gestão de áreas de atendimento técnico.

Fluxogramas de Procedimentos

O uso de fluxogramas para definir o fluxo das informações entre os departamentos são muito utilizados para facilitar o entendimento e a execução das atividades.

Abaixo seguem exemplo de fluxogramas e suas explicações dos mesmos exemplos citados anteriormente, porém agora estão bem mais completos:

Pedido de Homologação:

Figura 19. Exemplo de fluxograma do Pedido de Homologação (elaborada pelo autor).

Procedimentos

Como quaisquer departamentos de uma empresa existem regras a serem seguidas, recomendações e formas de atuar, em resumo tudo isso se encaixa na palavra “procedimentos”.

É recomendado que se defina procedimentos para todas as ações de interação com outros departamentos, ou seja, entrada e saída de informação do departamento de testes, desta forma já terão pontos importantes para a medição de produtividade, controle das atividades, filas e etc.

Com base nas observações realizadas na empresa XYZ, abaixo seguem exemplos de alguns procedimentos de interação com outros departamentos:

• Pedido de Homologação (teste): Solicitação formal via sistema ou não de teste de um software novo, atualizações, service patch e hotfix, geralmente solicitados pelo departamento de desenvolvimento de software.
• Pedido de Avaliação (verificação de funcionalidade): Quando a empresa tem uma estrutura organizacional de suporte em camadas, o departamento de testes pode ser a ligação entre o suporte e o desenvolvimento, quando isso acontece o suporte ao encontrar um “possível” problema abre uma solicitação para que o departamento de testes verifique se não é um mau uso ou erro de configuração, antes de encaminhar o 
• Pedido de Correção ao desenvolvimento. Esta etapa é muito importante para que os testes possam ser reavaliados e aperfeiçoados evitando que estes problemas cheguem aos clientes.
• Pedido de Correção (abertura de bugs): Notificação de problemas no software ao departamento responsável pela sua correção.
• Pedido de publicação: Após o termino de um teste de um pacote, patch ou hotfix é necessário disponibilizá-los aos clientes através dos meios de comunicação adotados pela empresa, normalmente um departamento de marketing faz esta atividade, este pedido marca o termino da atividade do departamento de testes.

Cada empresa adéqua suas atividades operacionais e escrevem seus procedimentos, com base na necessidade, devem ser publicados e seguidos por seus colaboradores. O termo de melhorias contínuas deve ser aplicado o tempo todo nestes procedimentos, pois a sua função é auxiliar na execução das atividades e não atrapalhar.

Diversos outros procedimentos devem ser adotados internamente no departamento de testes, procedimentos estes que já estarão definindo como o testador deve atuar em seus testes. Veremos em detalhes no capítulo Criando Testes.

Dokuwiki

DokuWiki é uma aplicação baseada no modelo Wikipédia escrito em PHP voltado para as necessidades de documentação em pequenas empresas, escrito por Andreas Gohr. Usa para armazenar dados em arquivos de texto, não necessitando de um banco de dados. Possui uma sintaxe simples, porém completa, similar à usada na Wikipédia.

Recursos disponíveis:

• Funciona com arquivos texto como armazenador;
• Simples de se editar com botões que facilitam a sintaxe de escrita;
• Permite se editar apenas parte de uma página;
• Geração automática de tabelas;
• Número de revisões sem limite;
• Suporte a diferenciação de revisões coloridas;
• Suporte a páginas somente leitura;
• Syndication de modificações recentes por RSS Feed;
• Pastas de assuntos;
• Interwiki Links;
• Envio e inserção de imagens;
• Redimensionamento de imagens;
• Suporte multi-idioma;
• Spam blacklist;
• Troca de textos personalizados;
• Trava de edição para evitar conflitos;
• Suporte total a UTF-8.