processo de testes: abordagem de projeto de testes test...

Revista Pensar Tecnologia, v. 4, n. 1, jan. 2015

Processo de Testes: Abordagem de Projeto de Testes

Test Process: Test Project Approach

Procedimiento de Prueba: Método de Proyectos de Prueba

Thiago José Corrêa Piqueiro1

Augusto Nogueira Zadra2

Resumo: Este artigo apresenta o processo de teste de software e mostra as principais característicasdo processo. A importância do tema se deve ao fato de que o processo de teste de software aumentaa qualidade do produto final sendo desenvolvido. O principal objetivo do estudo é apresentar oprocesso de teste e o uso deste como um projeto para a melhoria da qualidade dos projetos dedesenvolvimento. Trata-se de uma pesquisa exploratória com base em pesquisa bibliográfica sobreteste de software.Palavras Chave: projeto de teste, plano de teste, qualidade de software, teste de software

Abstract: This article presents the software testing process showing its main features and anapproach for the test process as a project, given the fact that the software test process enhances thequality of the final product being developed. The main objective of the study is to present the testprocess and its use as a project to enhance the development projects quality. The kind of research forthis article is exploratory and it is based on bibliographic research about software testing.Keywords: test project, test plan, software quality, software test

Resumen: En este artículo se presenta el proceso de pruebas de software que muestra susprincipales características y un enfoque para el proceso de la prueba como un proyecto, dado elhecho de que el proceso de pruebas de software mejora el producto final está desarrollando. Elobjetivo principal es dar a conocer el proceso de prueba y su uso como un proyecto para mejorar lacalidad de los proyectos de desarrollo. El tipo de investigación para este artículo es exploratoria, y sebasa en la investigación bibliográfica acerca de las pruebas de software.Palabras clave: proyecto de prueba, plan de pruebas, la calidad del software, pruebas de software

1 INTRODUÇÃO

Este artigo tem como tema o processo de teste de software e a necessidade

de controlarmos o processo de teste em um projeto dependente, mas apartado do

projeto de desenvolvimento de software. O processo de teste é inerente ao processo

de desenvolvimento, o qual pode ser visto como um projeto por si só, não sendo

apenas uma atividade do processo de desenvolvimento que pode ser descartada.

1Graduando em Sistemas de Informação na Faculdade Infórium de [email protected] Graduado em Ciência da Computação, Especialista em Engenharia de Software, Mestrando emTecnologia da Informação


Delimitou-se o tema deste estudo às principais características do processo de

teste e a visão do processo de teste como um projeto.

O objetivo geral é apresentar as principais características do processo de

testes de software e como tal processo pode influenciar na melhoria do processo de

desenvolvimento se visto como um projeto próprio. São objetivos específicos deste

artigo: apresentar as principais características do processo de teste, tais como o que

é e como utilizar; propor um exemplo simplificado do documento de plano de teste

para ser utilizado como base em projetos de teste; especificar quais são os tipos de

técnicas de teste mais comuns, tais como: teste unitário, teste de integração, teste

de sistema, teste de performance e teste de aceitação; abordar sucintamente os dois

tipos mais conhecidos de caso de teste, denominados como Caixa-branca e Caixa-

preta.

Aborda-se neste artigo que a utilização de um processo de teste adequado

pode trazer benefícios para todos os tipos de empresa, não só as de porte médio e

grande, mas também para as empresas de pequeno e micro porte, pois como

mostra Kaner et al (1999), todo software entregue possui um maior custo ao

apresentar erros que não foram corrigidos em desenvolvimento e têm que ser

tratados em produção, independentemente do tamanho da companhia que o

desenvolveu.

Justifica-se esta pesquisa tendo em vista o pouco incentivo existente quanto à

utilização de testes em pequenas e micro empresas devido ao baixo orçamento que

tais empresas costumam possuir. A falta de testes de software em tais empresas

acarreta mais prejuízo que benefícios ao não serem utilizados.

Desta forma, a pergunta norteadora do estudo é no sentido de verificar os

benefícios que o processo de teste de software pode trazer para o processo de

desenvolvimento de software nas empresas.

Para o entendimento deste tema, este trabalho foi dividido em cinco seções –

A seção 1, esta introdução, é indicativa do estudo; a seção 2 apresenta a

abordagem teórica sobre o processo de teste; a seção 3 caracteriza o processo de

teste através da visão deste como um projeto; a seção 4 apresenta a discussão


teórica sobre o processo e o projeto de teste; e a seção 5 tece as conclusões

obtidas sobre o processo de teste e seu uso como um projeto.

2 ABORDAGEM TEÓRICA SOBRE O PROCESSO DE TESTE DE SOFTWARE

Nesta seção apresentam-se as diversas definições do processo de teste e

seu aprimoramento ao longo do tempo.

De acordo com Pressman (2001), o teste de software pode ser visto como

uma atividade do processo de desenvolvimento de software que serve para garantir

ao cliente que o software sendo entregue terá o mínimo de erros possíveis e

atenderá aos requisitos especificados no escopo do projeto. Já Rios e Moreira

(2013, p. 10), apresentam definições diversas do que é o teste de software em si:

Quadro 1: Definições para teste de software:

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

Em Myers (2004), também são citadas algumas definições genéricas do

