Redução de custos de manutenção aplicando rotinas de testes

1. RESUMO

O foco do presente trabalho é a implantação de testes em software na empresa Softpar com objetivo de demonstrar a importância dos testes usando uma metodologia aplicada e através da solução proposta obter um melhor controle sobre o software desenvolvido, agregar qualidade e aumentar o nível de satisfação do cliente. Apresentam-se as etapas de implantação de testes no sistema. Planejamento de testes, preparação, especificação e execução. Ao longo do texto, enfatizam-se as atividades realizadas em cada uma dessas etapas, pois cada procedimento é importante na conclusão do processo. Destaca-se a importância dos testes no ciclo de desenvolvimento aprimorando qualidade ao software. Este trabalho monográfico implantou testes em software através de uma metodologia aplicada, utilizando como base o desenvolvimento de roteiros onde os testes são executados passo a passo. Para o desenvolvimento dos planos de testes, roteiros, casos de teste e a execução dos testes, realizou-se a instalação e configuração da ferramenta de gerenciamento de testes testlink. O resultado dos testes executados no ano de 2013 através da metodologia aplicada foi registrado na ferramenta testlink. Onde se observou que foi alcançado um total de 54% de erros na execução dos testes, O que representa que os testes executados através de roteiros apresentaram resultado positivo sendo que o objetivo de encontrar mais erros foi atingido no estudo trimestral. Para afirmar que a proposta desenvolvida neste trabalho monográfico é valida, apresenta-se a comparação entre a quantidade de bugs registrados nos três meses, utilizando metodologia aplicada, e os testes aleatórios, realizados durante 12 meses nos anos de 2010 a 2012. O resultado foi satisfatório, atingiu-se em um período menor de testes, um percentual considerável, a diferença entre os bugs encontrados em 2013, foi somente 8% a menos comparado com o ano de 2012, onde os testes foram executados por 12 meses, o único ano que os testes aleatórios foram superiores a metodologia aplicada. Com isso é possível observar que a metodologia proposta nesse trabalho, foi considerada positiva, sendo a mesma, satisfatória, em todas as comparações efetuadas. O resultado foi extremamente significativo, em relação aos anos comparados, provando assim, que as avaliações, foram eficazes.

Palavras-chave: Testes. Software. Qualidade

ABSTRACT

The focus of this work is the implementation of the software testing company Softpar in order to demonstrate the importance of using a testing methodology and proposed solution by getting a better handle on the software developed, add quality and increase the level of satisfaction customer. Present the deployment steps for testing the system. Test planning, preparation, specification and implementation. Throughout the text, emphasis is the activities performed at each of these steps, because each procedure is important in completing the process. Highlights the importance of testing in the development cycle to improving software quality. This monograph tests implemented in software using a methodology, using as a basis the development of scripts where the tests are performed step by step. For the development of test plans, scripts, test cases and test execution took place the installation and configuration of test management tool TestLink. The result of the tests performed in 2013 using the methodology applied was recorded in TestLink tool. Where it was observed that reached a total of 54% of errors in the execution of tests, What is that tests run through roadmaps were positive with the aim of finding more errors was hit in the quarterly survey. To say that the proposal developed in this monograph is valid, it presents a comparison between the amount of bugs recorded in the three months using the methodology applied, and random testing, conducted over 12 months in the years 2010 to 2012. Satisfactory result was reached in a shorter period of testing, a percentage considerably, the difference between the bugs found in 2013 was only 8% less compared to the year 2012, where the tests were run for 12 months, the only year that were superior to random testing methodology. Thus it can be seen that the proposed methodology in this study was considered positive, being the same, satisfactory in all comparisons made. The result was extremely significant for the years compared, thus proving that the assessments were effective.
Keywords: Tests. Software. Quality.

2. INTRODUÇÃO

O desenvolvimento de software tem passado por grandes mudanças. Com o aumento de novas tecnologias, umas das tecnologias que tem ganhado muito mercado, principalmente no que diz respeito na hora de medirmos qualidade, é o teste de software.

De acordo com Neto (2007), “O objetivo do teste, é identificar erro em um produto, para que as causas sejam identificadas e corrigidas antes de ir para o ambiente de produção”.

A atividade de testes em software se tornou uma etapa fundamental no ciclo de desenvolvimento de sistema, com o grande numero de empresas, desenvolvedoras de software. Elas precisam cada vez mais agregar qualidade, ao produto desenvolvido, para conseguir o espaço neste mercado competitivo.

Segundo Moreira (2003), testar é analisar se o software esta funcionando corretamente, verificar se está validando os requisitos e se o sistema que está sendo desenvolvido conforme a solicitação do cliente.

De acordo com Pressman (2001), qualidade de software, consiste de um conjunto de requisitos de um produto que atenda as necessidades dos clientes. Ou seja, que atinja a expectativa do cliente, que cumpra todos os requisitos solicitados da melhor forma possível.

Segundo Bastos et al (2012) , Durante as décadas de 1970, 1980 e 1990 eram realizados os testes unitários, onde os testes eram executados pelos próprios programadores. Fator que não permitia que muitos defeitos fossem encontrados. Esses defeitos apareciam quando o sistema já estava em ambiente de produção, onde a correção tem seu custo elevado e a credibilidade do sistema fica abalada. Pois o cliente pode acabar substituindo o sistema problemático por um sistema mais funcional.

As empresas buscaram melhorar a qualidade do software, para conseguir aumentar o nível de satisfação do cliente, que cada vez se torna mais critico e exigente.

E necessário citar o próprio beneficio, ao conseguir a redução dos custos de manutenção. Para isso, foi necessário aprimorar a atividade de teste e vincular ao projeto de desenvolvimento. O teste em software tornou-se uma atividade de extrema importância. As empresas viram a necessidade de implantar um setor somente para área de testes. E esses, passaram a ser executados por especialistas, profissionais capacitados para exercer a função, usando metodologias apropriadas.

Segundo Bastos et al (2012, p.31) o objetivo principal do processo de teste é simplesmente encontrar o maior número possível de defeitos no software.

O Desenvolvimento, sem as devidas preocupações com testes, Além de trazer prejuízo com retrabalho, pode causar uma má impressão nos clientes.

A problemática apresentada é a forma que a empresa Softpar, executa os testes em seu sistema, ela não possui método especifico para efetuar testes, e consequentemente não consegue conhecer os resultados reais. A empresa não possui planos de testes, roteiros de testes e por esse motivo surgem retrabalho, aumentando o custo para o desenvolvimento. E o maior dos problemas que seria entregar uma versão do sistema com bug, podendo afetar a credibilidade da empresa.

O objetivo geral deste trabalho é demonstrar a importância dos testes, no processo de desenvolvimento de softwares, com a utilização de uma metodologia de aplicação de testes. Demonstrando a facilidade e os benefícios através de desenvolvimento de roteiros de testes e casos de testes.

A solução proposta é implantar a ferramenta de gerenciamento de testes Testlink, onde os testes podem ser executados através de roteiros, facilitando e auxiliando o desenvolvimento do software e proporcionando a empresa Softpar uma melhor condução na atividade de testar.

