Olá Pessoal, tudo bom?

Ao codificar um software, este está livre de erros? O que é realmente caracterizado como um erro? Qual é a importância dos testes de software? Essa e outras perguntas estaremos começando a responder nesse nosso texto de hoje.

Ciclo de Vida de um Projeto de Software

De acordo com PRESSMAN((PRESSMAN – http://books.google.com.br/books?id=bL7QZHtWvaUC&pg=PA67&dq=software+engineering+pressman+project+phases&hl=en&sa=X&ei=mJB_VNKqGoqqggSVxYKoDw&ved=0CB4Q6AEwAA#v=onepage&q=software%20engineering%20pressman%20project%20phases&f=false)) um Projeto de Software possui várias fases ao longo da sua vida. Essas fases podem utilizar diferentes ciclos de desenvolvimento ou se repetir inúmeras vezes enquanto um software for sendo utilizado. Quando passa a ser de uma tecnologia defasada ou cai em desuso, o software passa a ser descontinuado.

As seguintes figuras ilustram esse processo de desenvolvimento de um projeto de software

 

 

Em comum podem ser agrupadas determinadas fases:

• Requisitos e Análise
• Desenvolvimento
• Manutenção
• Aposentadoria

O foco principal desse texto é a parte de desenvolvimento e manutenção de um software pois são nestas fases que ocorrem os problemas comuns de um software.

Problemas Comuns em Software

Os problemas de um software podem ser divididos em duas grandes áreas, a área Negocial do Software e a área de Codificação e Infraestrutura do Software.

Os problemas relacionados a área Negocial do Software podem estar relacionados a dois fatores básicos:

• Necessidades negociais não foram atingidas, ou seja o software não opera de acordo com a necessidade do dia a dia do cliente.
• Os requisitos levantados pelos analistas são incipientes; Existem pontos que o software poderia atender melhor, ou automatizar ainda mais o processo de negócio do cliente.

Já na área de Codificação e Infraestrutura do Software, os problemas podem ser relacionados em cinco fatores básicos:

• Integração entre serviços possui uma péssima qualidade; O software utiliza outros sistemas para obter informações, sendo que estas não trazem as informações corretas ou estão sempre fora do ar.
• Dificuldade na manutenção; A codificação do software foi feita de forma a não utilizar reuso e padrões de projetos.
• Descoberta tardia de defeitos; Defeitos no software são descobertos apenas no momento da avaliação pelo cliente ou ainda após a implantação em “Produção” (Utilização do software pelo público em geral)
• Usabilidade não amigável; O software pode até realizar as regras de negócio acordadas com o cliente, mas não de forma clara e amigável, como, por exemplo, um número excessivo de passos para realizar alguma tarefa simples.
• Performance sofrível em produção; durante a homologação do software com o cliente, o sistema funcionou corretamente, mas após a implantação, principalmente durante horários de “rush” (grande número de usuários utilizando o software ao mesmo tempo) o software trava ou apresenta grande lentidão.

Dos sete fatores apresentados acima, quais em sua opinião podem ser evitados se uma boa fase de teste de software for realizada?

Apenas o fator de Dificuldade na Manutenção não pode ser melhorado com a fase de teste de software. O restante dos fatores podem ser minimizados através dos testes.

Testes de Software

Existem duas frases clássicas ao escrever sobre testes de software:

Testes não demonstram a ausência de erros, apenas a sua presença.

Edsger Dijkstra

 

 

Não se pode ‘inserir’ qualidade em um produto de software mal construído apenas com teste, mas também não é possível construir um produto com qualidade sem testes

Mauro Pèzze

Como pode ser interpretado um software sempre irá conter erros, mas pode ser que chegue a um ponto da vida do software em que todos os erros “possíveis” já ocorreram. Esse softwares possuem mais de 10, 15 anos sem novas funcionalidades, sendo estas “testadas” pelos usuários à exaustão durante o tempo. Isso na prática é praticamente impossível de ocorrer, visto que um software sempre terá novas funcionalidades e manutenções em sua existência.

A qualidade de um software é outro fator ponderante para a obtenção de menos erros durante a sua vida. Se um software foi construído com pouca qualidade, ou ainda sem qualidade, este pode ser um “ninho de vespas”, onde ao obter um erro e realizar sua correção, faz surgir novos erros e problemas.

Dessa forma testes de software possuem alguns princípios para a sua realização, os quais estão relatados abaixo:

• Testes de software tem por objetivo apresentar defeitos, onde estes devem ser agrupados para melhor resolução.
• Testes de software em sua natureza são dependentes de contexto, ou seja, necessitam de uma “história”, estar dentro de uma narrativa do software.
• Testes de software exaustivos e completos são impossíveis na prática, pois é muito improvável conseguir detalhar todas as formas de inserção de informações, pois existem várias telas e interações entre as informações. Isso não é valido em situações triviais, onde a funcionalidade é pequena e não interage com outras funcionalidades.
• Testes de software devem ser planejados e antecipados pela equipe de desenvolvimento
• Deve ser tomado cuidado com o paradoxo do “pesticida”:
  • Altere frequentemente os casos e as massas de testes, para evitar que os seus testes se tornem nulos sobre novos erros.
• Deve ser tomado cuidado com o mito da “ausência de erros”:
  • Todas as perspectivas do software devem ser analisadas a fim de encontrar o máximo possível de erros

Como existem diversas formas de funcionalidades e integrações entre estas, testar apenas 1 tipo de formato de funcionalidade pode não abranger todos os pontos do sistema. Assim há vários níveis de testes de um software os quais podem testar individualmente Objetivos e Artefatos Alvo ou Técnicas e Responsabilidades do Software; Esses níveis de teste são divididos basicamente em 4 áreas:

• Teste Unitário; Realiza os testes em pequenas áreas de um projeto. Normalmente é dividido por Casos de Uso. Podem ser automatizados. O Ator que realiza o teste é o desenvolvedor do Caso de Uso.
• Teste de Integração; Realiza os testes em agrupamentos de casos de uso ou integrações com outros softwares e bases de dados. O Ator que realiza o teste é um membro da equipe de teste.
• Teste de Sistema; Realiza os testes em todo o sistema ainda dentro da empresa de desenvolvimento. O Ator que realiza o teste é um membro da equipe de teste, mas o ideal é que várias pessoas realizem esse teste conjuntamente.
• Teste de Aceitação; Realiza os testes em todo o sistema mas dentro do ambiente de homologação, que deve uma copia fiel do ambiente de produção. O ator que realiza o teste deverá ser o cliente. Este teste serve como aval ao sistema, indicando que este foi aceito e será utilizado pelo cliente.

Para cada nível de teste existem formas de realizar o teste. Essas formas de testar um sistema podem ser aplicadas a qualquer nível de teste, mas as vezes não é recomendado para algum nível. Para todas as formas de teste é necessário que um analista de teste realize um planejamento do que irá testar, a partir da documentação do software. As mais conhecidas formas de teste estão descritas abaixo:

• Teste Funcional; Testa as funcionalidades de um software. Esses testes são baseados nos documentos de Casos de Uso e Processos de Negócio. Existem 2 formas básicas de realizar esse teste, o Black-Box e o White-Box. A diferença básica entre esses é que o white-box é permitido “ver” o código, então é muito utilizado para testes de Debug, já o black-box não é permitido “ver” o código, sendo apenas possível observar o Log do software.
• Teste Não-Funcional; Testa o comportamento do software perante condições adversas. Assim esses testes consistem em testes para momentos críticos do sistema, como horários de pico e funcionalidades que demandam muito processamento. Compreende os testes de Desempenho, Carga, Stress, Usabilidade, Manutenibilidade, Confiabilidade e Portabilidade.
• Teste Estrutural; Testa a abrangência dos testes, ou seja, verifica qual é a “área de cobertura” dos testes de software. Pode atingir 100%, mas normalmente é condicionado para as áreas mais críticas do sistema. Esse tipo de teste é muito utilizado durante o Teste de Integração
• Teste de Regressão; Testes são processos repetitivos, custosos. Essa forma de teste é utilizada para que, ao fim do desenvolvimento de uma funcionalidade, seja realizado testes em todos as funcionalidades já codificadas no sistema até o momento. Assim essa forma de teste deve ser constantemente realizada, mas isso é impossível de ser feito por uma equipe de teste, então é altamente recomendável que este forma de teste seja automatizada, podendo ser aplicado em vários momentos do desenvolvimento.

Ciclo de Vida de um Erro

Sejam ou não realizados testes em software uma coisa é certa, erros irão aparecer. Dessa forma é necessário estar preparado para enfrentá-los! Uma maneira de formalizar o tratamento de um erro, tornando mais profissional a forma de tratá-lo, é através de um diagrama de estados. Um diagrama o qual considero bem completo é o do Bugzilla ((Bugzilla – http://www.bugzilla.org/)), que é uma ferramenta para cadastro e manutenção de erros de um software. Abaixo é mostrado esse diagrama de estados:

Um erro pode entrar dentro do processo de correção através de 2 estados, CONFIRMED e UNCONFIRMED.

Um erro que está no estado UNCONFIRMED pode duas ações básicas, ou é confirmado que está presente no software, neste caso indo para o estado CONFIRMED, ou ele é não está presente no software, indo para o estado RESOLVED, quando o erro é inválido (INVALID).

Ao chegar ao estado CONFIRMED, o erro pode ser atribuído a um desenvolvedor, enviando o erro ao estado IN_PROGRESS ou pode ser prontamente resolvido, indo para o estado RESOLVED, esse caso normalmente é quando o erro é duplicado (DUPLICATE) ou já foi corrigido (FIXED).

Durante a permanência no estado IN_PROGRESS, o desenvolvedor pode parar de trabalhar com o erro, voltando este ao estado CONFIRMED ou corrigí-lo, levando o erro ao estado RESOLVED.

No estado RESOLVED, quem assume o controle do erro é a equipe de testes, a qual realiza testes sobre o erro, verificando se a correção está correta, levando o erro ao estado VERIFIED ou voltando ao estado CONFIRMED caso esteja incorreta a correção. Caso um bug volte a ocorrer no futuro, ele voltará ao estado UNCONFIRMED começando novamente o processo.

Caso você conheça um pouco de Diagrama de Estados irá verificar que está faltando um ponto de finalização ou EndPoint. O diagrama foi construído dessa forma para demonstrar que um erro não é finalizado, mas sim está sob um estado de hibernação. Pode ser que ao alterar um código, criar uma nova funcionalidade, um desenvolvedor altere pontos que irão “acordar” esse erro. Assim é válido o conceito aplicado sobre o diagrama de estados da ferramenta Bugzilla.

Caso você adote uma postura similar a esse diagrama de estados para corrigir seus erros no projeto, você estará contribuindo para a boa operação do seu software. 🙂

finnaly

Existem diversas formas de teste e ferramentas que podem ser utilizadas para realizar testes em um software. Essa gama de ferramentas e recursos serão apresentados ao longo do tempo no site. O importante é conhecer e saber que existem diversas ferramentas que podem auxiliar na produtividade do desenvolvimento de um software no dia a dia de uma empresa ou acadêmica.

Duvidas e comentários favor deixar no comentário abaixo, a sua dúvida e questionamento é muito importante para a evolução do site e pontos no texto que podem não ter ficado compreensível. O seu feedback é muito importante!

É isso nos vemos no próximo post!

Até lá!