processo de teste, o qual as coloca como definições errôneas, pois ao definir o

processo de teste de forma genérica, é removida a importância do processo como

um todo, trazendo assim uma visão limitada do responsável pela execução dos

testes de software e ocasionando possíveis erros que podem ser evitados caso o

testador tenha uma visão mais detalhada do que é o processo de teste em seus

conceitos. De acordo com Myers (2004):

Uma das causas primárias de um teste de sistema ser improdutivo é o fato

de que a maior parte dos programadores começa com uma falsa definição

do termo. Eles podem dizer:

‘Testar é o processo de demonstrar que erros não estão presentes’.

ou


‘O propósito de testar é mostrar que um programa performa suas funções

definidas corretamente’.

ou

‘Testar é o processo de estabelecer a confiança sobre o que um programa

faz o que ele supostamente deveria fazer’. (MYERS, 2004, p. 10, tradução

própria)

Ainda em Myers (2004), complementando a definição do processo de teste, é

vista a necessidade de uma equipe de teste, onde é constatado que o teste de

software não é uma atividade invariável, mas uma técnica que requer planejamento

e deve ser ajustada de acordo com a necessidade do projeto. Todo usuário de uma

aplicação é um testador (teste de aceitação), mas para obter eficiência na execução

do processo de teste, deve haver entendimento e habilidade por parte do

responsável sobre suas atividades específicas durante o processo de teste (a qual

consta na documentação) e sobre o que o teste deve resultar ao executar

determinada tarefa (compreensão dos requisitos por parte do testador), por isso a

necessidade de pessoas qualificadas para realizar os testes, não sendo qualquer um

apto a realizar os testes de um sistema com eficiência sem estudo prévio do

processo de teste.

Em detrimento destas suposições, Myers (2004) enfatiza que o processo de

teste não deve ser definido em apenas uma disposição simplificada, pois este é um

processo complexo que deve ser visto de forma mais abrangente. Ele também diz

que o motivo de não utilizar uma vaga definição para conceituar um processo com

tamanha importância é por causa da perda de confiabilidade em quem o testa, pois

não estará demonstrando o foco necessário no processo. Myers (2004) afirma que

se deve pensar no sistema de software como passivo de falhas, sendo que tais erros

devem ser removidos enquanto houver tempo para testar antes da entrega do

sistema e o teste deve ser feito assumindo que há erros no sistema de software com

uma ou várias partes que não funcionam no sistema sendo testado.

Outra visão do processo de teste de software, apresentada em Rios e Moreira

(2013), é a visão do processo de teste de software como um processo próprio e

externo ao processo de desenvolvimento, com suas respectivas atividades assim

como o processo de desenvolvimento de software, possuindo um planejamento e


preparação durante sua fase de existência, a qual é composta de procedimentos

iniciais, especificação, execução e entrega. Para Myers (2004), o teste também é um

processo, mas definido de forma diferente:

O teste de software é um processo, ou uma série de processos,

desenvolvido para assegurar que o código computacional faz o que foi

desenvolvido para fazer e que não faz nada que não tenha sido

intencionado. O software deve ser previsível e consistente, não

apresentando comportamentos inesperados para o usuário final. (MYERS,

2004, p. 8, tradução própria)

O processo de teste é composto por várias técnicas, as quais são aplicadas

ao processo de teste para obtenção de eficiência na eliminação de erros do sistema

sendo testado. Dentre essas técnicas podem ser citadas as mais conhecidas e

possivelmente vistas como essenciais: teste unitário, teste de integração, teste de

sistema, teste de aceitação e teste de performance. Cada técnica de teste traz um

benefício específico na construção de um sistema, eliminando erros e aumentando a

qualidade do sistema sendo testado. Essas técnicas são muito bem apresentadas

por Pressman (2001) e são discutidas a seguir a partir da visão deste:

a. Teste Unitário

Trata-se do teste referente à micro parte do sistema, testando a menor

unidade lógica possível do sistema, como métodos e objetos. Os testes unitários são

realizados sobre a menor unidade do sistema de software, sendo tal unidade

definida como parte/componente ou módulo do sistema. Neste tipo de teste, é

realizado o teste dos caminhos que serão executados pelo sistema, sendo verificado

também se há coerência entre os dados de entrada e saída de cada módulo

especificado e se há erros de lógica dentro dos módulos do sistema, pode ser visto

como um teste de código de forma atômica.

b. Teste de Integração


Trata-se do teste das partes (módulos) do sistema ao serem unidas. Ao criar

os componentes que constituirão o sistema, estes são testados ao serem acoplados

quando é utilizado este tipo de técnica. No teste de integração, é feito o teste entre

as interfaces do sistema para verificar como elas interagem umas com as outras.

Neste tipo de teste é feita a união das unidades do sistema para verificar se são

compatíveis e não apresentam erros ao serem associadas ou sua associação

interfere ou prejudica outra parte do sistema que depende da parte sendo unificada.

c. Integração Descendente

Refere-se ao tipo de técnica de integração que parte do módulo central do

sistema e segue acoplando as partes secundárias do sistema a este módulo central.

Possui a desvantagem de caso o módulo principal dependa de um módulo

secundário, atrasa a atividade de teste do módulo primário enquanto não terminar a

