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.

Certificação CBTS

Bom dia pessoal,

Primeiramente agradecer a minha família pelo apoio e paciência, especialmente minha esposa Juliana Lopes e minha filha, aos amigos da homologação e a Aker pelo curso preparatório.

Obtive a Certificação Brasileira de Teste de Software - CBTS da Associação Latino Americana de Teste de Software. 

Valeu

Certificação Brasileira de Teste de Software (CBTS)

A Certificação Brasileira em Teste de Software (CBTS) foi criada pela Associação Latino Americana de Teste de Software (Alast) com o objetivo de estabelecer padrões para avaliar a qualificação dos profissionais que atuam na área de testes de software (ALATS – ASSOCIAÇÃO LATINO AMERICANA DE TESTE DE SOFTWARE, 2010).

Não a pré-requisitos para a realização do exame, que será exigido os seguintes tópicos:

• Introdução ao Processo de Teste;

• Processo de Teste;

• Ambiente de Teste; 

• Análise de Risco;

• PMBOK do PMI;

• Planejamento de Teste;

• Elaboração do Teste;

• Gestão de Defeitos; 

• Teste de Aceitação;

• Relatório de teste;

• Estimativa de teste;

• Tópicos especiais em teste de software.

Os assuntos podem mudar de um exame para outro, recomenda-se fazer download sempre da última versão disponibilizada no site da Alast.

CRIANDO A INFRA-ESTRUTURA PARA OS TESTES - SCRIPTS

Scripts

Os scripts são linguagens de programação interpretada de alto nível, que são executadas dentro de outros programas ou até mesmo outras linguagens de programação, são freqüentemente usadas como ferramentas de configuração e instalação em sistemas operacionais (Shell script), como por exemplo, em alguns sistemas operacionais da família Linux, que usam as linguagens GNU/Shell bash ou sh.

Os scripts mais conhecidos são:

·         Shell scripts;

·         Bash/Linux;

·         Sh/Linux;

·         Bat/Windows;

·         VBScripts/Windows;

·         JavaScripts/Web;

·         Perl/Multi-plataforma;

·         Python/Multi-plataforma.

O uso de scripts nos ambiente de testes é imprescindível, pois facilitam a configuração dos ambientes de testes, em testes repetitivos e de validação (performance e stress), como são fáceis de montar e de se alterar dá ao testador uma grande flexibilidade.

O que é testar?

Bom dia,

Estou estudando para a certificação CBTS, e achei estas definições pertinente, resolvi compartilhar:

• Testar é verificar se o software está fazendo o que deveria fazer, de acordo com os seus requisitos, e não está fazendo o que não deveria fazer (Rios e Moreira – 2002);
• Testar é o processo de executar um programa ou sistema com a intenção de encontrar defeitos (teste negativo) (Glen Myers – 1979);
• Testar é qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema, seja possível determinar se ele alcança os resultados desejados (Bill Hetzel – 1988).