O resultado esperado deste Trabalho monográfico é partindo da hipótese que a empresa, não possui um método especifico para efetuar testes, demonstrar através da implantação de uma metodologia aplicada. Com o apoio da ferramenta Testlink, para o gerenciamento dos testes. Que a empresa conseguirá conduzir a atividade de uma maneira mais eficaz, produtiva, e assim, será possível conhecer e identificar os resultados reais conseguindo comparar os resultados anteriores com o depois da implantação de testes, assim podendo focar os testes nos pontos mais críticos do sistema.

2.1. DEFINIÇÃO DO PROBLEMA

Tendo em vista a viabilidade deste projeto para a empresa Softpar, foi detectado o interesse da empresa, através da colaboração em aceitar o desafio permitindo a implantação do projeto. A empresa não possui método específico para efetuar testes, e por este motivo não consegue conhecer os resultados reais. Consequentemente vários problemas são identificados, como por exemplo: tem o custo do desenvolvimento elevado, retrabalho, e a empresa não consegue identificar os pontos críticos, para aplicar os testes adequadamente.

2.2. OBJETIVOS

A finalidade deste trabalho monográfico é aplicar a técnica de caixa preta onde o objetivo é validar a interface do sistema e suas funcionalidades.

2.2.1. Objetivo Geral

Demonstrar através de estudos sobre testes em software a importância da implantação dos testes, com acompanhamento de roteiros e casos de testes, desenvolvidos com apoio da ferramenta Testlink.

2.2.2. Objetivos Específicos

• Planejamento dos testes, onde o propósito será elaborar a estratégia de teste e o plano de teste.
• Preparação, ou seja, preparar o ambiente para os testes.
• Especificação, a finalidade será elaborar os casos de testes e os roteiros de testes.
• Execução, executar os testes planejados e registrar os resultados.
• Avaliação dos resultados, comparar resultados anteriores com o depois da implantação, através dos dados registrados.

2.3. MOTIVAÇÃO

A oportunidade de desenvolver um trabalho, a ser implantado em ambiente de produção, suprindo as necessidades da empresa e agregando uma melhor qualidade ao desenvolvimento do software. Aprimorando o conhecimento, sobre testes em software, e apoiando, melhor capacitação dos profissionais envolvidos, Além de proporcionar uma maior satisfação ao cliente que estará recebendo um produto com maior qualidade.

2.4. DESCRIÇÃO DO TRABALHO

Este trabalho abordará conceitos de testes em software, onde apresentará uma introdução sobre a utilização de testes, problemática, solução proposta que serviram de base para o desenvolvimento. No referencial teórico, ele demonstra conceito sobre testes e ferramentas utilizadas e uma visão geral da norma IEEE. Também são detalhadas as etapas utilizadas, planejamento, especificações, execução e avaliação dos resultados. Finalmente a conclusão e as referências bibliográficas.

3. ESTADO DA ARTE

Este capítulo tem a finalidade de identificar e compreender, os principais conceitos e metodologias envolvidas no processo de implantação de testes em software, e conhecer algumas ferramentas que podem auxiliar no registro de defeitos e no desenvolvimento de planos de testes, roteiros e casos de testes.

3.1. TESTES EM SOFTWARE

O primeiro relato sobre bugs em computadores aconteceu em 1947, quando engenheiros trabalhavam com a Harvard Mark I. Eles encontraram um inseto nos circuitos. Este inseto estava causando um erro nos cálculos da máquina. O inseto foi retirado e colado no livro de registro.

A atividade de testar software se reflete atualmente no comportamento das empresas, no interesse em implantar ou mesmo melhorar o processo de teste utilizado.

Hoje, as empresas precisam entregar o produto com o menor número de problemas possíveis, já que é impossível entregar um software perfeito. Os clientes estão cada vez mais exigentes e o mercado mais concorrido.

Para definir os conceitos de Testes em software, é importante esclarecer alguns dos principais itens relacionados a esta atividade, tais como defeitos, erros e falhas. A diferença entre estes três os conceitos seguem abaixo. Elas estão definidas na terminologia padrão para engenharia de software do IEEE - Institute of Electrical and Electronics Engineers – (IEEE 610, 1990 apud DIAS NETO, 2007).

Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou 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 programa 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.

Figura 1 - Defeito x Erro x Falha
Fonte: Neto, 2007

As empresas tem uma grande dificuldade na área de teste em software, que pode ser pela escassez de mão de obra qualificada, para apresentar as técnicas e implantar um processo adequado à organização, Não conhecem o resultado sobre o percentual e o alto custo do retrabalho. Seria mais viável realizar teste, e corrigir os problemas ainda em ambiente de homologação.

Os testes servem para verificar se o sistema conseguiu atingir determinadas especificações, descobrindo o maior número de defeitos possíveis. O objetivo desse processo é ter um sistema com melhor desempenho, menor índice de falha e menor quantidade de problemas futuros.

Para Sommerville (2007), atingir o máximo de qualidade deve ser o maior objetivo das organizações, os clientes não admitem mais receber um produto, cheio de defeitos, para aos poucos ir corrigindo.

O teste é qualquer atividade que avalia a capacidade de um requisito, permite determinar se o programa ou sistema apresenta os resultados esperados (Barioto, 2012 apud Hetzel, 1988).

O teste pode ser classificado de duas maneiras; teste baseado em especificação (specification-basead testing) e teste baseado em programa (program based testing), (Maldonado, Barbosa e Vincenzi, 2004 apud Howden, 1987).

Testar um programa é analisar o mesmo com a intenção de descobrir erros e defeitos. (Crespo et. al , 2010 apud Myers 1979).

A atividade de teste em software é um elemento complexo, para atingir a garantia da qualidade e representar a última revisão de especificação, projeto e codificação. (Barioto, 2012 apud Pressman, 1995).

O processo de operação de um sistema ou componente em específicas condições, observando ou registrando os resultados, fazendo uma avaliação em alguns aspectos do sistema ou componente (IEEE).

A arte de testar precisa de profissionais capacitados, metodologia apropriada, ambiente adequado, e sempre iniciar paralelamente ao desenvolvimento. Quando o teste é tratado, como um dos processos importantes, sem dúvida, os custos de manutenção serão reduzidos e os clientes ficaram mais satisfeitos.

De acordo com Maldonado, Barbosa e Vincenzi (2004, p.2) “o teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projetos de casos de testes, execução e avaliação dos resultados dos testes”.

Segundo Bastos et al (2012, p.228)“ a atividade de testar sistemas, já algum tempo, passou a ser tratada como um projeto de teste independente, com gerenciamento e controles próprios, embora ligada diretamente ao projeto do sistema em questão. Em outras palavras, os projetos de teste, embora independentes, devem ser completamente coerentes com o projeto do sistema que é testado.”

3.1.1. Verificação e validação

De acordo com Moreira (2003, pag.30), a verificação: são testes, que permitem verificar se o software está sendo desenvolvido conforme a solicitação do cliente. Validação são testes que permitem validar a interface e as funcionalidades do sistema, exemplo: Teste de aceitação.

3.1.2. Tipos de Testes

Os testes em software são uma maneira de garantir a qualidade do sistema. Existem diversas maneiras, de se testar um sistema, teste mais baixo nível e teste mais alto nível é classificado em testes de caixa-branca (White-box testing) e os testes de caixa-preta (Black-box testing).