construção do módulo secundário. O teste de integração descendente é utilizado

caso os módulos a serem acoplados não possuam tanta dependência dos módulos

que serão desenvolvidos após eles, ou quando é possível seu desenvolvimento de

forma paralela à outra parte do sistema que também não dependa das partes

principais do sistema.

d. Integração Ascendente

Refere-se ao tipo de técnica de teste de integração em que são construídos

os módulos secundários de forma separada e os acopla ao término de cada módulo.

Tem a desvantagem de que ao criar um módulo secundário é necessária a criação

de uma interface própria para testar este módulo separadamente. O teste de

integração ascendente pode ser utilizado caso os módulos secundários possuam

interfaces simples de serem desenvolvidas, ou sua integração às outras partes do

sistema possua baixa probabilidade de erros ao ser acoplado ao restante do

sistema, trazendo a possibilidade da não criação de interfaces próprias para cada

módulo.


e. Teste de Sistema

Teste de sistema refere-se ao teste do sistema como um todo, é feito após a

construção do sistema estar estruturalmente terminada, serve para verificar se todas

as funções necessárias para o funcionamento do sistema serão executadas

corretamente em conjunto. É um teste geral, que engloba todas as partes funcionais

do sistema, verifica se o sistema executa suas funções como definidas no escopo e

também não apresenta erros inesperados ao serem utilizadas várias de suas

funções simultaneamente.

f. Teste de Performance

O teste de performance serve para verificar se o sistema, além de estar

funcionando, executa suas funcionalidades em um tempo consideravelmente

satisfatório. É referente ao tempo de execução não só do sistema como um todo,

mas em suas partes individuais. Por exemplo: Um sistema de pagamentos executa

os cálculos dos pagamentos de forma eficiente, porém é lento ao transacionar os

dados calculados para algum outro sistema responsável por sua impressão, há erro

de performance neste sistema, pois parte dele não atende de forma satisfatória um

tempo de execução eficiente.

g. Teste de Aceitação

No modelo do documento de implantação da Melhoria do Processo de Teste

Brasileiro (MPT .Br), é apresentada a definição do teste de aceitação, o qual pode

ser entendido como verificação e cumprimento dos requisitos. É um aceite do

cliente, mostrando que o sistema atende às necessidades iniciais apresentadas por

ele, assegurando que o que foi planejado nos requisitos é o que será entregue ao

cliente e que suas expectativas serão atendidas.

Ainda no modelo de Melhoria do Processo de Teste Brasileiro (MPT .Br), é

visto que este tipo de teste pode ser dividido em níveis para que ao realizar os teste

não haja insatisfação do cliente em determinada parte do produto que depende de

outras partes. Este tipo de teste é melhor aplicado de forma gradual, sendo feita a


construção e entrega em módulos, permitindo que o cliente teste partes do sistema e

caso reprove alguma, não traga grandes atrasos à construção do sistema de forma

geral, pois a parte com a qual o cliente está insatisfeito é conhecida e pode ser

alterada antes da entrega do sistema completo. Dessa forma é possível obter

comentários em retorno (feedback) para a melhoria do sistema sendo desenvolvido

mais cedo o possível durante o processo de desenvolvimento, sabendo assim se o

que o cliente propôs como requisito foi compreendido e construído de acordo com o

que ele requisitou.

2.1 Aplicação das Técnicas de Teste em um Modelo Real

Como é visto em Rios e Moreira (2013), um modelo conhecido e que

demonstra a utilização das técnicas de teste é o modelo em V, o qual é explicado a

seguir.

Como pode ser visto na figura 1, a qual é apresentada por Rios e Moreira

(2013), durante a modelagem dos requisitos começa o planejamento dos testes de

aceitação que são responsáveis por verificar se há erros de lógica na elaboração

dos requisitos e iniciam-se os testes de sistema. Durante o projeto da arquitetura

são definidos quais comportamentos são esperados ao utilizar o sistema e o que

será necessário testar de acordo com a visão do usuário final do sistema. Durante o

projeto dos componentes (ou especificação das partes do sistema) e ao final do

projeto da arquitetura, são definidos quais casos de teste serão utilizados e como se

relacionam as partes do sistema para realização dos testes de integração. Ao final

do projeto dos componentes e durante a parte de codificação são definidos os testes

unitários que devem ser construídos e iniciando do ponto que une as duas

extremidades do “Vê” na figura começam a serem executados os testes planejados

durante a construção do sistema debaixo para cima, seguindo a ordem: teste

unitário, teste de integração, teste de sistema e teste de aceitação. Podemos então

constatar a partir da figura que o processo de teste também é paralelo ao processo

de desenvolvimento de acordo com a definição do modelo em V.


Figura 1: Modelo em V demonstrando a simultaneidade entre o processo de desenvolvimento

e o processo de teste de software:

Fonte: http://arquivo.devmedia.com.br/artigos/Higor_Medeiros/modelo-cascata/figura2.png

3 PROJETO DE TESTE

Como constatado em Rios e Moreira (2013), uma das formas de conseguir

ampliar a visão do desenvolvedor de modo claro sobre a importância do processo de

teste é apresentando-o como um processo externo ao processo de desenvolvimento