Caixa branca: ao contrário da caixa preta, os aspectos de implementação são fundamentais na escolha dos casos de teste. O teste estrutural baseia se no conhecimento da estrutura interna da implementação.

A técnica usada pelos desenvolvedores trabalha-se diretamente com o código-fonte do sistema. Os testes de unidade são testes de caixa-branca.

Segundo (Maldonado et al. , 2007, p.3), o teste de caixa branca baseia-se em programa que requer a especificação do código fonte, e seleção dos casos de teste que exercitem partes do código e não de sua especificação.

Figura 2 - Técnica de Teste Estrutural
Fonte: Artigo engenharia de software, Neto, 2007

Caixa preta: ela trata o software como uma caixa, cujo conteúdo é desconhecido, e só é possível visualizar o lado externo, ou seja, os dados de entrada fornecidos e as respostas produzidas como saída. Técnica usada pelos analistas de teste, testadores e usuários, trabalha-se com a interface do sistema, sem se preocupar com código-fonte do sistema. Entende-se o sistema como uma caixa onde ao inserir valores de entrada, retorna valores de saída, é utilizada a especificação dada pelo cliente para fazer o roteiro dos casos de teste.

Segundo (Maldonado et al. , 2007, p.4), o teste de caixa preta baseia-se em especificação cuja a finalidade é determinar se o programa satisfaz aos requisitos funcionais e não-funcionais especificados. Exemplos: teste funcional e de aceitação.

A diferença entre os dois é que o teste de aceitação é executado diretamente pelo cliente.

Figura 3 - Técnica de Teste Funcional
Fonte: artigo engenharia de software, Neto, 2007

Existem testes que são tanto de caixa-branca quanto caixa-preta, exemplos de testes mistos são: Testes de regressão devem ser executados toda vez que o sistema sofrer alterações, é necessário executar novamente os testes realizados anteriormente para garantir que os resultados não tenham sido afetados pela mudança realizada. Um dos objetivos é determinar se as funções previamente testadas continuam funcionando corretamente após a introdução de mudanças no sistema.

3.1.3. Técnica de teste funcional

São desenhados, para garantir que os requisitos e as especificações do sistema tenham sido atendidos. O processo de teste costuma envolver cenário de teste para uso na avaliação das funcionalidades da aplicação.

Segundo o livro base de conhecimento de testes em software, Aderson bastos et al (2012, p.58 – 65) contém os seguintes:

Testes de requisitos verificam se o sistema executa corretamente as funcionalidades, e se é capaz de sustentar essa correção, após a sua utilização por um período de tempo continuo, são realizados através da criação de checklists.

Teste de regressão deve ser executado sempre, que houver alguma alteração no sistema, sendo necessário voltar e testar os segmentos, após a de mudança, em outra parte do software.

Teste de tratamento de erros a capacidade do sistema de tratar s transações incorretas, aproximadamente 50% do esforço de programação, é dedicado ao tratamento das condições de erros em alguns softwares. E este teste requer que o testador pense negativamente.

Teste de suporte manual analisa se os procedimentos de suporte manual estão documentados e completos, determina, se as responsabilidades foram estabelecidas, verifica se a equipe que prestará suporte manual esta capacitada para executar a operação.

Teste de interconexão Garante que interconexão entre os softwares de aplicação funcione corretamente. A interconexão pode se dar através de dados recebidos, fornecidos ou ambos.

Teste de controle é a ferramenta de gestão necessária para assegurar que o processamento seja realizado conforme sua intenção. Entre os controles estão à validação de dados, integridade dos arquivos, trilhas de auditoria, backup, recuperação, documentação e outros aspectos do sistema relacionados à integridade.

Testes paralelos: É a comparação dos resultados do sistema atual, com a versão anterior determinando, se os resultados são consistentes com o processamento do antigo sistema.

3.1.4. Técnica de teste estrutural

São criados para verificar se o sistema desenvolvido e os programas funcionam. O objetivo é garantir que o produto desenvolvido funcione corretamente. A técnica não determina o funcionamento correto da aplicação, e sim a estrutura.

De acordo com o livro base de conhecimento de testes em software, Aderson bastos et al (2012, p.50 - 56) são citados abaixo compõem a técnica de teste estrutural.

Teste de execução analisa se o sistema atende aos critérios de desempenho específicos. Verificam os tempos de resposta, processamento e desempenho (performance). Avalia o comportamento do software simulando ambiente de produção.

Teste de estresse avalia o comportamento do software, sob condições criticas, tais como restrições significativas de memória, espaço em disco e CPU. Ron Patton, em seu livro software testing (Indianapolis: Sams, 2005), mostra que esse, é realizado colocando o software em condições mínimas de operação.

Teste de recuperação é capacidade de reiniciar operações, após a perda da integridade de uma aplicação. Responsável por garantir a continuidade das operações, após um desastre como queda de energia elétrica.

Teste de operação avalia o processo e sua execução, são desenhados para estabelecer se o sistema é executável, durante a operação normal, é um tipo de teste muito especifico, depende do software, exemplo é o software de “Call Center”.

Teste de conformidade verifica se a aplicação foi desenvolvida de acordo com os padrões, procedimentos e guias de TI. É importante ressaltar que pode ser mais viável executar os testes de conformidade durante a fase de requisitos do que nos estágios finais do ciclo de vida. Pois será difícil corrigir aplicações se os requisitos não estiverem devidamente documentados.

Teste de segurança É um teste para garantir a confidencialidade das informações, e a proteção dos dados contra o acesso indevido de terceiros.

3.2. PROCESSOS DE TESTE DE SOFTWARE

De acordo com Bastos et al (2012), o objetivo de um processo de teste, com metodologia própria, é diminuir os defeitos provenientes do processo de desenvolvimento. Para isso os testes passam a ser executados por especialistas.

Segundo Crespo et al (2010, p.4) “Processo de Teste: A metodologia define um processo genérico de teste que prevê a realização das atividades de planejamento, projeto, execução e acompanhamento dos testes de unidade, integração, sistemas e aceitação. A partir deste processo genérico cada empresa deve instanciar um processo específico que melhor atenda suas necessidades.”

De acordo com Crespo et al (2010, p.5), um processo de teste de software, é um conjunto de passos, parcialmente ordenados, constituídos por atividades, métodos e pratica usado para testar um produto.

O processo de teste tem as seguintes partes: Entradas: são todas as informações necessárias para a execução do teste do software, tais como informações, especificação de requisitos. Mecanismos e agentes são as equipes de teste, técnicas, procedimentos, e as ferramentas. Restrições e condições, cronogramas, custos, confiabilidade requerida. Saídas são os resultados, produtos da execução das atividades, tais como: Software testado, defeitos revelados, nível de confiabilidade atingido, qualidade desejada.

O processo de teste é voltado para o alcance de um nível de qualidade de produto, que durante o processo de desenvolvimento de software muda conforme avanço das atividades, requisitos, protótipos, modelos de dados logico, modelo de dados físico, código-fonte, módulos funcionais e finalmente um sistema.

Figura 4 - Ciclo de vida do processo de teste
Fonte: Rios, E. & Moreira, T.Teste de software.Rio de Janeiro, Alta Books, 2003