de software, assim trazendo ciência da necessidade que o processo de teste possui

em relação ao processo de desenvolvimento. Através da criação de um projeto de

teste externo ao projeto de desenvolvimento de software, isso se torna evidente,

pois são separadas as funções de cada processo e executadas dentro de um projeto

próprio.

Em um projeto de teste são definidas fases, que são parecidas com as fases

de um projeto de desenvolvimento, sendo elas: Procedimentos Iniciais,

Planejamento, Preparação, Especificação, Execução e Entrega.


Baseado no modelo apresentado por Rios e Moreira (2013), estas etapas

podem ser divididas e descritas da seguinte forma:

Procedimentos Iniciais (Planejamento e Especificação) – Após coleta dos

requisitos e definição do que o sistema a ser construído deverá fazer ou

deverá ter como funcionalidade. São criadas as estratégias de testes viáveis

a serem utilizadas ao testar o sistema que devem ser definidas através de um

plano (ou planos) de teste, os quais definirão os casos de teste e técnicas a

serem utilizadas no processo de teste.

Especificação – Criação dos roteiros e casos de teste definidos no(s) plano(s)

de teste a serem aplicados ao sistema que será desenvolvido. Trata-se dos

casos de teste baseados nos requisitos do sistema coletados junto ao cliente.

Execução – Criação do código propriamente dito para realização dos testes

no sistema junto com a execução dos procedimentos de teste definidos no(s)

plano(s) de teste(s).

Planejamento – Ocorre durante todo o processo de desenvolvimento do

projeto de teste e é a etapa responsável por verificar a consistência entre os

testes sendo criados e os requisitos definidos no escopo do sistema e calcular

os prazos para cada fase do processo de teste para utilizar os casos de teste

ou as técnicas que possuam maior necessidade caso não haja um prazo que

permita a utilização de todas as atividades definidas no(s) plano(s) de teste.

Preparação – Ocorre também durante todo o processo de desenvolvimento

do projeto e é a fase responsável por configurar o ambiente, verificar a

capacidade dos integrantes de realizar o que foi definido no(s) plano(s) de

teste para saber se é necessário alocar mais funcionários à equipe de teste.

Entrega (Documentação) – Nesta etapa é entregue o sistema desenvolvido

após realizar os testes e corrigir todos os erros possíveis durante o prazo de

entrega do projeto. Nesta etapa também é finalizada a documentação dos

procedimentos realizados durante a execução dos testes para que quando for


necessário realizar a manutenção do sistema haja um documento com os

procedimentos utilizados para o teste do sistema, onde possam ser

consultadas quais ações realizar para verificar se as funcionalidades do

sistema estão atendendo a seus requisitos e definir também se determinada

requisição de manutenibilidade é um erro de sistema ou uma requisição de

melhoria.

Segundo Rios e Moreira (2013), essa abordagem das fases de um projeto de

teste é baseada no Modelo em V, apresentado no capítulo anterior, sendo o modelo

em V uma abstração para o projeto de teste focado nas técnicas do processo de

teste, contendo o que será feito no projeto de teste, enquanto que as fases do

projeto de teste definem o como será feito. Através desse modelo é mostrado que os

testes podem ser elaborados e executados de forma paralela ao projeto de

desenvolvimento, não necessariamente após a construção de todo o sistema, com

cada uma das fases do projeto de teste sendo aplicadas durante uma fase

específica do processo de desenvolvimento. Tais fases do projeto de teste mostram

como será estruturado o processo de teste como um projeto.

3.1 Plano de Teste

Em Rios e Moreira (2013) e em Sommerville (2007) é visto que o principal

documento do projeto de teste é o documento de Plano de Teste, junto com o Guia

Operacional de Testes (GOT), o qual contém os requisitos de teste coletados

durante a fase inicial do projeto. Os documentos com maior relação ao Plano de

Teste são: o documento de Estratégia de Testes, que contém quais tipos de testes

serão realizados e o documento de Roteiros de Testes, o qual descreve como serão

realizados e organizados os testes. O Plano de Teste estrutura e organiza as

informações referentes ao processo de teste durante todo o projeto, facilitando

assim o planejamento do Projeto de Teste. Ainda em Rios e Moreira (2013), no

Plano de Teste, temos a parte lógica do processo de testes, documento onde será

definida a arquitetura do sistema, as ferramentas que serão utilizadas para sua

construção, responsáveis pela execução dos testes, requisitos necessários para a


execução do testes, como ambiente e alocação de funcionários tanto da empresa

provedora do sistema quanto da empresa que utilizará o sistema. Esse documento

está diretamente relacionado ao documento de Estratégia de Teste, o qual descreve

como será executado o que está contido no documento de Plano de Teste.

Também pode ser visto em Sommerville (2007) uma descrição sobre o plano

de teste e como este pode ser utilizado dentro do processo de teste, tal documento é

descrito como segue:

Planos de teste não são documentos estáticos; evoluem durante o processo

de desenvolvimento. Os planos de teste mudam devido a atrasos em outros

estágios do processo de desenvolvimento. Se parte de um sistema está

incompleta, o sistema como um todo não pode ser testado. Você tem,

portanto, de atualizar o plano de teste para realocar os testadores para a

alguma outra atividade e trazê-los de volta quando o software estiver

disponível novamente. (SOMMERVILLE, 2007, p. 344)

Apresenta-se no apêndice deste artigo um plano de teste que pode ser

utilizado como referência ao construir um Plano de Teste, o qual foi criado de acordo

com as especificações apresentadas por Rios e Moreira (2013) com algumas

adaptações. Como citado anteriormente, não é o único documento necessário para

a criação de um projeto de teste, porém é o ponto de partida na construção do

projeto de teste e pode ser utilizado como base e incentivo para o início da

implantação do processo de teste em qualquer organização que pretenda começar a

utilizar o processo de teste junto ao seu processo de desenvolvimento.

3.2 Casos de teste

As técnicas de software, citadas anteriormente, estão divididas em dois

tipos de casos de testes, que comportam tais técnicas. Cada um desses

casos de teste é aplicado ao projeto de teste de acordo com a necessidade

do projeto, sendo estes casos de teste conhecidos como: testes Caixa-preta e

testes Caixa-branca. Baseado no que é apresentado por Pressman (2001),

eis o que pode ser entendido sobre tais casos de teste e quando utilizá-los:


a. Teste Caixa-branca

Trata-se do caso de teste em que o código é testado e analisado pelos

desenvolvedores, verifica-se se o código atende aos padrões da empresa e se não

há erros de codificação, conforme apresenta Pressman (2001). O teste Caixa-branca

também é conhecido como teste Caixa-de-vidro devido à sua transparência para

quem realiza o teste, tendo a visão de todo o funcionamento lógico do sistema

enquanto é executado. Neste tipo de caso de teste o responsável pela execução dos

testes pode verificar todos os caminhos que são percorridos pelos dados dentro do

sistema e assim certificar-se se há alguma irregularidade quanto ao fluxo dos dados

dentro do sistema. No caso de teste Caixa-branca também é verificada a estrutura

lógica dos módulos do sistema e se estes módulos respeitam o limite para eles

programado. Este tipo de caso de teste pode ser visto de forma geral como teste de

código, pois todos os testes realizados são referentes ao código do sistema.

b. Teste Caixa-preta

Como visto também em Pressman (2001), este caso de teste é referente ao

tipo de caso em que não há visão do código do sistema, o teste é aplicado sobre as

funcionalidades do sistema, ignorando a forma como o sistema foi escrito e dando

ênfase à forma como ele funciona. O teste Caixa-preta é responsável pela

verificação do comportamento do sistema e se este se comporta como esperado

pelo cliente, não apresentando nenhuma anormalidade ao ser utilizado. Chama-se

Caixa-preta por ser feito sem focar no código, apenas nas funcionalidades. O

testador responsável por realizar tal tipo de teste interpreta o papel do usuário final,

utilizando o programa à espera de alguma possível anormalidade ao executá-lo.

Este tipo de caso de teste pode ser visto de forma geral como caso de teste

funcional, pois todos os testes realizados são referentes às funcionalidades do

sistema.

A partir das definições dos casos de teste (que podem ser entendidos

também como abordagens estratégicas de teste de software), podemos observar

baseados na visão de Pressman (2001), que cada tipo de abordagem de caso de


teste possui sua devida importância dentro do processo de teste de software,

podendo cada uma ser utilizada em determinada etapa do projeto de teste de

software de acordo com a necessidade e os benefícios que pode proporcionar ao

projeto.

4 DISCUSSÃO TEÓRICA DO PROJETO DE TESTE NO PROCESSO DE TESTE

De acordo com o modelo tradicional de desenvolvimento de software e

baseado na visão de Kaner et al (1999), pode ser entendido que o software passa

por um ciclo de estágios de desenvolvimento, cada qual é necessário para obtenção

de um sistema com qualidade. Dentre essas fases, está a fase de testes (validação),

que apesar de possuir um gasto considerável durante o processo de

desenvolvimento, traz economia posterior tendo em vista que os erros foram

suprimidos durante a fase de criação do software, tornando o aparecimento de erros

menos constante quando o sistema entra em produção, estado do sistema no qual o

custo para correção passa a possuir um gasto muito superior. Kaner et al (1999)

também apresentam que esses estágios, os quais podem ser considerados como

base da engenharia de software, são conhecidos como: planejamento,

criação/desenvolvimento, validação/teste, entrega e manutenção, que formam o

ciclo de vida do processo de desenvolvimento de software e dentre os quais deve

haver a atividade de teste ao menos na fase de validação do sistema.

Este tipo de abordagem não é novidade, desde o modelo em cascata é

utilizada a abordagem de desenvolvimento dividida em fases (estágios), onde cada

fase depende da anterior para que esta ocorra, porém, em um projeto real, isso só é

possível em teoria, pois ao executar um projeto deve haver incrementabilidade

(progressão passo a passo de forma evolutiva) e paralelidade (várias atividades

ocorrendo ao mesmo tempo), devido aos curtos prazos comumente orçados no

cenário de desenvolvimento de software atual. Ainda em Kaner et al (1999), é

mostrada a inserção do teste dentro da sequência de fases do processo de

desenvolvimento, o qual é mostrado como tendo as seguintes fases: planejamento;

desenvolvimento; codificação e documentação; teste e correção; entrega,