Figura 5 - Processo de Teste de Software
Fonte: Bastos et al, Base de Conhecimento de testes em Software, 2012

3.3. CASOS DE TESTES

Uma descrição especifica de um teste a ser executado. Um ou mais casos de testes costumam, estar relacionados a um caso de uso.

Um bom caso de teste é aquele que encontra erros ocultos (Barioto, 2012 apud Myers, 1979).

Um caso de teste é um documento que possui entradas dentro inseridas no sistema/programa e suas saídas esperadas. Mostra os caminhos percorridos por um módulo, caso de uso ou funcionalidade dentro do projeto. Servem como base para que, os testadores possam executá-los manualmente, mas podemos cria-los com intuito de automatizar e cobrir o máximo de situações possíveis.

Tabela 1 - Representação caso de testes 01

Fonte: Neto, 2007

3.4. ROTEIROS DE TESTES

“O roteiro precisa ter casos de testes bem escritos e objetivo para que o testador consiga executar com facilidade, é necessário eficiência e que no resultado final se encontre o maior numero de erro possível. No caso de teste será necessário o detalhamento das atividades a serem executadas.” (Caroline, 2007).

O roteiro de teste é uma maneira de realizar testes manuais em sistemas, fundamental para a execução, de maneira simplificada. Ele é composto por um conjunto de casos de testes.

A Pré-condição, é um requisito para o comportamento do sistema antes da execução do caso de teste. O procedimento está detalhado a deverá seguir a descrição do caso de teste. O resultado esperado como o sistema deveria se comportar depois de finalizadas as etapas do caso de teste.

Modelo de Roteiro de testes
Projeto: OMNI/NFE_001                          Autor: Marcos Roberto Gonçalves
Roteiro: v.001.1                                      Data: 06/10/2012

Tabela 2 - Roteiro de Teste 

Fonte: Artigo Engenharia de software, Neto, 2007

3.5. TESTE DE SOFTWARE E SUA IMPORTÂNCIA

Com a necessidade das empresas por sistemas ágeis, seguros e estratégicos, para os negócios, o teste de software cumpre um papel fundamental na gestão desse ambiente. A qualidade tornou-se uma operação indispensável para empresas que procuram minimizar gastos, evitar retrabalho e entregar um produto confiável e competitivo.

Quanto mais cedo os erros forem descobertos, mais barato será a manutenção. Durante os últimos trintas anos, a grande massa da comunidade de engenharia de software, tem utilizado os mesmos modelos de processos de desenvolvimento. (Gonçalves, 2009 apud Pressman, 2006).

3.6. POR QUE TESTAR SOFTWARE

Errar é humano. Estudos indicam que é impossível desenvolver um sistema sem defeitos. Softwares podem além trazer prejuízo financeiro, também colocar vidas em riscos. É necessário diminuir ao máximo os defeitos no sistema, garantindo que os erros serão eliminados, Também para agregar qualidade do produto e reduzir o custo.

3.6.1. Características de Qualidade

Segundo Bastos et al (2012, p.140), A Norma ISO/IEC 9126-1 define as características de qualidade que o software deve atender: Funcionalidade, verificar a capacidade do sistema em prover funcionalidades definidas que atendam as necessidades do usuário, quando usado sob determinadas condições pré-estabelecidas. Confiabilidade, o produto de software é capaz de manter seu nível de desempenho, ao longo do tempo, nas condições estabelecidas de utilização. Usabilidade, capacidade, em ser entendido, aprendido e utilizado sob as condições estabelecidas. Eficiência os recursos e os tempos envolvidos são compatíveis com o nível de desempenho requerido. Manutenibilidade, esforço necessário para realização de alterações especificas no produto. Portabilidade, facilidade de poder ser transferido de um ambiente para outro.

Características de qualidade e os tipos de teste necessários segundo a metodologia de Bastos et al (2012, p.99).

Tabela 3 - Características de Qualidade

Fonte: Bastos et al, Base de Conhecimento de testes em Software, 2012

3.6.2. Custos da qualidade de software

Muitas empresas se preocupam com o valor para implantação dos testes, o custo elevado das atividades e dos procedimentos que buscam garantir a qualidade.

Segundo Tocchetto (2011), todas as atividades tem um custo associado, sendo que, para que possamos calcular o custo da qualidade devemos considerar três elementos: o custo da falha, o custo da prevenção e o custo da avaliação, sendo cada um deles citados abaixo: (http://www.profissionaisti.com.br/2011/11/desenvolvimento-de-software-custo-da-qualidade).

Custo da falha, de custos com produtos defeituosos entregues ao cliente. Podemos associar a este custo os reparos, a utilização da equipe de helpdesk, bem como, os danos causados por um defeito.

Custos da prevenção, com atividades que possam evitar defeitos. Treinamentos, definição de métodos, procedimentos e aquisição de ferramentas. É possível observar que, praticamente todas as atividades do time de garantia da qualidade estão associadas a este custo.

Custo da avaliação com a detecção de defeitos. Neste elemento podemos citar as atividades de teste de software, tempo gasto na automação de scripts de teste, revisões e inspeções.

A cada uma alternativa, esta associada um custo especifico, Esses somados, constituem o custo da qualidade. O custo da qualidade é parte do custo total de produção do software, que comtempla também os custos de sua construção.

​Figura 6 - Comparação de custos 
Fonte: QAI - Quality Assurance Institute

3.7. FERRAMENTAS DE TESTES

Este capítulo tem a finalidade de apresentar o conceito sobre as ferramentas utilizadas neste trabalho.

Mantis: é uma ferramenta utilizada para gerenciamento de defeitos, é gratuita e Open Source tem um mecanismo onde se podem gerenciar defeitos de vários projetos ao mesmo tempo. Pela vantagem de ser Web o defeito relatado no mantis pode ser acessado facilmente através de um browser. Ao acessar o projeto é possível criar, editar ou remover um defeito associado a ele. Estas permissões são atribuídas pelas organizações através do controle do perfil de cada usuário, cada perfil pode ser configurado de acordo com a necessidade dos projetos. Os defeitos cadastrados podem ter diversas severidades, status e prioridades. Assim que o testador encontrar um defeito e cadastrar no mantis, também poderá imediatamente atribuir a um desenvolvedor para ser corrigido. A facilidade ao trabalhar com esta ferramenta permite uma interação entre desenvolvedores e testadores que proporciona uma rápida correção dos defeitos.

Figura 7 - Ferramenta Mantis para gerenciamento de defeitos
Fonte: http://www.mantisbt.org, 2012

Testlink: é uma ferramenta gratuita, e Open Source é utilizado para gerenciamento dos testes, da mesma forma que o mantis é plataforma web. pode ser acessada de qualquer browser. É simples e intuitiva e dispensa muito tempo de treinamento. Pode ser utilizados no desenvolvimento de casos de testes, plano de testes, roteiros e para registros de requisitos do sistema. Após o desenvolvimento, o testlink pode ser utilizado no apoio à execução os testes, registrando seus status (passou, falhou ou bloqueado) durante a fase de testes. Após a finalização dos testes é possível gerar relatórios com toda a informação registrada durante a execução dos testes. O testlink permite criar vários projetos, plano de testes, organizar casos de testes de cada projeto em suítes de acordo com a necessidade.

Figura 8 - Ferramenta Testlink para gerenciamento de testes
Fonte: o autor (2013)

A figura apresentada acima é uma representação ilustrativa da ferramenta Testlink que está instalada no equipamento que foi utilizado para desenvolver esse trabalho, em servidor local.

3.8. VISÃO GERAL DA NORMA IEEE 829

De acordo com Crespo (2010, p.5), a norma IEEE 829-1998 descreve um conjunto de documentos para as atividades de teste de um produto de software.

Os documentos definidos cobrem as tarefas de planejamento, especificação e relato de testes, são citados abaixo.

Plano de teste apresenta o planejamento para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma das atividades de teste identificam os itens e as funcionalidades a serem testadas, tarefas a serem realizadas, riscos associados com a atividade. A tarefa de especificação de testes é coberta pelos 3 documentos citados abaixo.

Especificação de projeto de teste refina a abordagem apresentada no plano de teste e identifica as funcionalidade e características a serem testadas. Este documento também identifica os casos e os procedimentos, se existir, apresenta os critérios de aprovação.

Especificação de caso de teste inclui dados de entrada, resultados esperados, ações e condições gerais para a execução do teste.

Especificação do procedimento de teste especifica os passos para executar um conjunto de casos de teste.

Os relatórios de testes são cobertos pelos 4 documentos seguintes.

Diário de teste: apresenta registros cronológicos dos detalhes relevantes relacionados com a execução dos testes.

Relatório de incidente de teste: Documenta qualquer evento que ocorra durante a atividade de teste que requeira analise posterior.

Relatório resumo de teste: apresentam de forma resumida os resultados das atividades de teste associadas com uma ou mais especificações de projeto de teste e prove avaliações baseadas nesses resultados.

Relatório de encaminhamento de item de teste: identifica os itens encaminhados para teste no caso de equipes distintas serem responsáveis pelas tarefas de desenvolvimento e de teste.

Figura 9 - Relacionamento entre documentos de teste
Fonte: Crespo et al (2010)

Segundo CRESPO (2010, p.6), a norma IEEE 829-1998 indica que as atividades são separadas em 3 etapas: Preparação, execução e registro do teste.

A norma pode ser utilizada para teste de produtos de software de qualquer tamanho e complexidade, em projetos pequenos e de baixa complexidade para diminuir o gerenciamento e os custos de produção dos documentos. Alguns documentos propostos podem ser agrupados.

Os documentos podem ser adaptados a empresas ou projetos. A norma também apresenta um conjunto de informações necessárias para o teste de produtos de software. Se for seguida corretamente auxiliara a gerência a se concentrar tanto nas fases de planejamento, quanto à realização de testes. Evitando o problema de pensar em testar o software apenas após a conclusão.

3.9. TRABALHOS RELACIONADOS

Os trabalhos relacionados abaixo servem como fonte para a discussão dos resultados entre os trabalhos expostos e o presente trabalho.

3.9.1. Trabalho de Silva e Severino (2010)

O trabalho monográfico de Silva e Severino foi apresentado com a finalidade de implantação e melhoria na qualidade de aplicações através de um sistema de gestão de testes.

O propósito do trabalho foi fornecer uma ferramenta contendo um método simplificado que possa auxiliar na implantação de um processo de Testes de software. A ferramenta dará ao gerente segurança e capacidade de medir a qualidade do seu produto. Neste trabalho, especificamente, a ferramenta elaborada pelos acadêmicos será um auxiliar no processo de Testes de software. A referida ferramenta foi desenvolvida a partir de estudos bibliográficos e eletrônicos, que serviram de base para a sua construção. A ferramenta em questão atua sob os níveis G e F do modelo de maturidade de software MPSBR.

O nível G de maturidade é o nível mais baixo do modelo MPSBR, sendo ele composto pelo processo de Gerência de Projetos e Gerência de Requisitos. (SOFTEX, 2009).

O nível F do modelo de amadurecimento de processo tem como objetivo agregar processos de apoio à gestão do projeto tais como: Garantia da Qualidade (GQA), Medição (MED), Gerência de Configuração (GCO), Aquisição (AQU), Portfólio de Projetos (GPP), ficando sobre responsabilidade dos processos GQA e MED a abordagem mais aprofundada sobre o gerenciamento de Testes. (SOFTEX, 2009).

Para a definição do processo de Testes foi feito um estudo sobre as metodologias para gerenciamento de processo com foco em Testes. Nessa análise optou-se por utilizar o MPSBR. Foi construída uma aplicação para ambiente WEB, fornecendo flexibilidade à empresa que a utilizará, podendo acompanhar o processo de qualquer local que possua uma conexão com a internet.

O resultado foi à criação de uma ferramenta que pode ser comercializada.

​Figura 10 - Aplicação para implantação de Testes
Fonte: Silva e Severino (2010)

3.9.2. Trabalho de Kammers (2006)

O trabalho monográfico de Kammers apresentou um proposito de descrever as fases do processo de testes e as atividades envolvidas. Apresentando problemas e dificuldades geradas pelo não uso de uma metodologia de testes. Conforme os sistemas se tornam mais complexos e cruciais para a empresa, aumenta a importância de um teste eficaz. Vimos que na década de (70 a 90) aumenta a participação do teste no total de esforços de um projeto. As atividades de teste que antes eram executadas apenas na última fase de um projeto, agora atuam a partir do momento em que ele possua requisitos.

Ao observar a importância e complexidade das atividades envolvidas, vimos à necessidade do uso de uma metodologia para gerir este processo. Através deste trabalho, notamos a complexidade que o processo de teste possui. E que para que ele tenha êxito, é fundamental que as etapas de planejamento sejam elaboradas com muito critério e detalhamento.

Além disso, as atividades de teste devem estar alinhadas com o processo de desenvolvimento. Se não houver esta cooperação entre as equipes o processo pode não ter êxito.

E para que o processo ocorra de modo organizado, deve ser dada ênfase ao preenchimento correto e pleno da documentação referente a cada etapa do teste.

3.9.3. Artigo de Ochner e Mendes

Este artigo define um guia de implantação da área de testes em iterações para pequenas e médias empresas de software. O objetivo do guia é utilizar os benefícios da abordagem iterativa para facilitar a implantação e estruturação de testes. Ele foi definido com base na disciplina Testes da metodologia de desenvolvimento de software RUP, do padrão para artefatos de testes IEEE 829, das práticas definidas pelo TMM e pelas áreas de processo Verificação e Validação do CMMI.

A indústria mundial de Tecnologia da Informação tem investido, cada vez mais, em atividades de testes. Carreiras de especialistas em testes vêm sendo criadas em maiores escalas.

Para o desenvolvimento de software com qualidade, dentro de prazos e custos controlados e compatíveis com o mercado, é fundamental a melhoria dos processos da engenharia de software. A melhoria de processo de software tem sido baseada em modelos como CMMI[CMMI, 2002], ISO/IEC12207, ISO/IEC 15504 [ISO/IEC, 1998]. Estes modelos identificam processos fundamentais para a engenharia de software, Por este motivo, a comunidade científica tem criado modelos complementares que endereçam especificamente o processo de testes, tais com TMM [TMM, 2002], TPI [TPI, 1999], entre outros.

Modelo de maturidade de teste de software se reflete atualmente no comportamento das empresas na busca em implantar ou mesmo melhorar o processo de teste utilizado. Com o objetivo de facilitar a implantação de testes em pequenas e médias empresas de software, foi definido um guia que especifica todas as fases e atividades necessárias para que esta implantação seja feita de forma estruturada.

Tabela 4 - Comparação de trabalhos relacionados 

Fonte: Autor (2013)
A tabela foi desenvolvida pelo autor para comparação dos trabalhos relacionados.

4. MÉTODO PROPOSTO

Esse trabalho foi desenvolvido através de livros, artigos, revistas, sites e normas técnicas. As metodologias e ferramentas estudadas foram analisadas a fim de identificar características a serem adotadas ou consideradas no desenvolvimento.

Para que sejam alcançados, e para um melhor entendimento o trabalho será desenvolvido em etapas.

Figura 11 - Representação das Etapas para o objetivo ser atingido
Fonte: Autor (2013)

A figura apresentada acima foi desenvolvida para apresentar as etapas detalhadas.

4.1. 1ª ETAPA PLANEJAMENTO DOS TESTES

Para atingir a primeira etapa, iniciando o projeto para a implantação dos testes na empresa Softpar, será utilizada a ferramenta testlink, a utilização terá como objetivo o gerenciamento de testes. O testlink tem a opção de desenvolver projeto de testes, planos de testes, suítes de testes e casos de testes. Facilitando o trabalho dos testadores e possibilitando uma melhor comunicação entre testadores e desenvolvedores. O testlink é uma ferramenta open source e plataforma web.

4.1.1. Plano de Teste

Para o teste ser bem sucedido é necessário ter um bom planejamento. É necessário utilizar um documento padronizado e que seja guiado por regras e normas internacionais. O documento utilizado é conhecido como plano de teste, e é nele que definimos o nível de cobertura e a abordagem dos testes.

Segundo bastos et al (2012) a norma IEEE 829:2008 relaciona os seguintes elementos que deverão constar no plano de teste:

Tabela 5 - Definição da Norma IEEE 829:2008 para Plano de Trabalho.

Fonte: Bastos et al, Base de Conhecimento de testes em Software, 2013.

Após a instalação e configuração da ferramenta testlink, será desenvolvido o plano de teste conforme mostra a figura 12.

Figura 12 - Desenvolvimento Plano de Testes
Fonte: o autor (2013)

A figura apresentada acima é uma representação ilustrativa da ferramenta testlink que está instalada em um servidor local.

4.1.2. Estratégia de Testes

Segundo Emerson Rios e Trayahú Moreira, no livro Teste de software (Rio de Janeiro: Alta Books, 2003): “Na formulação da estratégia de teste devem ser levados em consideração diversos fatores, tais como o porte e importância do software, requisitos, prazos estabelecidos, riscos do negócio e os custos envolvidos”.

Na estratégia de teste deve incluir: Os estágios ou níveis de teste a serem abordados, (unidade, integração, sistema e aceitação); Informar a fase do desenvolvimento em que se aplica o teste referido; Os tipos de testes que devem ser executados (funcional, desempenho, carga, estresse entre outros); As técnicas e ferramentas a serem empregadas no teste (funcionais e estruturais); E os critérios de conclusão e êxito do teste que serão aplicados.

Será discutido em uma reunião com integrantes da equipe de desenvolvimento qual o módulo será liberado os testes.

Para a elaboração do planejamento de testes será efetuado o levantamento de requisitos de testes.

Requisitos: A elaboração de um Documento de Requisitos tem por objetivo coletar as informações necessárias para que o software seja validado e entregue ao cliente conforme a sua real necessidade.

Para definir os requisitos deve-se detalhar exatamente o que se deseja testar. (Silva e Severino, 2010 apud Molinari, 2008).

4.2. 2ª ETAPA PREPARAÇÃO

Nesta etapa a finalidade será organizar o ambiente para os testes, disponibilizar os equipamentos que serão utilizados, o pessoal, as ferramentas, hardwares e o software.

Na etapa de preparação será avaliada a necessidade de treinamento para a equipe designada aos testes.

A ferramenta utilizada nesse processo é citada na seção 2.7 do capítulo 2 que é o testlink para a criação do projeto de teste, plano de teste, casos de testes e roteiros de teste.

O ambiente projetado para a execução dos testes tem a finalidade de aproximar-se ao máximo ao do cliente. As atividades da preparação. As atividades da preparação: Instalar hardware e software necessário; A ferramenta que será utilizada; Definir arquitetura do ambiente de produção e desenvolvimento; Preparar o ambiente em conformidade com o real; e avaliar a necessidade de treinamento.

Segundo bastos et al (2012, p.46) a infraestrutura e as ferramentas de teste precisam atender as necessidades da equipe de testes, sendo necessário avaliar a necessidade de treinamento da equipe.

4.3. 3ª ETAPA ESPECIFICAÇÃO

Os objetivos desta etapa são elaborar os casos de testes e os roteiros de testes.

Após a equipe de desenvolvimento liberar módulos ou partes do sistema para os testes, será iniciado a elaboração do roteiro e casos de teste.

Esta etapa será elaborada com apoio da ferramenta testlink onde os roteiros e os casos de teste são preparados. Como mostra a figura 13.

4.3.1. Roteiro de Testes

A primeira etapa definida será a elaboração dos roteiros de testes, pois é considerada uma das partes mais importante para a execução dos testes, onde o testador consegue realizar uma sequência de passos de forma prática.

Os roteiros apresentaram os passos detalhados da tarefa que será executada pelo testador.

4.3.2. Casos de Testes

Serão desenvolvidos com apoio da ferramenta testlink, que apresentará os resultados esperados dos testes e terá como objetivo identificar resultados positivos e negativos.

Segundo a metodologia de Bastos et al (2012, p.153) a norma IEEE 829 orienta que um caso de teste deve possuir: Identificador de caso de teste, Itens de teste, Especificações de entrada, Especificações de saída, Ambiente necessário, Exigências especiais e Interdependências.

Tabela 6 - Definição da Norma IEEE 829 sobre Casos de Testes

Fonte: Bastos et al, Base de Conhecimento de testes em Software, 2013

Figura 13 - Desenvolvimento Casos de Testes
Fonte: o autor (2013)

A figura apresentada acima é uma representação ilustrativa da ferramenta Testlink que está instalada no equipamento que foi utilizado para desenvolver esse trabalho, em servidor local.

4.4. 4ª ETAPA EXECUÇÃO DOS TESTES

A finalidade é executar os casos de testes, conforme o roteiro e registrar os defeitos encontrados.

Alguns profissionais julgam que este é o momento em que o teste é realizado de fato.

A execução dos testes ocorrerá com apoio da ferramenta testlink, o testador executa os passos do roteiro, no módulo liberado de acordo com os procedimentos definidos e informa o resultado obtido.

O testador tem a opção de descrever uma nota sobre a execução do teste e atribuir um resultado diretamente para o caso de teste, (passou, falhou não executado e bloqueado). Como mostra a figura 14.

Figura 14 - Execução dos Testes
Fonte: o autor (2013)

Para o registro e controle dos defeitos a ferramenta utilizada é o Testlink. Existem vários benefícios ao utilizar esta ferramenta, dentre eles, melhora a comunicação entre os desenvolvedores e testadores.

A figura 14 apresentada acima é uma representação ilustrativa da ferramenta Testlink que está instalada no equipamento que foi utilizado para desenvolver esse trabalho, em servidor local.

4.5. 5ª ETAPA AVALIAÇÃO DOS RESULTADOS

Nesta etapa será apresentado o método utilizado para avaliação dos resultados da implantação de testes na empresa Softpar, considerando os resultados registrados anteriores com o depois de implantar a metodologia para execução dos testes.

Para o apoio da avaliação será utilizada a ferramenta mantis citada na seção 2.7 capítulo 2, a qual contém o registro dos erros do período de 2010 a 2012.

Figura 15 - Ferramenta mantis que contém registro dos erros de 2010 a 2012
Fonte: http://www.mantisbt.org, 2013

4.5.1. Métodos de avaliação

A avaliação será elaborada por módulos, serão avaliados os módulos de emissão de NF-e e cadastro de emitente, a execução dos testes serão realizadas nos meses Fevereiro, Março e Abril de 2013. Esses resultados ficaram registrados na ferramenta testlink.

A comparação será através de gráficos onde haverá a análise de apenas 3 meses dos anos anteriores 2010, 2011 e 2012, que estão registrados na ferramenta de gerenciamento de erros mantis, comparado com o resultado obtido dos testes executados com a metodologia implantada em 2013.

Os bugs encontrados nestes períodos serão documentados, conforme estão registrados na ferramenta mantis e testlink. O tempo utilizado para avaliação nesta etapa é de 3 meses.

A próxima avaliação terá por finalidade a comparação dos dados registrados, em um período de 12 meses nos anos 2010 a 2012, e analisados com apenas 3 meses de 2013.

4.5.2. Critérios de avaliação

O critério utilizado para avaliação será a coleta dos bugs identificados nos módulos de emissão de notas fiscais eletrônicas e cadastros de emitentes dos anos 2010 a 2012 onde os testes eram executados sem metodologia, e de forma aleatória, onde serão comparados com o registro dos testes do ano 2013 com a metodologia implantada. Os resultados serão apresentados na tabela ilustrada abaixo.

A tabela 7 ilustrada abaixo terá a finalidade de registrar os bugs pelo ano do registro, pela quantidade, encontrados no período, a descrição que informa o nome do módulo que será disponibilizado para os testes e porcentagem de bugs encontradas em cada módulo.

Tabela 7 - Registro dos bugs

Fonte: O autor (2013)

4.5.3. Análise e discussão dos resultados

A analise será realizada através das tabelas e dos gráficos, comparando os resultados definidos antes da implantação, e após a metodologia aplicada, com os resultados registrados será possível, analisar se a metodologia utilizada trouxe mais eficiência aos testes, ou se a técnica utilizada precisa ser aprimorada.

5. RESULTADOS

Representará os resultados mapeados com a implantação da metodologia aplicada, em testes de software na empresa Softpar.

5.1. APRESENTAÇÃO DOS ERROS REGISTRADOS

As tabelas 8, 9 e 10 ilustradas abaixo apresentam os resultados, conforme a quantidade de erros que foram registrados em, 2010 a 2012, pela ferramenta mantis, utilizada pela empresa Softpar para registrar os erros a qual é citada na seção 2.7 do Capitulo 2.

A tabela 11 apresenta a quantidade de bugs que foram identificados no ano 2013, após a realização dos testes utilizando a metodologia aplicada.

A tabela 8 ilustrada abaixo apresenta a quantidade de bugs que foram encontrados nos meses de setembro, outubro e novembro do ano de 2010 quando a empresa Softpar realizava o teste aleatoriamente.

Bug é um erro no funcionamento comun de um software ou hardware, também conhecido por falha lógica programacional de um programa de computador, pode causar discrepâncias no objetivo, ou impossibilidade de realização, de uma ação na utilização de um programa de computador ou apenas uma trava no sistema. Um termo criado por Thomas Edison quando um inseto causou problemas de leitura em seu fonógrafo em 1878.

E o primeiro registro de um bug segundo o livro base de conhecimento em teste de software aconteceu em 1947, quando os engenheiros que trabalhavam no Harvard Mark I encontraram um inseto nos circuitos. Este inseto estava causando um erro nos cálculos da máquina. O inseto foi retirado e colado no livro de registro.

Tabela 8 - Registro dos bugs 2010.

Fonte: O autor (2013)

Observou-se que no ano de 2010, foi registrado um total de 20 erros onde 95% dos itens avaliados, pertencem à emissão NF-e e somente 5% ao cadastro de emitente. Analisando que a empresa não utilizava metodologia para execução dos testes provavelmente os 95% dos erros identificados foram encontrados por clientes ao efetuar a emissão da nota fiscal eletrônica.

A tabela 9 ilustrada abaixo apresenta o resultado dos bugs que foram encontrados nos meses de Setembro, Outubro e Novembro de 2011, quando a empresa Softpar registrava os bugs, conforme eram identificados no teste aleatório, ou quando os erros apareciam em ambiente de produção, onde eram informados pelos clientes.

Tabela 9 - Registro dos bugs 2011

Fonte: O autor (2013)

Na tabela do ano 2011, foram registrados apenas 6 bugs no período estudado nos módulos de emissão NF-e e cadastro emitente. É possível observar nesta tabela que nos meses de setembro, outubro e novembro de 2011, os clientes tiveram pouco problema para emitir notas fiscais eletrônicas, se comparado com o ano anterior 2010, em contrapartida, aumentou o registro de bugs no cadastro de clientes.

A tabela 10 apresenta os bugs, identificados em testes aleatórios e em ambiente de produção nos meses Setembro, Outubro e Novembro de 2012.

Tabela 10 - Registro dos bugs 2012

Fonte: O autor (2013)

Verificou-se que no ano 2012, foi registrado um total de 24 bugs, sendo que 92% é emissão NF-e e apenas 8% cadastro de emitente.

Com o resultado apresentado na tabela 10, observa-se que aumentou a quantidade de bugs no módulo de emissão notas fiscais eletrônicas, que pode ter sido motivado por diversos fatores, dentre eles a atualização ou a alteração de campos no módulo emissão NF-e, sendo solicitado por clientes para facilitar a utilização do sistema, outro fator que pode ter originado o aumento de bugs foi a elevação das vendas do sistema.

Logicamente onde há mais pessoas usando o mesmo sistema a possibilidade de erros serem encontrados é elevada.

A tabela 11 apresenta o resultado de bugs registrados no ano de 2013. Onde a condução dos testes é executada obedecendo à metodologia aplicada.

Tabela 11 - Registro dos bugs 2013

Fonte: O autor (2013)

Na tabela 11 é possível observar, que o resultado da execução do testes após implantação da metodologia aplicada foi extremamente significativo, em relação aos anos comparados, observou-se que no mesmo período, foi possível identificar 61 bugs o que representa 54% do total dos itens avaliados nos 4 anos.

Neste período, é possível visualizar que os testes executados, apresentaram resultado positivo, além disso, pode-se considerar que os testes realizados neste período, foram eficientes e confiáveis, levando em consideração, que a possibilidade do testador esquecer algum passo do roteiro é praticamente nula.

Gráfico 1 - Resultados de bugs encontrados no estudo trimestral.
Fonte: O autor (2013)

O gráfico acima apresenta os dados coletados nos anos de 2010, 2011, 2012, e também o resultado do trabalho aplicado nos meses Fevereiro, Março e Abril do ano de 2013, no qual, comparou-se em apenas 3 meses, o percentual de erros registrados, nos cadastro de emitentes e emissão de notas fiscais eletrônicas.

Dessa forma, foi possível observar que a metodologia proposta nesse trabalho, foi considerada positiva, tendo a mesma, alcançado um total de 54% de erros encontrados, o que é extremamente significativo em relação aos anos comparados, provando assim, que a metodologia testada, foi eficaz.

A metodologia aplicada busca reduzir, ou mesmo sanar problemas de atraso na entrega do software, diminuir retrabalhos um dos fatores que gera desperdício de tempo e dinheiro nos processos de desenvolvimento. Os roteiros auxiliam as equipes de testes a trabalharem de maneira mais clara e produtiva, sendo que é possível testar uma gama de possibilidades e requisitos tornando o software mais qualificado, produtivo e confiável.

Aumentar a confiabilidade de um programa significa encontrar e corrigir erros. Um dos fatores que tornam a metodologia eficiente é a integração constante entre os testadores e os desenvolvedores, isso favorece para que as necessidades dos clientes sejam rapidamente compreendidas e em seguida implementadas com a sua resolutividade.

Com os resultados apresentados é possível identificar quais são os pontos mais críticos do sistema, onde o teste precisa ser executado com maior frequência e criticidade.

As tabelas 8, 9, 10 e 11, citadas na seção 4.1 do capítulo 4, ilustram claramente que através do estudo realizado nos módulos apresentados no gráfico 2, foi possível identificar que o módulo emissão de NF-e, é sem duvidas o módulo que se apresentou mais critico no período do estudo. Sendo que o percentual de bugs registrados é de 86% sobre os itens avaliados.

Gráfico 2 - Apresentação dos resultados do estudo
Fonte: O autor (2013)

É importante salientar a eficiência de uma metodologia aplicada, onde faz com que a qualidade, a credibilidade, a confiança e a competitividade do software cresçam, permitindo a empresa entregar o sistema no tempo definido no projeto, com menor número de falhas possíveis e com custo dentro do previsto.

Gráfico 3 - Resultados de bugs encontrados no estudo anual
Fonte: O autor (2013)

O gráfico 3, apresenta a comparação dos resultados coletados no estudo, onde é possível observar que no ano de 2013, os testes executados com a metodologia aplicada em um período de apenas 3 meses apresentou resultado significativo, comparado aos testes aleatórios executados pelo período de 12 meses, nos anos de 2010 a 2012.

Claramente é possível observar a vantagem em executar testes através de roteiros. Usando a metodologia aplicada foi possível encontrar 29% de bugs nos itens avaliados, o que representa apenas 8% a menos dos bugs encontrados, nos testes aleatórios realizados por 12 meses no ano de 2012.

Através deste trabalho, foi possível verificar a complexidade do processo de testes, observa-se que quanto mais organizado for o procedimento para execução dos testes, mais eficiente será a condução da atividade. Mais bugs serão identificados e mais credibilidade a empresa terá no mercado de desenvolvimento de software.

6. CONCLUSÃO

Qualidade é fator de competitividade, na nova realidade do setor de desenvolvimento de sistemas, que é comprovado pelos aspectos, que levaram as empresas buscarem profissionais experientes voltados, à área de testes com intuito de entregar o produto com o menor número de defeitos possíveis.

Este trabalho monográfico implantou testes em software através de uma metodologia aplicada, utilizando como base o desenvolvimento de roteiros onde os testes são executados passo a passo. Essa metodologia foi aplicada na empresa Softpar, a qual visualizou a importância de utilizar uma metodologia de aplicação de testes, à facilidade para conduzir a atividade e os benefícios através da utilização desta metodologia.

Para o desenvolvimento dos planos de testes, roteiros e casos de teste realizou-se a instalação e configuração da ferramenta de gerenciamento de testes testlink a qual é está citada na seção 2.7 do Capítulo 2.

O total de bugs registrados nos anos de 2010 a 2012 foram coletados da ferramenta mantis, a qual é citada na seção 2.7 do capitulo 2 e os resultados da coleta dos bugs são citados nas tabelas 8,9 e 10 da seção 4.1 do capitulo 4.

O resultado dos testes executados no ano de 2013 através da metodologia aplicada foi registrado na ferramenta testlink. Onde se observou que foi alcançado um total de 54% de erros na execução dos testes, O que representa que os testes executados através de roteiros apresentaram resultado positivo sendo que o objetivo de encontrar mais erros foi atingido.

Para afirmar que a proposta desenvolvida neste trabalho monográfico é valida, apresenta-se a comparação entre a quantidade de bugs registrados nos 3 meses, em que os testes são executados utilizando a metodologia aplicada, e os testes aleatórios, executados pelo período de 12 meses nos anos de 2010 a 2012.

O resultado foi satisfatório, atingiu-se em um período menor de testes, um percentual considerável, a diferença entre os bugs encontrados em 2013, foi somente 8% a menos comparado com o ano de 2012, o único ano que os testes aleatórios foram superiores a metodologia aplicada.

Com isso é possível observar que a metodologia proposta nesse trabalho, foi considerada positiva, sendo a mesma, satisfatória, em todas as comparações efetuadas.

O resultado foi extremamente significativo, em relação aos anos comparados, provando assim, que as avaliações, foram eficazes.

Além disso, foram definidos conceitos de algumas normas de qualidade, dentre as mais utilizadas, e também as técnicas de testes, tais como documentações geradas, quais tipos de testes são utilizados atualmente, onde se aplicam e quais os benefícios de se investir na área de testes.

Como sugestões para trabalhos futuros propõe-se implantar a metodologia aplicada neste trabalho monográfico em todos os módulos do sistema desenvolvido pela empresa Softpar. Definir processos para os testes iniciarem desde o inicio do ciclo de desenvolvimento do sistema, estudar e adquirir conhecimento para desenvolver scripts para automatizar os testes.

7. REFERÊNCIAS BIBLIOGRÁFICAS

Aderson Bastos, Emerson Rios, Ricardo Cristalli e Trayahú Moreira, Base de conhecimento em teste de software (Rio de Janeiro: Alta Books, 2012).

ALMEIDA Carla. Introdução ao teste de software. Disponível em Disponível em 

W. E. Howden. Software Engineering and Technology: Functional Program Testing
and Analysis. McGrall-Hill Book Co, New York, 1987.

8. APÊNDICES

Verde oliva = cadastro de emitente.
Amarela = emissão NF-e.

Azul = cadastro de emitente.
Vermelho = emissão NF-e.

Cor azul = cadastro de emitente.
Laranja = emissão NF-e.

Azul = cadastro de emitente.
Branco gelo = emissão NF-e.

Cor azul = cadastro de emitente.
Branco gelo = emissão NF-e.