manutenção e melhoria. Como visto, após a fase de codificação e documentação é


inserida a fase de teste, neste caso sendo o teste uma atividade do processo de

desenvolvimento, não um processo. Apesar de não ser mostrado como um

processo, o teste continua sendo importante e visto como uma fase indispensável do

processo de desenvolvimento mesmo neste tipo de abordagem.

Sobre a importância da atividade de teste, realça Kaner et al (1999) que o

objetivo de testar é encontrar erros no programa, não provar que o programa não

possui erros, o núcleo da atividade de teste de software é encontrar problemas no

sistema sendo desenvolvido, portanto, deve haver vontade por parte do testador em

encontrar tais erros, pois quanto mais erros o testador é capaz de encontrar em um

sistema, mais eficiente estará sendo o seu trabalho e isto independe da abordagem

de teste aplicada ao processo de desenvolvimento (atividade do processo de

desenvolvimento ou um processo paralelo ao processo de desenvolvimento).

Em Pressman (2001), esta visão sobre o objetivo de testar é convergente à

visão de Kaner et al (1999), além de poder ser vista como mais completa, pois cita

que testar é encontrar erros ao invés de tentar provar que o sistema não contém

erros, sendo tal atitude tomada durante todas as fases do processo de teste e

adiciona também que a atividade de teste não é uma tarefa plural sobre todo o

processo de teste, mas uma tarefa singular que deve ser aplicada em cada parte do

sistema sendo criado. Ele cita que o teste é realizado através de técnicas como

testes unitários, de integração, validação (aceitação) e de sistema, que realizam de

forma geral e sistemática a validação do software sendo desenvolvido, facilitando o

desenvolvimento de cada teste em cada fase do processo de teste.

Essa colocação sobre o teste faz parecer que o testador é um “vilão” tentando

“quebrar” o programa, mas pelo contrário, encontrar erros no sistema mostra que

está havendo um bom trabalho em equipe, evitando que o erro chegue ao cliente

(sistema em produção), como visto em Pressman (2001) que apresenta o processo

de busca de erros como uma arte, colocando o testador como o escultor e a procura

pelos erros como a lapidação de uma escultura, sendo que a cada erro encontrado

completa-se uma parte da obra final (o software). Tal atividade de busca de erros

deve ser compartilhada entre testadores, pois erros que um testador não foi capaz

de encontrar podem ser encontrados por outro, tendo em vista o fato de que

pessoas têm visões diferentes das atividades de teste ao executá-las.


Já na visão do processo de teste como um projeto, é mostrado por Rios e

Moreira (2013) que os principais documentos do processo de teste são: O Guia

Operacional de Testes, O documento de Estratégia de Testes, O documento de

Plano de Testes, O documento de Roteiro de Testes, Os documentos de Casos de

Testes e o documento com as definições e descrições dos Scripts de Teste. Esses

documentos podem ser descritos resumidamente da seguinte forma:

Guia Operacional de Testes – Documento opcional que pode ser utilizado como

um acordo de execução do projeto de testes para que se possa dar início ao

projeto.

Estratégia de Testes – Contém uma visão geral do projeto de testes sobre quais

estratégias serão utilizadas para a execução dos testes.

Plano de Testes – Principal documento para o projeto de teste, pois contém sua

estrutura e trabalha em concordância com o documento de Estratégia de Testes,

responsável pela definição lógica do projeto.

Roteiro de Testes – Documento responsável por mostrar os roteiros de testes a

serem executados, obrigatoriamente deve conter um cronograma sobre a

execução dos roteiros.

Casos de Testes – Os casos de teste são formas de testar o sistema e podem

ser vistos como tipos de teste Caixa-branca e Caixa-preta, cada qual deve estar

identificado no documento de Plano de testes para o controle de execução dos

testes.

Scripts de teste – Parte referente à automatização da execução dos testes caso o

projeto utilize testes automatizados. Contém casos de testes a serem executados

automaticamente pelo sistema.

Esses documentos são todos os documentos necessários para a implantação

do projeto de teste apresentados por Rios e Moreira (2013). São utilizados conforme

a possibilidade de adoção da empresa que deseja implantar o processo de testes

junto ao seu processo de desenvolvimento, pois para obter benefício no uso do

projeto de testes não é necessário o uso do processo de teste por completo em

razão de sua flexibilidade. Caso haja interesse em certificar-se através da

organização de Melhoria do Processo de Testes Brasileiro (Mpt .Br), deve haver um


estudo aprofundado por parte da empresa sobre quais documentos são necessários

ter domínio para obter tal certificação.

Para a criação de um modelo de projeto de testes há a possibilidade de

consulta online de documentos próprios para isto. Através da união de várias

empresas interessadas na melhoria do processo de desenvolvimento e também da

utilização de testes, foi criada uma organização própria para certificação relacionada

ao processo de testes no cenário brasileiro. Tal entidade também proporciona a

possibilidade de certificação tanto de desenvolvedores quanto de processos

empresariais. De acordo com o site sobre Melhoria do Processo de Testes Brasileiro

(MPT .Br, 2014):

O MPT.Br é constantemente aperfeiçoado tomando como referência as

versões anteriores e suas aplicações nas empresas, assim como

contribuições da comunidade de teste de software brasileira. Os pontos

críticos do modelo, a base referencial em teste e a evolução da engenharia

de software são sempre levados em consideração para consolidação e

implementação da melhoria contínua do modelo (MPT.Br, 2014).

O processo de teste também pode ser terceirizado, trazendo a vantagem ao

processo de desenvolvimento ao evitar que seja inserida em um processo já

estabelecido, uma atividade sobre a qual os membros da equipe de

desenvolvimento de determinada empresa possam não possuir o conhecimento

necessário. Como é enfatizado por Myers (2004):

Enfatizamos que uma organização deveria evitar tentar testar seus próprios

programas. A razão é que a organização responsável por desenvolver um

programa tem dificuldade em testar objetivamente o mesmo programa.

A organização de teste deveria ser tão logo removida quanto possível, em

termos de estrutura da companhia, da organização de desenvolvimento. De

fato, é desejável que a organização de teste não seja parte da mesma

companhia, porque se ela for, ela ainda é influenciada pelo mesmas

pressões de gerenciamento que influenciam a organização de

desenvolvimento. (MYERS, 2004, The art of testing, p. 111, tradução

própria)


Para isso, já existem empresas especializadas no ramo de consultoria e

treinamento de equipes de teste, as quais atendem empresas de todos os portes.

Tal tipo de contratação pode trazer conhecimento para a empresa contratante e

também ampliar a visão da empresa sobre o teste de software, devido ao processo

ser realizado por um responsável externo, como também apresenta Myers (2004).

Uma forma de evitar esse conflito é contratar uma companhia separada

para o teste de software. Esta é uma boa ideia, se a companhia que

desenvolveu o sistema e o usará desenvolveu o sistema ou se um

desenvolvedor externo produziu o sistema. As vantagens notadas

normalmente são: aumento da motivação no processo de teste, uma

competição saudável com a organização de desenvolvimento, remoção do

processo de teste do gerenciamento de controle da organização de

desenvolvimento, e a vantagem de conhecimento especializado que a

agência de teste independente traz como solução para o problema.

(MYERS, 2004, The art of testing, p. 111, tradução própria)

5 CONCLUSÃO

A atividade de teste de software aplicada de forma externa ao processo de

desenvolvimento de software passa a ter vida como um projeto a ser desenvolvido

dentro das especificações do processo de teste. Vimos que a vantagem em utilizar

um projeto próprio para o teste de software é a possibilidade de separação entre o

processo de teste de software e o processo de desenvolvimento de software,

tornando assim mais clara a visão da função de cada processo e enfatizando a

importância que o processo de teste possui, podendo influenciar muito na qualidade

final de um software sendo desenvolvido.

Apesar de parecer que haverá um maior gasto de tempo ao utilizar um projeto

próprio para realizar os testes de um sistema, essa abordagem traz uma maior

liberdade em relação ao quanto do sistema deverá ser testado e afasta o receio dos

desenvolvedores em inserir dentro de seu processo de desenvolvimento de software

já estabelecido, uma atividade completamente nova sobre a qual tais

desenvolvedores talvez não tenham conhecimento adequado para exercê-la.


Também permite que seja terceirizado o processo de teste, recebendo consultoria

para treinamento de uma equipe a ser contratada ou treinando uma equipe própria

para a execução do projeto de teste de software.

Dessa forma, o processo de teste pode ser implementado gradualmente,

criando-se projetos de teste que foquem nas áreas em que a equipe de

desenvolvimento possua menos eficiência ou maiores dificuldades para aumentar a

qualidade, seja ao especificar o sistema, codificá-lo, validá-lo, verificá-lo ou ao

acoplar a interface à parte lógica do sistema. Pode-se então aplicar as estratégias

Caixa-branca ou Caixa-preta em ordem de necessidade, seguidas de suas

respectivas técnicas de teste de software. Além das técnicas de teste de software

citadas, há várias outras que podem ser utilizadas para a melhoria do processo de

teste, cada qual sendo aplicada de acordo com o custo-benefício obtido pela

empresa.

Podem ser obtidas certificações de nível de implantação do processo de teste

através da organização para Melhoria do Processo de Teste Brasileiro (Mpt .Br,

2014). Essas certificações são divididas em vários níveis e servem como

comprobabilidade de aderência ao processo de teste de software por parte da

empresa de forma organizada, estruturada e oficial dentro da empresa, ou pode ser

obtida certificação para o próprio testador, comprovando assim conhecimento para

prestar consultoria na área de testes ou estar coordenando uma equipe para a

implantação e utilização do processo de teste de software.

A abordagem do processo de teste vista como um projeto enfatiza sua devida

importância e pode ser aplicada a empresas de todos os portes, tendo seu foco na

melhoria do processo de teste de software em pequenas e micro empresas. Como

descrito no documento de Melhoria do Processo de Teste Brasileiro (MPT .Br, 2014),

além de ser possível a utilização do processo de teste em pequenas e micro

empresas, já é um processo definido de forma adequada no próprio cenário

tecnológico brasileiro, havendo assim incentivo para a implantação e utilização do

processo de teste de software.


REFERÊNCIAS BIBLIOGRÁFICAS

KANER, Cem; FALK, Jack; NGUYEN, Hung. Testing Computer Software. 2. ed.Third Avenue, New York: John Wiley & Sons Inc., 1999.

MYERS, Glenford. The Art of Software Testing. 2. ed. Hoboken, New Jersey: JohnWiley &Sons Inc., 2004.

MPT.Br. Disponível em: < http://mpt.org.br/ >. Acesso em 02 de abril de 2014.

PRESSMAN, Roger. Software engineering: a Practitioner’s Approach. 5. ed. Avenueof the Americas, New York: McGraw-Hill Companies, Inc., 2001.

RIOS, Emerson e MOREIRA, Trayahú. Teste de Software. Rio de Janeiro, Rio deJaneiro: Editora Alta Books, 2013.

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo, São Paulo:Pearson Education do Brasil, 2007.


APÊNDICE


Plano de Teste (Exemplo)

Versão 1.0: Thiago José

Belo Horizonte, 01 de abril de 2014.


Sistema de Intranet da Empresa X

Ambiente de teste

Servidores (Compartilhado com outros projetos, custo reduzido):

Desenvolvimento: Dual Core, 100 gb HD, 2gb memória RAM, SO Linux

Homologação: 2 servidores Dual Core, 100 gb HD, 2gb memória RAM, SO

Linux (aplicação e banco de dados)

Componentes a serem testados: área de apresentação (interface/site) e área

de administração (gerenciamento dos dados).

Forma de acesso ao sistema: intranet

Linguagem de programação utilizada: python

Ferramentas:

Teste unitário: framework django (open source) / unity test (embutido na

ferramenta)

Testes de integração, sistema e aceitação: ferramenta lettuce (open source)

Responsáveis técnicos

1 Gerente:

- zxy (nome do Gerente);

1 Analista de Teste:

- xyz(nome do Analista);

2 testadores:


- yzx (nome do Testador 1, pode sertambém desenvolvedor) - unitários

- zxy (nome do Testador 2) – testes comportamentais.

Tipos de testes a serem utilizados

- Testes unitários

- Testes de integração

- Teste de sistema

- Testes de aceitação

Métodos de teste (Como serão feitos os testes)

Testes unitários serão realizados durante a codificação do sistema, de forma

não automática, serão executados pelos testadores.

Testes de sistema e integração serão realizados de forma automatizada

através de uma ferramenta própria para isto.

Testes de aceitação serão manuais, sendo executados pelo cliente e pelo

Analista de Teste no ambiente de homologação.

Critérios de aceitação

- Cadastrar funcionários

- Efetuar acesso de funcionário


- Negar acesso por uma hora caso login ou senha sejam digitados errado 3

vezes

- Permitir cadastro de avisos de eventos por funcionários com permissão X

- Permitir cadastros de notícias apenas por funcionários com permissão Y

- Cadastrar usuários

- Efetuar acesso de usuários

- Negar acesso por uma hora caso login esteja errado 3 vezes

- Exibir avisos cadastrados pelos funcionários com a permissão X

- Exibir últimas 5 notícias da empresa cadastradas pelos funcionários com

permissão Y

Cronograma de testes

Atividades Data prevista parainício

Data prevista paratérmino

Plano de testes 01/01/01 02/01/01Roteiros de

testes (elaboração doscritérios de formaescrita)

03/01/01 04/01/01

Testes deaceitação/integração

04/01/01 05/01/01

Testes desistema

05/01/01 06/01/01

Testes deaceitação/Homologação

06/01/01 07/01/01


Riscos do Projeto

- Falha nos ambientes de desenvolvimento e/ou homologação;

- Novos requisitos fora do escopo inicial;

- Invalidez de membro(s) da equipe de teste;

- Indisponibilidade dos dados para executar os testes;

- Inconsistência dos dados para teste.

Abordagem de teste

Produção completa – Com acordado com o cliente “azx”, este disponibilizará

dados para teste ao término de cada módulo do sistema e ao término do sistema.

Requisitos de acesso

- Ambiente de teste configurado;

- Equipe de testes formada;

- Dados para início dos testes terem sido entregues;

- Critérios de aceitação sem erros de lógica (requisitos sujeitos a verificação).

Critérios de término dos testes

- Testes unitários sem erros de sintaxe e lógica;


- Testes de integração atendem aos requisitos de interface e estrutura;

- Testes de sistema atendem aos critérios de aceitação;

- Todos os requisitos foram atendidos.

Casos de Teste utilizados

Serão utilizados casos de teste tanto Caixa-branca quanto Caixa-preta, O

primeiro tipo de caso de teste será realizado pelos testadores ao final da construção

de cada módulo, já os testes Caixa-Preta serão realizados após entrada do sistema

em ambiente de homologação. Tais casos de testes serão criados pelo Analista de

Teste e serão entregues ao cliente assim que forem montados para o cliente tomar

conhecimento do que deverá ser realizado junto ao Analista de Teste nos casos

Caixa-preta e também saber quais testes estão sendo realizados pelos testadores

nos casos Caixa-branca.


Aceite dos responsáveis pela aprovação do plano de testes

Data de início dos testes: 01/01/01

Data de término dos testes: 07/01/01

Analista Responsável pela aprovação

______________________________

Cliente Responsável pela aprovação

_______________________________

processo de testes: abordagem de projeto de testes test...

Documents