escola superior aberta do brasil – esab …€¦ · · 2015-04-234.1. o que É o tdd? ... a...
TRANSCRIPT
ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM
ENGENHARIA DE SISTEMAS
GUSTAVO KATAOKA
USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL
CAMPO GRANDE – MS 2012
GUSTAVO KATAOKA
USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL
Monografia apresentada ao Curso de Pós-Graduação em Engenharia de Software da Escola Superior Aberta do Brasil como requisito para obtenção do título de Especialista em Engenharia de Sistemas, sob orientação Profa. Ma. Rachel Cristina Mello Guimarães.
CAMPO GRANDE – MS 2012
GUSTAVO KATAOKA
USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL
Monografia aprovada em .... de ................. de 2012.
Banca Examinadora
CAMPO GRANDE – MS 2012
RESUMO
Com a popularização do desenvolvimento ágil, surgem dúvidas em como se deve proceder com os testes em um software, pois alguns dos seus princípios podem ser confundidos com a falta de metodologia. O estudo objetiva descobrir como o desenvolvimento ágil aborda os testes de software, sendo o teste totalmente dependente da documentação produzida para este software. Dessa forma, utiliza a pesquisa caracterizada como indutiva do tipo qualitativa de caráter exploratório utilizando estudos realizados anteriormente, disponíveis em publicações como livros, teses, dissertações e artigos científicos. Conclui que o principal princípio do desenvolvimento ágil é a entrega contínua de funcionalidades de um software ao cliente.
Palavras-chave: Desenvolvimento ágil. Teste de software. Qualidade de software.
SUMÁRIO
CAPITULO 1 - INTRODUÇÃO .................................................................................... 6
1.1. JUSTIFICATIVA ................................................................................................... 7
1.2. OBJETIVOS ......................................................................................................... 7
1.2.1. Objetivo geral................................................................................................... 8
1.2.2. Objetivos específicos ...................................................................................... 8
1.3. DELIMITAÇÃO DO TRABALHO........................................................................... 8
1.4. METODOLOGIA ................................................................................................... 8
1.5. ORGANIZAÇÃO DO TRABALHO ........................................................................ 9
CAPITULO 2 - TESTE DE SOFTWARE ................................................................... 10
2.1. VALIDAÇÃO DE REQUISITOS .......................................................................... 11
2.2. QUALIDADE DE SOFTWARE ATRAVÉS DE TESTES ..................................... 12
2.3. DEFINIÇÕES DO QUE OS TESTES PODEM IDENTIFICAR ............................ 15
2.3.1. Falha ............................................................................................................... 15
2.3.2. Falta ................................................................................................................ 15
2.3.3. Erro ................................................................................................................. 15
2.3.4. Defeito ............................................................................................................ 16
2.4. VALIDAÇÃO E VERIFICAÇÃO .......................................................................... 17
2.5. VISÃO GERAL DAS TÉCNICAS DE TESTE DE SOFTWARE .......................... 20
2.5.1. Testes de caixa branca ................................................................................. 20
2.5.2. Testes de caixa preta .................................................................................... 22
2.5.3. Testes de caixa cinza .................................................................................... 23
2.6. FASES DE TESTE DE SOFTWARE .................................................................. 24
2.6.1. Teste Unitário................................................................................................. 24
2.6.2. Teste de Integração ....................................................................................... 25
2.6.3. Teste de Sistema ........................................................................................... 26
2.6.4. Teste de Aceitação ........................................................................................ 27
2.7. CONSIDERAÇÕES SOBRE O CAPÍTULO ........................................................ 28
CAPITULO 3 - DESENVOLVIMENTO ÁGIL ............................................................ 30
3.1. PLANEJAMENTO NO DESENVOLVIMENTO ÁGIL .......................................... 32
3.2. ESTIMANDO AS HISTÓRIAS DE USUÁRIO ..................................................... 35
3.2.1. Planning Poker .............................................................................................. 36
3.3. EXECUÇÃO DO PLANEJAMENTO ................................................................... 37
3.4. MÉTODOS ÁGEIS ............................................................................................. 40
3.4.1. Feature Driven Development ........................................................................ 40
3.4.2. Extreme Programming .................................................................................. 42
3.4.3. Scrum ............................................................................................................. 45
CAPITULO 4 - TEST DRIVEN DEVELOPMENT ...................................................... 48
4.1. O QUE É O TDD? .............................................................................................. 48
4.2. CICLO DE VIDA DO TDD .................................................................................. 49
4.3. TIPOS DE TESTES UTILIZADOS NO TDD ....................................................... 51
4.3.1. Teste Unitário................................................................................................. 51
4.3.2. Teste de Integração ....................................................................................... 51
4.3.3. Teste de Aceitação ........................................................................................ 51
4.4. EXEMPLO SIMPLES DE UTILIZAÇÃO DO TDD ............................................... 52
CAPITULO 5 - CONCLUSÃO ................................................................................... 55
REFERÊNCIAS ......................................................................................................... 57
6
CAPITULO 1 - INTRODUÇÃO
O desenvolvimento de software vem, ao longo do tempo, sofrendo diversas
mudanças. Partindo de um processo caótico ou inexistente, passando por
metodologias burocráticas e pesadas, até chegar a estratégias que visem a melhoria
da qualidade e redução de custos.
O teste de software é uma das principais atividades realizadas no processo de
desenvolvimento de um produto de software, sendo responsável, segundo
Sommerville (2011), por cerca de 40% do esforço realizado pela equipe de
desenvolvimento.
No passado, o teste não era tratado com a devida importância, agora é cada vez
mais visto como atividade essencial no desenvolvimento e entrega de um software.
Entretanto, testes pobres ou ineficazes podem ser tão ruins quanto nenhum teste
realizado e pode custar tempo, esforço e custo significativo, pois além de não
contribuir para melhorar a qualidade do software, tem como resultado que seus
clientes são os que irão encontrar e relatar os defeitos em seu software (WATKINS,
2009).
A experiência adquirida com o tempo mostra que o gasto com esforço em
desenvolvimento e confecção de testes de software é melhor do que ter a
credibilidade da organização afetada por causar prejuízos a clientes devido a
funcionalidades que não foram testadas devidamente.
Atualmente está se passando uma evolução no se diz respeito ao desenvolvimento
de software, com o Desenvolvimento Ágil (também referenciado como Método Ágil)
em ascensão. Esse método trás consigo um conjunto de princípios que chamam
muito a atenção de quem os vê pela primeira vez.
Um desses princípios que mais se destaca na visão deste autor é o que diz: “Priorize
o software funcionando do que a produção de documentação extensa”.
Um dos principais objetivos do teste de software, segundo Sommerville (2011), é
demonstrar que o software atende aos requisitos para o qual fora proposto. Logo,
7
para produzir os testes do software é necessária a documentação de requisitos
desse software.
Como o desenvolvimento ágil, ao propor que se priorize o software funcionando
acima de sua documentação, trata a confecção das várias formas de testes na
produção de um software e de que forma isso contribui para a garantia de qualidade
no software produzido?
Este trabalho está focado em encontrar e organizar as idéias de vários autores
dessa área de maneira a responder esse questionamento.
1.1. JUSTIFICATIVA
Com o crescimento da adoção de metodologias ágeis de desenvolvimento de
software, surge a preocupação em como os testes de um produto de software será
tratado durante o processo de produção do mesmo.
Essa preocupação se deve ao fato de que um dos princípios do desenvolvimento
ágil de software diz que se deve priorizar o software em funcionamento do que a
documentação do mesmo (RÜPING, 2003).
As metodologias de desenvolvimento tradicionais baseiam a confecção dos testes
em cima da documentação produzida. E como produzir os testes para um software
que pode ter documentação escassa?
A justificativa para esse estudo é esclarecer que, apesar de ser flexível e adaptativa
à equipe e aos projetos, o desenvolvimento ágil também objetiva a melhoria da
qualidade do software. E uma das formas para atingir esse objetivo é através dos
testes de software.
1.2. OBJETIVOS
Os objetivos estabelecidos para esse estudo foram definidos conforme apresentado
a seguir.
8
1.2.1. Objetivo geral
Descobrir de que maneiras as metodologias ágeis de desenvolvimento de software
confeccionam os testes de um sistema a ser produzido e como isso pode contribuir
para a garantia de qualidade desse sistema.
1.2.2. Objetivos específicos
1. Estudar as principais formas de testes aplicáveis ao desenvolvimento de
software;
2. Conceitualizar as principais metodologias de desenvolvimento ágil;
3. Identificar as formas como cada metodologia ágil estudada trata o
planejamento e execução de testes durante o desenvolvimento de um
produto de software.
1.3. DELIMITAÇÃO DO TRABALHO
A proposta deste trabalho é desvendar quais as principais formas de teste de caixa
branca, caixa preta e caixa cinza e suas estratégias para a confecção, bem como
suas fases de execução.
Este trabalho também foca em estudar o desenvolvimento ágil, mostrando alguns de
seus métodos. Os métodos apresentados serão Scrum, Programação Extrema e
Feature Driven Development (FDD). Também é apresentado o Test Driven
Development (TDD), sendo dedicado um capítulo inteiro a ele.
1.4. METODOLOGIA
A pesquisa deste trabalho caracteriza-se como indutiva do tipo qualitativa de caráter
exploratório. Utiliza estudos realizados anteriormente, disponíveis em publicações
como livros, teses, dissertações e artigos científicos sobre o tema proposto.
Para a avaliação do material pesquisado é aplicada uma análise e descrição de
conteúdo, buscando obter indicadores que permitam compreender melhor o tema.
9
1.5. ORGANIZAÇÃO DO TRABALHO
Este trabalho está organizado da forma como apresentado a seguir:
Capítulo 2 - Este capítulo apresenta uma revisão bibliográfica sobre teste de
software. Mostrando a sua importância para a garantia de qualidade de um produto,
quais os principais tipos de testes existentes e em que fases são aplicados.
Capítulo 3 - Conceitualiza o desenvolvimento ágil de software. Apresenta os
princípios defendidos pelo chamado “Manifesto Ágil”, diferença dos modelos
tradicionais e teóricos de desenvolvimento, quais os principais métodos e de que
forma cada um dos métodos apresentados contribui para melhorar o processo de
teste de software.
Capítulo 4 - Apresenta a metodologia de desenvolvimento ágil orientado a testes
(Test Driven Development – TDD). O TDD trata-se de um método ágil. O motivo pelo
qual fora dedicado um capítulo exclusivamente para isso deve-se ao fato de o TDD
representar a união dos dois objetos de estudo deste trabalho, no caso o Teste de
Software e Desenvolvimento Ágil.
10
CAPITULO 2 - TESTE DE SOFTWARE
Para Pressman (2010), o teste de software é um dos elementos que compõe a
gestão de qualidade e seve para descobrir erros cometidos inadvertidamente ao
projetar e construir um software.
Um dos aspectos mais críticos para a qualidade de um produto de software
customizado que deve ser levado em consideração é que o software deve atender
aos requisitos desejados pelo cliente (NAIK; TRIPATHY, 2008). Isso pode ser
facilmente observado quando nos deparamos com alguns requisitos impostos por
clientes que, muitas vezes, para o desenvolvedor não faz o menor sentido, mas que
deve ser atendido para que satisfaça o seu desejo.
Segundo Sommerville (2011), o processo de teste de software possui dois objetivos
distintos, sendo eles descritos como segue:
1. Demonstrar ao desenvolvedor e ao cliente de que o software atende aos
requisitos no qual fora proposto. Para um software customizado, isso significa
que deve haver pelo menos um teste para cada requisito listado no
documento de requisitos de usuário e de sistema. Para um produto de
software genérico, significa que deve existir testes para todas as
funcionalidades do sistema que irão incorporar o produto a ser lançado;
2. Descobrir falhas e defeitos no software onde o seu comportamento está
incorreto, indesejado ou fora das conformidades de suas especificações. Isso
engloba comportamento indesejável do sistema, tais como: falhas, cálculos
incorretos e corrupção de dados.
Já Lewis (2009) diz que teste não é apenas uma atividade para encontrar bugs1, é
também utilizado com o objetivo de assegurar a qualidade de software medindo seus
atributos e capacidades seguindo de encontro às expectativas e normas aplicáveis,
fornecendo informações valiosas sobre o esforço de desenvolvimento de software.
1 Termo utilizado para acusar um erro, falha, engano, fracasso em software de computador que produz um resultado incorreto ou inesperado.
11
Ao testamos um software, estamos atribuindo-lhe um valor que aumenta sua
qualidade e confiabilidade, além de reduzir drasticamente eventuais erros. Não
apenas testar para mostrar que ele funciona, mas começar com a suposição de que
contém erros e tentar encontrar o maior número de erros possível (MYERS, 2004).
2.1. VALIDAÇÃO DE REQUISITOS
O objetivo da validação de requisitos é assegurar que os requisitos definidos para
um sistema refletem o que o cliente deseja. Essa validação é importante, pois erros
em um documento de requisitos podem conduzir a um extenso custo de retrabalho
quando descobertos durante o desenvolvimento ou, principalmente, depois de o
sistema ter sido implantado. O custo para consertar o problema de requisito, fazendo
mudanças no sistema, é muito maior do que reparar o design ou erros de
codificação. A razão disso é que uma mudança no requisito significa que o design e
implementação do sistema também requerem mudança, além de ser necessário
testar novamente (SOMMERVILLE, 2011).
Uma afirmação um tanto quanto contraditória ao desenvolvimento ágil. Pois Shore e
Warden (2008) afirmam que um dos princípios do manifesto ágil diz que as
mudanças de requisitos são sempre bem vindas, mesmo tarde no desenvolvimento,
pois, com as mudanças sendo implementadas o quanto antes, o cliente pode
conseguir uma vantagem competitiva em seu negócio. Embora o custo seja o
mesmo, a mudança é mais bem vista no desenvolvimento ágil.
Sommerville (2011) afirma ainda que durante o processo de validação de requisitos,
verificações devem ser realizadas sobre os requisitos na documentação de
requisitos. Sendo:
Verificações de validade - Um usuário pode pensar que um sistema é necessário
para executar determinadas funções. No entanto, uma reflexão e análise podem
identificar as funções adicionais ou diferentes que são necessárias. Sistemas
possuem diversos stakeholders2 com necessidades distintas, e qualquer conjunto de
requisitos é inevitavelmente um compromisso com toda a comunidade de
stakeholders. 2 Qualquer grupo, indivíduo, ou organização que seja afetado, ou possa afetar o produto, projeto, ou organização (KANDT, 2006).
12
Verificações de consistência - Os requisitos em documento não podem ter
conflitos uns com os outros. Ou seja, não deve haver regras ou descrições
contraditórias de uma mesma funcionalidade do sistema.
Verificações de integridade - Todas as funcionalidades e restrições definidas pelo
usuário do sistema devem estar incluídas no documento de requisitos.
Verificações da realidade - Todo o conhecimento em tecnologia existente deve ser
utilizado na verificação dos requisitos para garantir que possam realmente ser
implementados, levando em conta o orçamento e cronograma para o
desenvolvimento do sistema.
Verificabilidade - para reduzir um conflito em potencial entre o cliente e o
contratante, os requisitos do sistema devem sempre ser escritos de modo que sejam
verificáveis. Deve ser possível escrever um conjunto de testes que possam
demonstrar que o sistema entregue atende cada requisito especificado.
2.2. QUALIDADE DE SOFTWARE ATRAVÉS DE TESTES
Em seu trabalho, Kandt (2006) diz que, ao desenvolver um software, devemos nos
preocupar tanto com a qualidade do produto de software quanto a qualidade do
processo utilizado para a produção desse software. A qualidade do produto reflete o
caráter essencial, funcionalidades e propriedades dos artefatos, e é um reflexo do
quão bem atenderão as necessidades dos stakeholders. Já a qualidade do
processo, por outro lado, reflete em como o produto de software é produzido. Ao
atingir essas qualidades beneficiará os usuários de três modos apresentados abaixo.
1. Qualidade convencional: representa a satisfação das partes interessadas;
2. Qualidade essencial: refere-se a atributos de um artefato necessários para
alcançar um nível mínimo de satisfação do cliente;
3. Qualidade atrativa: representa uma característica inesperada, porém bem
vinda, pelo produto.
Pressman (2010) descreve cinco pontos de vista nos quais a qualidade de software
pode ser embasada, sendo estes apresentados abaixo:
13
1. Visão transcendental: qualidade é algo que é reconhecido imediatamente,
porém não pode ser definido;
2. Visão do usuário: o usuário vê a qualidade em termos de objetivos específicos
do usuário final. Se o produto atende aos objetivos, então esse apresenta
qualidade;
3. Visão do fabricante: define a qualidade em termos de especificação original
do produto. Se o produto está em conformidade com a sua especificação,
então esse produto apresenta qualidade;
4. Visão do produto: sugere que a qualidade pode ser vinculada a características
inerentes de um produto;
5. Visão baseada em valor: baseia-se em quanto um cliente está disposto a
pagar pelo produto.
A qualidade de software pode definida como sendo a conformidade desse software
com os requisitos funcionais e de desempenho explicitamente declarados, padrões
de desenvolvimento documentados e características esperadas pelo software
desenvolvido. Além disso, a qualidade é medida com base nos requisitos do
software, sendo que a falta de conformidade com esses requisitos significa falta de
qualidade no software produzido.
Tian (2005) afirma que existem dois grupos com visões e expectativas diferentes
sobre garantia de qualidade de software: o grupo dos consumidores de produtos de
software composto basicamente por clientes e usuários, e o grupo dos produtores de
software formado pelos envolvidos com desenvolvimento, gestão, manutenção,
publicidade e serviços de produtos de software.
A expectativa dos consumidores é que o software execute funções úteis tal qual fora
especificado. Além disso, é esperado que o software realize essas funções
especificadas corretamente sobre uso repetitivo, por longos períodos de tempo e de
forma confiável.
14
Para os produtores de software a qualidade fundamental desejada é o cumprimento
das obrigações contratuais na produção de produtos de software que estejam de
acordo suas especificações pretendidas.
A garantia de qualidade foca no processo prevenindo contra defeitos, enquanto o
teste de software foca na detecção de erros e defeitos, relatando problemas com a
execução, tempo, tráfico, transações e interações do sistema (FUTRELL; SHAFER;
SAFER, 2002).
Em busca de um processo de fabricação relativamente livre de defeitos, devem-se
concentrar esforços em testes no processo de desenvolvimento de um software.
Sendo assim, os testes devem ser projetados e implementados para sistemas e
componentes para demonstrar que eles funcionam como esperado (TIAN, 2005).
Portanto, a demonstração de bom comportamento é o objetivo principal do teste,
que também pode ser interpretada como fornecendo evidências de qualidade no
contexto de qualidade de software, ou como atingir as metas de qualidade
determinadas.
Para Kandt (2006) a qualidade de um produto de software geralmente está
associada com a ausência de defeitos nesse software. Entretanto, qualidade
também pode estar associada a outras propriedades valorizadas por consumidores e
produtores de software, as quais são: eficiência, disponibilidade, manutenabilidade,
confiabilidade, portabilidade, reusabilidade e usabilidade. Dentro manutenabilidade
encontra-se a definição de testabilidade sendo definida como a extensão na qual o
software facilita a verificação do seu funcionamento.
O propósito primário para o teste de software pode ser considerado como a
demonstração de qualidade desse software. Tian (2005) demonstra pensar da
mesma forma quando afirma que os testes vão muito mais além de detectar e
consertar defeitos no software. Afirma ainda que com os testes podemos nos
beneficiar com a detecção de problemas com o processo de desenvolvimento e
entregas de produtos de software.
O teste pode ainda ser utilizado na detecção de problemas no sistema como um
todo quando um determinado sub-módulo sofre alguma alteração. Kand (2006)
afirma que dois terços dos defeitos encontrados no código do sistema são
15
introduzidos dessa forma. Ter uma boa estratégia de teste de software por ajudar
quando todo o processo de teste deve ser repetido, garantindo a qualidade mesmo
que mudanças aconteçam.
2.3. DEFINIÇÕES DO QUE OS TESTES PODEM IDENTIFICAR
Quando muitas pessoas associam qualidade a um sistema de software, é uma
indicação que poucos, caso haja, problemas são esperados acontecer durante sua
operação. E ainda, quando algum problema ocorrer, é esperado que cause o mínimo
de impacto possível (TIAN, 2005).
A literatura estudada apresenta diferentes visões a respeito dos elementos
identificados durante o processo de teste de software, sendo apresentados a seguir.
2.3.1. Falha
A incapacidade de um sistema ou componente para executar suas funções
requeridas dentro de requisitos de desempenho especificados (TIAN, 2005).
2.3.2. Falta
Uma característica de um sistema de software que pode levar a um erro do sistema.
Por exemplo, a falta ao inicializar uma variável poderia levar a um resultado errado
quando ela for utilizada (SOMMERVILLE, 2011).
2.3.3. Erro
É definido por Tian (2005) como sendo uma ação humana que produz um resultado
incorreto.
O erro é um estado do sistema. Na ausência de qualquer ação corretiva por parte do
sistema, um estado de erro pode levar a uma falha que não seria atribuído a
qualquer evento subseqüente ao erro (NAIK; TRIPATHY, 2008).
16
2.3.4. Defeito
Segundo Kandt (2006), um defeito é uma anomalia do produto que causa um efeito
inesperado. Uma organização deve utilizar uma abordagem eficiente e eficaz para
detecção de defeitos, tendo um benefício significativo, pois a detecção de defeitos e
as atividades de correção praticadas de forma ineficiente e ineficaz consomem cerca
de cinqüenta por cento da força de trabalho para criar o software, além de setenta e
cinco por cento do custo total do ciclo de vida do software.
Figura 1: Relações referentes a defeitos. Fonte: Tian (2005). Nota: Adaptado pelo autor.
O defeito se refere a um desvio de comportamento de um requisito de usuário ou da
especificação do produto de software (TIAN, 2005). Este autor afirma também que o
defeito pode ser visto como diferentes aspectos de erros, faltas e falhas, ou um
relacionamento entre os três. Um ou vários erros podendo gerar uma ou várias
faltas, e/ou uma ou várias faltas podendo gerar uma ou várias falhas, como ilustra a
Figura 1.
17
2.4. VALIDAÇÃO E VERIFICAÇÃO
Sommerville (2011) define a Validação e Verificação (V&V) como sendo o processo
de checagem e analise de um software, realizado durante e depois do processo de
implementação, para assegurar o cumprimento de suas especificações, garantindo
assim, a entrega das funcionalidades esperadas pelo cliente. Atividades de
verificação acontecem em todos os estágios do processo de desenvolvimento. A
V&V começa na revisão de requisitos e continua da revisão do design e inspeção de
código até a produção de testes de software.
A verificação avalia um sistema ou componente para determinar se o produto, em
uma determinada fase do ciclo de vida, satisfaz as condições impostas no início
dessa fase. Isso tipicamente envolve reuniões de revisão para avaliar documentos,
planos, código, requisitos e especificações, usando listas de verificação,
questionários, normas e convenções organizacionais. Verificação (Estamos
construindo certo o sistema?) ocorre durante cada fase do ciclo de vida do
desenvolvimento do software. Validação tipicamente envolve teste real e coloca-se
depois de completas as verificações. Validação (Estamos construindo o sistema
certo?) ocorre no final com os testes de aceitação do usuário. Também pode ser
considerado em ocorrer durante todo o ciclo de vida, pois as matrizes de
rastreabilidade de requisitos permitirão a avaliação contínua (FUTRELL; SHAFER;
SAFER, 2002).
18
Figura 2: Atividades exigidas para alcançar a qualidade de software. Fonte: Pressman (2010). Nota: Adaptado pelo autor.
A Figura 2 apresenta as atividades, como um conjunto de componentes, necessárias
para alcançar a qualidade de software.
A atividade de testes constitui o último baluarte3 a partir do qual a qualidade pode ser avaliada. Não se pode testar a qualidade. Se ela não estiver lá antes de começar a testar, também não estará lá quando terminar de testar (PRESSMAN, 2005, p.451).
Pressman (2005) afirma também que a V&V abrange um conjunto de atividades de
garantia de qualidade, tais como revisões técnicas formais, auditoria de configuração
e qualidade, monitoração do desempenho, simulação, estudo de viabilidade, revisão
da documentação, revisão do banco de dados, analise de algorítimos, teste de
desenvolvimento, teste de qualificação, teste de instalação e teste de desempenho.
A verificação serve para provar que um produto de software atende aos requisitos
especificados durante as atividades anteriores realizadas corretamente durante o
ciclo de vida de desenvolvimento. Já a validação confirma que o sistema atende aos
requisitos do cliente no final do ciclo de vida. A criação de testes está mais
3 Fortaleza, refúgio, construção segura.
19
relacionada com a validação do que a verificação. O teste de software é considerado
um processo de validação, ou uma fase do ciclo de vida (LEWIS, 2009).
A Figura 3 representa uma variação do modelo cascata com as fases de
desenvolvimento dispostas em forma de V (Modelo V), onde Tian (2005) relaciona a
verificação ou validação com seu requisito ou especificação correspondente. Os
requisitos do cliente são validados por uso operacional, enquanto a especificação do
produto, o projeto de alto-nível e o projeto de baixo-nível são verificados pelo teste
de sistema, teste de integração e teste de componente, respectivamente. O teste de
sistema também faz validação do produto, concentrando-se na forma como as
operações do sistema atendem as especificações do produto. Por fim, a atividade de
codificação e o teste unitário são agrupados em uma única fase, onde o próprio
código especifica o comportamento esperado através de testes unitários.
Figura 3: Atividades de V&V associadas com o modelo V. Fonte: Tian (2005). Nota: Adaptado pelo autor.
20
O teste passa a acontecer em todas as fases do ciclo de vida quando a verificação é
incorporada ao teste. Melhores resultados são atingidos ao combinar a verificação e
validação no processo de teste do produto. A verificação inclui procedimentos
sistemáticos de revisão, analise e teste durante o ciclo de vida de desenvolvimento,
começando com a fase de requisitos e continuando até a fase de codificação,
assegurando a qualidade da produção e manutenção do software. Além de impor
uma prática de desenvolvimento sistemática e organizada resultando em um produto
que pode ser facilmente compreendido e avaliado por uma entidade independente
(LEWIS, 2009).
2.5. VISÃO GERAL DAS TÉCNICAS DE TESTE DE SOFTWARE
A atividade de teste, segundo Pressman (2010), possui como objetivo primário a
descoberta de erros em um software. Como objetivo secundário, a atividade de teste
demonstra que as funções do software estão trabalhando de acordo com as
especificações do cliente. Um teste bem sucedido é aquele que revela um erro,
defeito ou desconformidade com a especificação ainda não descoberta. Pressman
(2005) salienta ainda que o intuito do teste não seja apenas demonstrar a ausência
de erros, mas evidenciar a presença de erros ao se testar um software.
A maior parte da literatura estudada referentes a testes de software apontam a
existência de três técnicas principais. Sendo elas apresentadas abaixo:
Teste de caixa branca;
Teste de caixa preta;
Teste de caixa cinza.
A seguir é abordada cada uma dessas técnicas de teste de software.
2.5.1. Testes de caixa branca
Segundo Sommerville (2011) o teste de caixa branca, também conhecido como teste
estrutural, é uma abordagem para projetar casos de teste, onde os testes são
derivados de estruturas e implementações de software conhecidas. O entendimento
21
do algorítimo usado em um determinado componente é utilizado para fazer as
projeções de casos de teste.
Para Pressman (2010), usando o teste de caixa branca, o engenheiro de software
pode confeccionar casos de teste com os propósitos listados abaixo:
1. Garantir que caminhos independentes dentro de um módulo tenham sido
exercitados pelo menos uma vez;
2. Exercitar todas as decisões lógicas com os valores falso ou verdadeiro;
3. Executar todos os laços em suas fronteiras e dentro de seus limites
operacionais;
4. Exercitar todas as estruturas de dados internas para garantir sua validade.
Tian (2005) diz o teste de caixa branca serve para verificar a correta implementação
das unidades internas do software tal como declarações, estruturas de dados,
blocos, etc. Isso é feito através da execução de tais unidades e observando seus
comportamentos. Esse teste possui essa denominação devido a visualização das
partes internar do software, como se o software fosse uma caixa transparente.
Uma desvantagem do teste de caixa branca é que ele não verifica se as
especificações estão corretas, isto é, concentra-se apenas na lógica interna e não
verificar a conformidade da lógica com a especificação. Outra desvantagem é que
não há maneira de detectar os caminhos desaparecidos e dados sensíveis a erros.
Por exemplo, se a declaração em um programa deve ser codificada "se | a-b | < 10",
mas é codificada "se (a-b) < 1", isso não seria detectável sem a consulta da
especificação do produto. Uma desvantagem final é que o teste de caixa branca não
pode executar todos os caminhos possíveis da lógica de um programa, porque isso
implicaria um número astronomicamente grande de testes (LEWIS, 2009).
Segundo Tian (2005), várias ferramentas de software são utilizadas no auxílio da
execução do teste de caixa branca, tais como as ferramentas de depuração de
software (debuggers), ajudando na rastreabilidade de quais caminhos são
exercitados durante a execução.
22
O teste de caixa branca examina o código fonte com foco no fluxo de controle e no
fluxo de dados. O fluxo de controle refere-se ao fluxo de uma instrução para outra. O
controle passa de uma instrução para outra através de uma série de maneiras, como
uma instrução que é seguida de outra, chamada a funções, passagem de
mensagem e interrupções. Instruções condicionais o fluxo de controle normal em um
programa. O fluxo de dados refere-se à propagação de valores de uma variável ou
constante para outra variável. Definições e usos de variáveis determinam o aspecto
do fluxo de dados em um programa (NAIK; TRIPATHY, 2008).
2.5.2. Testes de caixa preta
Tian (2005) define o teste de caixa preta, também denominado na literatura como
teste funcional, verifica a correta manipulação das funções externas providas por um
software. Esse teste é conhecido como caixa preta porque toma-se o software como
uma caixa, a qual não é possível visualizar o seu interior, mas sim seu
comportamento exterior através da entrada e saída de dados e outras características
observáveis. Simplificando, o teste de caixa preta consiste “rodar” o software e
observar na esperança de ser fácil distinguir um comportamento esperado de um
inesperado.
No teste de caixa preta, o engenheiro de teste preocupa-se apenas com a parte
externa acessível do software, geralmente a mesma visão que um simples usuário
do software teria, isto é, basta inserir os valores de entrada e observar o que ocorre
na saída dos resultados. Ao aplicar uma entrada para o software e observar o
resultado, o engenheiro de teste deve ser capaz de determinar se esse resultado era
ou não esperado. As possíveis entradas e a avaliação dos resultados devem ser
interpretados a partir da especificação de requisitos do software (NAIK; TRIPATHY,
2008).
Para Pressman (2010), os testes de caixa preta não são uma alternativa aos testes
de caixa branca. Trata-se de uma abordagem complementar que tem a finalidade de
descobrir uma classe de erros diferentes dos erros descobertos pelos testes de
caixa branca. Os testes de caixa preta procuram descobrir as seguintes categorias
de erros:
1. Funcionalidades incorretas ou ausentes;
23
2. Erros de interface;
3. Erros nas estruturas de dados;
4. Erro no acesso a bancos de dados externos;
5. Erros de desempenho;
6. Erros de inicialização e término.
Segundo Myers (2004), na abordagem de teste de caixa preta, os testes devem ser
derivados da especificação do produto, sem se preocupar como ele funciona por
dentro. Neste caso o teste de caixa preta assemelha-se a fazer um test-drive em um
automóvel. Grande parte das pessoas sequer imagina como os automóveis
funcionam por dentro, mas a maioria delas sabe como operar um veículo e possuem
especificações e preferências ao realizarem o teste.
Myers (2004) afirma ainda que, ao usar a abordagem de teste de caixa preta para
encontrar erros em um software, o critério deve ser exaustivo, fazendo uso de várias
possibilidades de condições de entradas nos casos de teste.
2.5.3. Testes de caixa cinza
De acordo com Patton (2005) o teste de caixa cinza é uma mistura do teste de caixa
branca com o teste de caixa preta. Com esse teste, o testador equilibra a linha que
divide o teste de caixa branca do teste de caixa preta. Porém, o teste é feito como o
teste de caixa preta, mas o trabalho é complementado com observações (não tão
minuciosas como no teste de caixa branca) no funcionamento interno do software.
Para Lewis (2009), o teste de caixa preta representa a combinação entre o teste de
caixa branca e o teste de caixa preta. O testador deve estudar a especificação de
requisitos do software e conversar com a equipe de desenvolvimento para entender
a estrutura interna do sistema. A motivação para esse tipo de teste é esclarecer
especificações ambíguas para projetar testes. Um exemplo do uso de teste de caixa-
cinza é quando aparece para o testador uma determinada funcionalidade que parece
ser reutilizada em vários momentos da aplicação. Se o testador se comunica com o
24
desenvolvedor e entende o design interno e arquitetura, muitos testes serão
eliminados, pois a funcionalidade será testada apenas uma única vez.
2.6. FASES DE TESTE DE SOFTWARE
Essa seção apresenta as diferentes estratégias e fases teste de software, bem como
quais as técnicas que são utilizadas em cada uma dessas fases.
2.6.1. Teste Unitário
Segundo Pressman (2010), o teste unitário é usado para verificar a menor unidade
de projeto de software, ou seja, o módulo. Caminhos de controle são testados para
descobrirem erros dentro do módulo, utilizando para isso a descrição detalhada do
projeto. A complexidade dos testes e os erros detectados são limitados pelo campo
de ação restrito estabelecido para o teste unitário, sendo este baseado sempre no
teste de caixa branca.
Para Sommerville (2011), teste unitário é chamado de teste de componente e refere-
se ao processo de testar componentes individuais em um sistema. Esse teste tem o
objetivo de expor as falhas que um sistema venha a possuir. Há diferentes
componentes que podem ser testados nesse estágio, dentre os quais:
1. Funções individuais ou métodos de um objeto;
2. Classes de objeto que possuem diversos atributos e métodos;
3. Componentes compostos formado por vários objetos ou funções diferentes.
Estes componentes compostos têm uma interface definida que é usada para
acessar sua funcionalidade.
O teste unitário pode feito isoladamente do resto do sistema dependendo do ciclo de
vida de desenvolvimento e do sistema. O teste de componente pode incluir o teste
de funcionalidades e características não-funcionais especificas como o
comportamento dos recursos utilizados, performance ou robustez, bem como testes
estruturais. Os casos de teste são derivados de produtos de trabalho, tais como o
design de software ou o modelo de dados (GRAHAM et al., 2006).
25
2.6.2. Teste de Integração
Segundo Pressman (2010), o teste de integração é uma técnica sistemática para a
construção da arquitetura de software e que, ao mesmo tempo, realiza testes para
descobrir erros associados à interface. O objetivo é coletar unidades de
componentes testados e construir uma estrutura de programa ditada pelo design.
O teste de integração são testes de caixa preta também. Porém as caixas são
geralmente maiores do que uma unidade. Muitas vezes, as unidades são agrupadas
em componentes, ou programas com várias sub-rotinas, ou mesmo sub-sistemas.
Em um paradigma orientado a objetos, vários objetos pertencentes a um sub-
sistema são agrupados e submetidos a teste de caixa preta, depois o agrupamento é
combinado com outros agrupamentos para formar o sistema como um todo, como
mostra a Figura 4, que é então submetido ao teste de integração (FUTRELL;
SHAFER; SAFER, 2002).
Figura 4: Teste de integração. Fonte: Futrell; Shafer; Safer (2002).
O grande problema do teste de integração, segundo Sommerville (2011), é localizar
os erros. Há interações complexas entre os componentes do sistema e, quando uma
saída anômala é descoberta, pode ser difícil identificar onde ocorreu o erro. Para
facilitar a localização de erros, deve-se sempre usar uma abordagem incremental
26
para integração de sistemas e testes. Inicialmente, deve-se integrar uma
configuração mínima do sistema e testar. Depois deve-se adicionar componentes a
esta configuração mínima e teste novamente após cada incremento e assim,
sucessivamente, até que todos os componentes tenham sido integrados.
2.6.3. Teste de Sistema
Após o teste de integração ser completado, o próximo passo é o teste de sistema. O
teste de sistema checa se o produto integrado atende a especificação de requisitos
(SPILLNER; LINZ; SCHAEFER, 2007). Isso é necessário após o teste de integração
devido:
Os testes abaixo do teste de sistema, de acordo com o Modelo V, testa o
sistema segundo suas especificações técnicas, ou seja, na perspetiva técnica
do desenvolvedor de software. O teste de sistema olha para o software com a
perspectiva do usuário, sendo que os testadores validam se os requisitos
estão completos e atendidos apropriadamente;
Muitas funções e características do sistema resultam da interação de todos os
componentes, sendo estas visíveis apenas no nível de operação do sistema.
Para Graham et al. (2006), o teste de sistema está concentrado no comportamento
de todo o software como fora definido no escopo do projeto de desenvolvimento.
Podem-se incluir testes baseados em riscos e/ou na especificação de requisitos,
processos de negócio, casos de uso ou outra descrição de alto nível do
comportamento do sistema, interações com o sistema operacional e recursos do
sistema. O teste de sistema, geralmente, é o último teste diretamente relacionado
com desenvolvimento que verifica se o produto a ser entregue atende as
especificações de requisitos, sendo seu propósito encontrar o maior número de
defeitos possível. Na maioria das vezes, esse teste é realizado por testadores
especializados que formam uma equipe de teste dedicada, e às vezes
independente, no âmbito do desenvolvimento, reportando os erros e defeitos
encontrados ao gerente de desenvolvimento ou gerente de projeto. Em algumas
organizações, o teste de sistema é realizado por uma equipe de terceiros ou por
analistas de negócios. O nível de independência é baseado no nível de risco
27
aplicável e isso terá uma influência alta sobre a forma como o teste do sistema é
organizado.
Graham et al. (2006) afirma ainda que o teste de sistema deve abordar tanto os
requisitos funcionais como os não-funcionais. Os testes não-funcionais incluem
desempenho e confiabilidade. Os testadores podem precisar para lidar com
requisitos incompletos ou em situação irregular. O teste de requisitos funcionais
começa usando técnicas de caixa preta apropriadas para o aspecto do sistema a ser
testado. Por exemplo, uma tabela de decisão pode ser criada para combinações de
efeitos descritos nas regras de negócio. Técnicas de caixa branca também podem
ser usadas para avaliar a meticulosidade dos elementos de testes.
O teste de sistema para um software grande e complexo pode levar muitos meses e
envolver uma quantidade elevada de pessoas do time de desenvolvimento. Também
é possível que seja necessário todos os programadores do time de desenvolvimento
para corrigir os erros e defeitos encontrados durante essa fase de teste. O termo
“teste de sistema” se originou dos testes de grandes aplicações. Hoje, o termo é
aplicado para a fase final de testes de aplicações de qualquer tamanho. O teste de
sistema é, também, um termo abrangente que inclui testes especializados, tais como
desempenho ou segurança (JONES; BONSIGNOUR, 2011).
Teste de sistema pode exigir controles de configuração formais e também merece
apoio de monitoramento de defeitos. Teste de sistema é normalmente baseado em
princípios de caixa preta, embora às vezes a forma de teste caixa branca seja usada
também. Teste de sistema pode ser realizado pelos desenvolvedores, o pessoal de
teste profissional, ou por pessoal de garantia da qualidade (JONES; BONSIGNOUR,
2011).
2.6.4. Teste de Aceitação
De acordo com Watkinst (2009), o teste de aceitação é usado para garantir que o
software atende aos requisitos de negócios, fornecendo confiança de que o sistema
funciona corretamente. Sendo utilizado antes de o software ser formalmente
entregue ao usuário, o teste de aceitação é conduzido por representantes indicados
pelos usuários e por um representante da equipe de desenvolvimento.
28
Segundo Graham et al. (2006), a organização de desenvolvimento, ao realizar os
testes de sistema e todas as correções de defeitos necessárias, deve entregar o
software ao usuário ou cliente mediante teste de aceitação. O teste de aceitação
deve responder a perguntar como:
O sistema pode ser liberado?
Quais são os riscos em potencial?
O sistema cumpre suas obrigações?
Graham et al. (2006) firma ainda que o teste de aceitação requer mais atenção dos
usuários ou clientes do que dos outros stakeholders envolvidos. Sua execução deve
ser feita em um ambiente o mais parecido possível com o ambiente de produção
onde o software será implantado.
Para Lewis (2009), o teste de aceitação verifica se o sistema satisfaz aos critérios de
aceite do usuário. Esse teste deve ser planejado com base nas especificações de
requisitos e requer um ambiente de teste formal. O teste de aceitação usa a técnica
de teste de caixa preta para testar o sistema segundo suas especificações e é,
geralmente, executado pelo usuário final. Durante o teste de aceitação, é importe
que o time do projeto coordene o processo de teste e atualize os critérios de aceite,
conforme necessário.
O objetivo do teste de aceitação é estabelecer uma relação de confiança entre o
sistema e seus interessados. O teste de aceitação é mais focado no tipo de teste de
validação, nesse caso, a tentativa de determinar se o sistema é adequado para a
finalidade. Encontrar defeitos não deve ser o foco principal do teste de aceitação e
sim avaliar a disponibilidade do sistema para a implantação e uso (GRAHAM et al.,
2006).
2.7. CONSIDERAÇÕES SOBRE O CAPÍTULO
Obviamente a literatura traz muito mais sobre teste de software, podendo ser
dedicados livros inteiros sobre o assunto, que é tão antigo quanto a própria
engenharia de software. Porém, a principal informação sobre o teste de software foi
29
adquirida, sendo esta: os testes são totalmente dependentes das informações
contidas nos documentos de requisitos para sua produção.
Este capítulo mostrou também como se relacionam o teste de software e a qualidade
de software, apresentando os testes como forma de verificação dos requisitos e
validação do processo de desenvolvimento e do produto de software.
30
CAPITULO 3 - DESENVOLVIMENTO ÁGIL
Pressman (2010) define o desenvolvimento ágil como sendo a combinação de
filosofias e de um conjunto de diretrizes de desenvolvimento. Essa filosofia encoraja
a satisfação do cliente através da entrega rápida e incremental do software, e motiva
a equipe com métodos informais e processos simplificados.
Segundo Sommerville (2011), a filosofia por traz do desenvolvimento ágil está
refletida no chamado "Manifesto Ágil", o qual foi concebido pelos principais
desenvolvedores desses métodos. O manifesto é apresentado na Figura 5, sendo
exatamente o mesmo apresentado por Pressman (2010) e Sommerville (2011). Essa
figura mostra também os nomes dos desenvolvedores fundadores do Manifesto Ágil.
Figura 5: Maniesto Ágil. Fonte: Manifesto ( 2001).
O Manifesto Ágil de Desenvolvimento de Software foi assinado por Kent Beck e
outros dezesseis notáveis desenvolvedores, escritores e consultores de software
31
(Figura 5), sendo que este grupo ficou conhecido como a "Aliança Ágil"
(PRESSMAN, 2010). A Aliança Ágil segue os seguintes princípios:
1. A maior prioridade é satisfazer o cliente através da entrega contínua e
adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento. Processos ágeis tiram vantagem das mudanças visando
vantagem competitiva para o cliente.
3. Entregar freqüentemente software funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto.
5. Construir projetos em torno de indivíduos motivados. Dar a eles o ambiente e
o suporte necessário e confiar neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para uma equipe
de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter
um ritmo constante indefinidamente.
9. Contínua atenção a excelência técnica e bom design aumentam a agilidade.
10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é
essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-
organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e
então refina e ajusta seu comportamento de acordo.
32
Os princípios apresentados estão em ordem de prioridade, portanto a maior
prioridade do desenvolvimento ágil é: Satisfazer o cliente através da entrega
contínua e adiantada de software com valor agregado.
É muito difícil fazer entrega contínua em curtos períodos de tempo. Por causa desse
princípio, o método ágil, segundo Rasmusson (2010), preocupa-se em quebrar um
grande problema em problemas menores. A quebra do problema em partes menores
pode ser uma tarefa complicada do ponto de vista do desenvolvedor. Para amenizar
esse problema, o método ágil procura manter o cliente quase como um membro da
equipe, consultando-o sempre, de maneira organizada, e focando em seu ponto de
vista, afinal é a ele que o produto de software deve atender.
Rasmusson (2010) afirma ainda que deve-se assegurar que o que será entregue
deve funcionar. Com isso, cada um dos pequenos problemas deve passar por
testes. A cada nova funcionalidade implementada no software pode e deve passar
pelos mesmos testes vistos no Capítulo 2. Para isso a documentação do software
deve existir como forma de suporte a essas etapas.
As mudanças em como o software deve se comportar sempre fazia as equipes de
desenvolvimento da velha guarda ficar apreensivas com o fato. Mas as equipes de
desenvolvimento ágil devem ser capazes de responder bem a essas mudanças,
quase que as desejando. Pressman (2010) diz que a agilidade é muito mais do que
resposta eficaz às mudanças. Também engloba a filosofia, adotada no manifesto,
que incentiva a organização e atitude do time, fazendo com que a comunicação
entre membros do time melhore. A adoção do cliente como parte da equipe elimina
eventuais disputas entre eles e a equipe de desenvolvimento.
3.1. PLANEJAMENTO NO DESENVOLVIMENTO ÁGIL
Todo projeto, geralmente, começa com o planejamento e no desenvolvimento ágil
isso não é diferente. A grande questão é como deve ser o planejamento no
desenvolvimento ágil de modo a dar suporte ao seu primeiro princípio, sendo
entregar o software continuamente, em curtos períodos de tempo, através de
iterações.
33
Rasmusson (2010) compara o planejamento no desenvolvimento ágil com um
planejamento de afazeres de um fim de semana agitado, utilizando para isso uma
lista de tarefas.
Essa lista de tarefas é conhecida no desenvolvimento ágil como master story list
(lista de histórias mestre), e cada elemento contido nessa lista, ou seja, cada tarefa,
é denominada user story (história de usuário).
A história de usuário é definida por Cohn (2004) como sendo uma funcionalidade
que será útil ao usuário ou cliente interessado no software. As histórias de usuário
são compostas de três aspectos:
Uma descrição usada para planejamento e para lembrete;
Conversas para concretizar os detalhes;
Testes que transmitem e documentam os detalhes, sendo usado para
determinar quando a funcionalidade é concluída.
A lista de histórias mestre contém uma descrição em alto nível de cada
funcionalidade que o cliente deseja ver no sistema, sendo a base para a
especificação de requisitos (RASMUSSON, 2010). Essa lista deve ter as histórias de
usuário ordenadas segundo a prioridade definida pelo cliente.
Após terem sido priorizadas, cada uma das histórias deve ser estimada, quanto ao
tempo de sua conclusão, pela equipe de desenvolvimento. Esse trabalho inicial,
apresentado na Figura 6, forma a base para o planejamento do projeto.
34
Figura 6: Criação da Master story list para planejamento do projeto. Fonte: Rasmusson (2010). Nota: Adaptado pelo autor.
Uma iteração refere-se a um grupo de histórias de usuário, ordenadas segundo
prioridade do cliente, a ser desenvolvido em um determinado intervalor de tempo.
Geralmente um período de uma ou duas semanas é definido para cada entrega. A
cada iteração um grupo de histórias é transformado em software testado e pronto
para execução em ambiente de produção do cliente. Conforme as histórias vão
sendo implementadas, é possível medir a velocidade do time, ou seja, quanto do
software é feito por iteração, para saber o quanto do software será feito no futuro
(RASMUSSON, 2010).
Uma maneira eficiente para registrar as histórias de usuário, segundo Leffingwell
(2011), é apresentada abaixo:
Como <papel>, eu gostaria <atividade> com isso <benefício>.
Dessa forma, as histórias de usuário podem ser vistas de modo a incorporar
elementos do problema como o benefício desejado, a função ou papel do usuário
diante do problema, e a atividade em si que o usuário deseja no sistema. Abaixo
segue um exemplo:
35
Como vendedor, eu gostaria de paginar meus contatos, com isso posso selecionar facilmente um grande números de clientes em potencial.
Leffingwell (2011) afirma também que as histórias de usuário são consideradas
como sendo a substituição ágil para o que tem sido tradicionalmente expresso como
declarações de requisitos de software (ou casos de uso no RUP e UML), sendo elas
a locomotiva do desenvolvimento ágil. Desenvolvidas inicialmente dentro de
construções do XP, são agora utilizadas também para desenvolvimento ágil em
geral, e são ensinadas na maioria das classes de Scrum.
3.2. ESTIMANDO AS HISTÓRIAS DE USUÁRIO
Ao estimar história de usuário, logo vem a cabeça que o que se deseja com a
estimativa é descobrir quanto tempo uma determinada história gastará para ser
concluída.
Porém, raramente as estimativas serão corretas devido ao fato de não ser possível
saber se os membros da equipe de desenvolvimento terão interrupções ao longo
dos dias de desenvolvimento.
Um dia sem interrupções ou preocupações de um time de desenvolvimento é
definido por Cohn (2004) como sendo um dia ideal. Também é possível pensar em
outras unidades de tempo pra medir a estimativa, por exemplo, uma semana ideal.
Um dia ideal dificilmente acontecerá a um dos membros do time, sendo praticamente
impossível que aconteça para todos os membros do time. Segundo Shore e Warden
(2008), parte do segredo para fazer boas estimativas é de prever o esforço e não o
tempo que um projeto irá tomar. As estimativas devem der feitas em termos de dias
ideais, muitas vezes chamado de store points (pontos de história). Pontos de história
é o número de dias ideais que uma tarefa levaria se realizada inteiramente.
Conforme McConnell (2006 apud MCCONNELL; RASMUSSON, 2010), o principal
objetivo da estimativa de software não é prever o resultado de um projeto, é para
determinar se as metas do projeto são realistas o suficiente para permitir que o
projeto seja controlado para conhecê-las.
36
3.2.1. Planning Poker
O Planning Poker (Poker do Planejamento) consiste em um baralho de cartas
contendo valores de pontos de história. Sendo que cada membro da equipe de
desenvolvimento possui um baralho completo (PICHLER, 2010).
A Figura 7 ilustra procedimento do poker do planejamento. Para cada história, o
cliente lê a descrição, fazendo com que o time realize um debate para conhecer os
detalhes da história. A estimativa é feita através do baralho, sendo que cada
membro do time de desenvolvimento seleciona a carta que representa sua
estimativa (LEFFINGWELL, 2011).
As cartas devem ser colocadas na mesa com a face para baixo, ou seja, sem revelar
a estimativa no primeiro momento. As estimativas devem ser reveladas ao mesmo
tempo depois que todos os membros do time fizerem a escolha.
Figura 7: Aplicação do Poker de Planejamento para estimar uma história. Fonte: Rasmusson (2010). Nota: Adaptado pelo autor.
37
Revelar a estimativa ao mesmo tempo é útil para evitar que uma estimativa revelada
prematuramente influencie a escolha dos outros membros.
Segundo Rasmusson (2010), o poker do planejamento pode ser usado também para
prover a comunicação entre os membros do time. Depois de reveladas as
estimativas, o time discute, caso haja alguma divergência, para revelar detalhes da
história não vistos por alguns membros e pra descobrir os membros que já tiveram
algum tipo de experiência com histórias parecidas.
Após a discussão, todas as cartas são recolhidas e o processo é repetido até que se
faça um consenso na estimativa de todos os membros da equipe de
desenvolvimento (RASMUSSON, 2010).
3.3. EXECUÇÃO DO PLANEJAMENTO
Como foi dito anteriormente, o software é produzido continuamente através de
iterações. As iterações são constituídas de histórias de usuário, sendo que o
agrupamento das histórias deve ser feito de modo que uma iteração seja possível de
ser realizada, segundo a estimativa obtida, no período de uma a duas semanas,
respeitando a ordem de prioridade definida pelo cliente.
De acordo com Rasmusson (2010), ao desenvolver uma iteração, há basicamente
três etapas que cada história de usuário contida nessa iteração deve passar para se
convertida em funcionalidade útil ao cliente. Essas etapas são listadas abaixo:
Análise e projeto;
Desenvolvimento;
Teste.
Essas etapas são observadas também na Figura 8. Após fazer tudo o que se julgar
necessário para a história é que se pode considerá-la como uma funcionalidade
desenvolvida.
38
Figura 8: Processo aplicado a cada tarefa da Master story list. Fonte: Rasmusson (2010). Nota: Adaptado pelo autor.
Quando a funcionalidade é desenvolvida, passa-se à outra história, até que todas as
histórias da iteração sejam desenvolvidas, podendo assim realizar a entrega do
incremento de software ao cliente.
Para Leffingwell (2011), cada história opera no mesmo padrão, ou seja, a definição
da história, escrita do código e do teste, e execução dos testes em função do código.
Tudo é feito em paralelo e desenvolvimento da história só é completo quando tudo
isso é feito. Essa seqüência é conhecida como Definição/Construção/Teste, e é
definida a seguir:
Definição: essa função refere-se a combinação da especificação de
requisitos e projeto. Essa etapa é elaborada através de interações entre o
cliente e a equipe de desenvolvimento;
Construção: refere-se basicamente a etapa de codificação da história de
usuário. Durante esse processo não só é admitida como também é
encorajada conversações entre desenvolvedores e cliente;
39
Teste: a história não pode ser dada como completa sem antes passar por um
teste de aceitação, o que assegura que o código produzido atende a intenção
definida para essa história. A produção de testes de aceitação (além de testes
unitários) depois, ou em paralelo com a codificação, ajuda a compreensão da
história pela equipe de desenvolvimento.
Portanto, na primeira etapa do desenvolvimento de uma história, ou seja, na etapa
de analise e projeto, é que é feito o detalhamento da especificação de requisitos.
Isso significa que a cada inicio do desenvolvimento de uma história, deve-se fazer a
especificação dessa história. Para que isso seja possível, a comunicação constante
com o cliente é necessária.
Dessa forma consegue-se atingir os objetivos do manifesto ágil, ou seja, valorizando
mais os indivíduos envolvidos através de interações, colaboração com o cliente e
resposta às mudanças.
Mas até que ponto se pode considerar a documentação do software de modo que dê
suporte necessário para as etapas seguintes como o teste, por exemplo? Rüping
(2003) descreve a experiência de dois colegas quando esses se juntaram a ele em
um projeto, um após o outro. O primeiro deles foi submetido a uma grande e
complexa documentação desenvolvida antes de sua chegada. Algum tempo depois,
ao ver como o colega estava se saindo com a documentação, encontrou
descontentamento e frustração, pois o colega estava afogado na especificação, mas
era impossível manter todos os detalhes em sua mente. O trabalho do novo colega
começou a melhorar quando começou a interagir com os outros membros do time,
fazendo discussões e depois tomando a documentação como apoio.
Quando o segundo colega se juntou à equipe, seu tratamento foi diferente do
primeiro. Ele recebeu apenas uma breve explicação sobre o projeto e um pequeno
documento introdutório que incluía todas as coisas úteis para saber sobre o projeto,
além de uma lista de contatos para esclarecimento de várias questões. Seu
amadurecimento no projeto foi mais rápido do que o primeiro.
Rüping (2003) conclui estas histórias evocando a questão de por que alguns
documentos acabam por ser úteis, enquanto outros não. Aparentemente, algumas
40
coisas podem ser melhor comunicadas através de documentos, mas outras não
podem.
Ao voltar para o manifesto ágil, o qual diz "software em funcionamento mais do que
documentação abrangente", podemos concluir que a documentação é mais valiosa
se contribuir para os outros objetivos globais. Neste sentido, a documentação é um
meio e não um fim. Quanto mais ela ajudar os indivíduos interagirem em equipe,
mais a documentação se torna útil, e mais fácil se torna para a equipe desenvolver
software em funcionamento.
3.4. MÉTODOS ÁGEIS
Segundo Shore e Warden (2008), um método, ou processo, é uma maneira de
trabalhar. Para fazer algo, deve-se seguir um processo. Alguns processos são
escritos, como se fossem roteiros a serem seguidos; outros são informais, como
limpar uma casa.
Métodos Ágeis são processos de desenvolvimento de software que dão suporte à
filosofia ágil e consistem em conjuntos de elementos individuais chamados práticas.
Dentre essas práticas encontram-se o uso de controle de versão, definição de
padrões de código e demonstrações semanais aos stakeholders. Essas práticas,
muitas das quais já existem há anos, são combinadas pelo método ágil em uma
maneira única que acentua as partes que dão apoio a filosofia ágil, descarta o que
for considerado desnecessário, e agrega algumas novas idéias. O resultado é visto
por muitos como leve, porém um poderoso método de desenvolvimento.
A seguir são apresentados alguns métodos ágeis, sendo eles o Feature Driven
Development (FDD), o Extreme Programing (XP) e o Scrum. Dentre os assuntos
tratados, será apresentado o ciclo de vida de cada um e maneiras como cada um
trata os testes durante o desenvolvimento do produto de software.
3.4.1. Feature Driven Development
O Feature Driven Development (FDD), conhecido também em nosso idioma como
"Desenvolvimento Orientado à Funcionalidade", é um modelo de processo de
41
desenvolvimento de software orientado a objetos. Foi introduzido por Peter Coad e
colegas, e vem sendo ampliado e melhorado por Stephen Palmer e John Felsing,
sendo aprimorado para um processo de adaptação ágil que pode ser aplicado a
projetos de tamanho razoavelmente grande.
De acordo com Pressman (2010), o FDD adota uma filosofia que enfatiza a
colaboração entre pessoas em uma equipe FDD, gerencia problemas e
complexidades do projeto utilizando um recurso baseado em decomposição seguido
de integração de incrementos de software, e a comunicação de detalhes técnicos
utiliza meios verbais, gráficos e baseados em texto. Além disso, o FDD enfatiza
atividades de garantia de qualidade, incentivando uma estratégia de
desenvolvimento incremental com o uso de inspeções de projeto e de código,
aplicação de auditorias, coleta de métricas e uso de padrões de projeto.
No contexto do FDD, uma funcionalidade representa uma função do software
valorizada pelo cliente que pode ser implementada em duas semanas ou menos.
O FDD define cinco atividades em seu processo como mostra a Figura 9.
Figura 9: Processo de Desenvolvimento Orientado à Funcionalidade. Fonte: Palmer e Felsing (2002). Nota: Adaptado pelo autor.
Palmer e Felsing (2002) afirmam que o FDD utiliza os testes de software da mesma
forma como a atividade de teste é definida em processos tradicionais como o modelo
em cascata por exemplo. A diferença é dada pelo fato de, no processo incremental e
iterativo, a atividade de teste ser realizada após cada incremento ou após certo
número de iterações. O FDD pode usufruir dos seguintes tipos de teste, vistos no
capítulo anterior:
42
Teste Unitário;
Teste de Integração;
Teste de Sistema;
Teste de Aceitação.
3.4.2. Extreme Programming
Segundo Sommervile (2011), a Programação Extrema (XP), traduzido do inglês, é
um dos mais conhecidos e usados dos métodos ágeis. Esse nome, dado por Kent
Beck em 2000, foi definido dessa forma devido à abordagem empregar boas práticas
reconhecidas, tais como o desenvolvimento iterativo, ao nível "extremo".
De acordo com Pressman (2010), existem cinco valores que estabelecem a
fundação para todo o trabalho realizado como parte do XP. Cada um desses valores
é utilizado como guia para especificar atividades, ações e tarefas do XP. Os valores
são apresentados abaixo:
Comunicação: Para alcançar uma comunicação eficaz, o XP enfatiza a
colaboração informal entre clientes e desenvolvedores, com estabelecimento
de metáforas para comunicação de conceitos importantes, feedback contínuo
e evitar a documentação volumosa como um meio de comunicação.
Simplicidade: O XP restringe os desenvolvedores a projetar apenas para
necessidades imediatas, ao invés de considerar as necessidades futuras. A
intenção é criar um projeto simples que pode ser facilmente implementado em
código.
Feedback: O feedback é obtido basicamente de três formas:
o Através da concepção e implementação de uma estratégia de teste
eficaz, o software fornece resultados à equipe ágil. O XP faz uso do
teste unitário como a sua tática de teste primária. Com o
desenvolvimento de cada classe, a equipe escreve um teste unitário
para cada operação de acordo com a funcionalidade especificada.
43
o Com a entrega de um incremento do software ao cliente, as histórias
de usuário implementadas são utilizadas como base para testes de
aceitação. Ao grau em que o software implementa uma saída, o
comportamento da história é considerado uma forma de feedback.
o Ao derivar requisitos como parte do planejamento iterativo, a equipe
oferece ao cliente um feedback rápido em relação ao custo e impacto
sobre o cronograma.
Coragem: A adesão rigorosa a certas práticas XP exige coragem. Por
exemplo, existe muita pressão para projetar necessidades futuras. A maioria
das equipes de desenvolvimento sucumbe, argumentando que projetar para o
"futuro" vai economizar tempo e esforço a longo prazo. Uma equipe ágil de
XP deve ter a coragem para projetar para "hoje", reconhecendo que as
necessidades futuras podem mudar drasticamente, exigindo assim retrabalho
substancial de projeto e código implementado.
Respeito: Ao alcançar a entrega bem sucedida de incrementos de software, a
equipe desenvolve crescente respeito entre eles e os outros stakeholders.
Figura 10: Processo de desenvolvimento em Programação Extrema. Fonte: Pressman (2010). Nota: Adaptado pelo autor.
44
Shore e Warden (2008) afirmam que as equipes XP executam todas as atividades
de desenvolvimento de software simultaneamente. Análise, projeto, codificação,
testes e até mesmo a implantação pode ocorrer com certa freqüência. A Figura 10
ilustra essas atividades de desenvolvimento.
O XP faz isso através do trabalho em iterações, sendo que cada iteração representa
um incremento realizado em uma semana de trabalho. Toda semana, a equipe faz
um pouco de planejamento, um pouco de design, um pouco de codificação, um
pouco de testes, e assim por diante.
O trabalho é realizado sobre histórias de usuário, ou seja, durante a semana, a
equipe trabalha em todas as fases de desenvolvimento para cada história. No final
de uma semana, um incremento do software é lançado para análise interna, ou
diretamente em ambiente de produção.
Para a atividade de teste, Shore e Warden (2008) afirmam que cada membro do
time XP faz sua própria contribuição para garantir a qualidade do software.
Os programadores providenciam a primeira linha de defesa através de testes
unitários e testes de integração.
Os Testes de aceitação são especificados pelo cliente e baseados em
características e funcionalidades do sistema que são visíveis pelo cliente (caixa
preta). Os testes de aceitação são derivados das histórias de usuários
implementadas como parte de um determinado lançamento do software
(PRESSMAN, 2010).
Por fim, os testadores ajudam a equipe de desenvolvimento a descobrir se os seus
esforços estão sendo de fato voltados à produção de código de alta qualidade. Isso
é realizado através de testes exploratórios que buscam surpresas e falhas no
software. Quando os testadores encontram e reportam falhas, a equipe realiza
análise da causa do defeito e considera como melhorar o seu processo para evitar
que erros similares ocorram no futuro (SHORE; WARDEN, 2008).
45
Os testadores também exploram características não-funcionais do software, tais
como o desempenho e estabilidade. Os clientes, em seguida, podem usar essas
informações para decidir criação ou modificação de histórias.
3.4.3. Scrum
De acordo com Pressman (2010), o Scrum, cujo nome é derivado de uma atividade
que ocorre durante uma partida de rugby, é um método de desenvolvimento ágil de
software que foi concebido por Jeff Sutherland e sua equipe de desenvolvimento no
início de 1990. Nos últimos anos, o andamento do desenvolvimento dos métodos
Scrum tem sido realizado por Ken Schwaber e Mike Beedle.
Segundo Sommerville (2011), o Scrum é um método de desenvolvimento ágil que
foca na gestão de desenvolvimento iterativo ao invés de abordagens técnicas
específicas para engenharia de software ágil. A Figura 11 apresenta o processo de
desenvolvimento Scrum. O Scrum não prescreve a utilização de práticas de
programação, como programação em pares e testes durante desenvolvimento. Ele
pode ser usado em conjunto com outras abordagens ágeis, como XP, fornecendo
uma estrutura de gerenciamento para o projeto.
Figura 11: Processo Scrum. Fonte: Pressman (2010). Nota: Adaptado pelo autor.
46
O time Scrum é composto pelo scrum master (mestre Scrum), o product owner
(proprietário do produto) e o time de desenvolvimento, sendo referido simplesmente
como "o time". O time deve possuir todas as habilidades necessárias para a
construção de um produto de software, tais como a coleta de requisitos, análise,
projeto, codificação e teste (PHAM; PHAM, 2011).
O scrum master é caracterizado por Pichler (2010) como o membro do time Scrum
que dá suporte ao product owner e ao time, protege o time e o processo, e intervém
de forma adequada quando necessário para garantir que o ritmo de trabalho seja
sustentável, que a equipe se mantenha saudável e motivada, e que nenhum débito
técnico ocorra.
O product owner é responsável por tomar nota de entradas para o software dos
diferentes stakeholders, ou dos usuários que os representam, para elaborar uma
lista de requisitos que resultará no product backlog (PHAM; PHAM, 2011).
O product backlog é uma lista priorizada de requisitos, que pode incluir tudo, desde
características do negócio até questões técnicas para correções de defeitos.
Os sprints consistem em unidades de trabalho que são necessárias para alcançar
um ou mais requisitos definidos no product backlog. Um sprint deve se encaixar em
um período de tempo pré-definido, sendo usualmente utilizado o valor de trinta dias
(PRESSMAN, 2010).
Alterações em itens do product backlog não são introduzidas durante o Sprint. Isso
permite que os membros da equipe possam trabalhar em um ambiente de curto
prazo, porém de forma estável.
No início de cada sprint, o time Scrum se reúne para fazer seu planejamento.
Durante a primeira metade do encontro, o time discute os itens de alta prioridade do
product backlog. Comunicação eficaz é essencial para o time entender o product
owner e as expectativas dos stakeholders para esses itens. A discussão pode incluir
esboços de alto nível para ajudar o time a entender a visão do product owner. Na
segunda metade do encontro, o time Scrum foca no product backlog para identificar
as histórias de usuário da lista às quais se comprometerá a completar durante o
sprint. Para cada história de usuário, o time irá detalhar todas as tarefas, incluindo a
47
revisão de arquitetura, desenvolvimento, teste, documentação do usuário final, e
outras (WOODWARD; SURDEK; GANIS, 2010).
No início de cada dia do sprint, o time se reúne para uma "Daily Scrum" (reunião
diária Scrum), onde cada membro do time responde a basicamente três perguntas:
O que você fez ontem? O que você vai fazer hoje? Você tem algum impedimento?
No final do sprint, o time demonstra código em funcionamento para cada história de
usuário completada durante o sprint para o product owner e para os stakeholders. O
time não mostra histórias do sprint que não foram concluídas, em vez disso, eles as
movem de volta para o product backlog. O product owner definirá nova prioridade
para essas histórias, e o time terá a chance de terminar o trabalho no sprint
seguinte.
Após a demonstração, o time se reúne para refletir sobre o sprint e identificar
caminhos que podem ser melhorados. Nessa reunião é feita uma reflexão sobre o
que correu de bom e de ruim. Além disso, a reunião de reflexão do sprint pode
contribuir na troca de experiências entre os membros do time.
48
CAPITULO 4 - TEST DRIVEN DEVELOPMENT
O Test Driven Development (TDD), do inglês Desenvolvimento Orientado à Teste, é
apontado por Pressman (2010) como uma tendência emergente em Engenharia de
Software.
O método foi criado por Kent Beck (mesmo criador do XP) em 2002, e abordado por
ele em sua obra "Test-Driven Development By Example" publicada pela Addison
Wesley em 2002.
O TDD ganhou a atenção recente em ambientes profissionais e tem feito incursões
iniciais no ensino de engenharia de software. Uma ampla gama de estudos
empíricos sobre o impacto do TDD em prática industrial e ambientes acadêmicos
dando provas convincentes de sua popularidade (MADEYSKI, 2010).
4.1. O QUE É O TDD?
Segundo Madeyski (2010), a característica chave do TDD é que os programadores
escrevem os testes antes de produzir o código que implementará as funcionalidades
do software, ou seja, antes que eles mudem o comportamento do código, eles
devem ter testes falhando para esse código.
De acordo com Sommerville (2011), o TDD foi introduzido como parte de outro
método ágil, o XP.
Pressman (2010) afirma que os requisitos para um componente de software servem
de base para a criação de uma série de casos de teste que exercitarão a interface e
tentarão encontrar erros nas estruturas de dados e funcionalidades entregues pelo
componente. Nesse caso o TDD pode ser visto como uma tendência que enfatiza a
produção dos casos de teste antes da criação do código fonte do software.
O feedback dos desenvolvedores é que TDD é uma abordagem muito valiosa,
segundo Watkins (2009). A necessidade de entender os requisitos em detalhes para
ser capaz de projetar testes e mostrar que o código atende aos requisitos antes de
49
implementar o código ajuda os desenvolvedores a ganharem uma compreensão
completa dos requisitos.
Alguns desenvolvedores, ainda segundo Watkins (2009), expressam a visão de que
TDD pode atrasá-los e reduzir a sua produtividade. Na prática, houve redução na
produtividade do desenvolvedor, mas não se mostrou muito significativa. Em
contrapartida houve uma melhoria mensurável na qualidade do código produzido,
em termos de requisitos de adequação, bem como na entrega de código com menos
defeitos.
4.2. CICLO DE VIDA DO TDD
A Figura 12 apresenta o ciclo de vida de desenvolvimento utilizando o TDD.
Figura 12: Ciclo de vida do TDD. Fonte: Pressman (2010). Nota: Adaptado pelo autor.
Sommerville (2011) descreve os passos no processo de desenvolvimento TDD como
segue:
50
1. O primeiro passo é identificar o incremento de funcionalidade desejado pelo
cliente. Deve ser normalmente pequeno e implementável em poucas linhas de
código.
2. Escreve-se um teste para esta funcionalidade através de ferramentas ou
bibliotecas para automatização de testes. Com isso o teste pode ser
executado reportando se foi bem sucedido ou não.
3. Executa-se o novo teste em conjunto com todos os outros testes já
implementados. O novo teste irá falhar devido ao fato da funcionalidade ainda
não ter sido implementada.
4. Implementa-se a funcionalidade e executa o teste novamente. Isso pode
envolver refatoração do código existente para melhorá-lo e adição de novos
códigos aos que já foram implementados.
5. Uma vez que todos os testes tenham sido executados com êxito, procura-se
por uma nova funcionalidade, caso haja, afim de iniciar o processo
novamente.
Pressman (2010) diz que, durante a execução do TDD, o código é desenvolvido em
incrementos muito pequenos, geralmente uma sub-função da funcionalidade de
cada vez, sendo que nenhum código deve ser escrito até que exista um teste para
exercitá-lo. Deve-se notar que cada iteração resulta em um ou mais novos testes
que são adicionados a um conjunto de testes de regressão que é executado com
todas as mudanças. Isto é feito para garantir que o novo código não gerou efeitos
colaterais, causando defeitos no código já existente.
Alguns benefícios, de acordo com Sommerville (2011), podem ser observados ao
utilizar o TDD, sendo estes:
Cobertura de código: Em princípio, todos os segmentos de código escritos
devem ter pelo menos um teste associado. Portanto, pode-se dizer que a
maior parte do código no sistema foi realmente executada. O código é testado
da forma como está escrito, assim defeitos são descobertos no início do
processo de desenvolvimento.
51
Testes de regressão: A suíte de testes é desenvolvida de forma incremental
como o programa é desenvolvido. Pode-se sempre executar testes para
verificar se mudanças no software não introduziram novos defeitos.
Simplificação da depuração: Quando um teste falha fica óbvio onde está o
problema. Não sendo necessário usar ferramentas de depuração para
localizar o problema.
Documentação do sistema: Os próprios testes atuam como uma forma de
documentação que descreve o que o código deveria fazer. A leitura dos testes
pode tornar mais fácil a compreensão do código.
4.3. TIPOS DE TESTES UTILIZADOS NO TDD
O TDD pode utilizar os tipos de teste descritos abaixo como parte integrante do seu
processo de desenvolvimento de software.
4.3.1. Teste Unitário
O teste unitário representa a tecnologia de frente para os testes que suportam
programação. Aqueles que são desenvolvidos como parte do TDD, sendo que não
só ajudam o programador começar a história direito, mas também ajudam a projetar
o sistema (CRISPIN; GREGORY, 2009).
4.3.2. Teste de Integração
Segundo Shore e Warden (2008), o código a ser desenvolvido pode necessitar se
comunicar com elementos externos como banco de dados, sistemas em rede,
sistemas de arquivos e outros.
O TDD pode ser utilizado para esse tipo de código também, e o tipo de teste usado
para este fim é o teste de integração.
4.3.3. Teste de Aceitação
Obviamente, o teste de aceitação não é possível executar sem possuir a
implementação do software ou funcionalidade deste software, pois se trata de um
52
teste de caixa preta. Não é possível executar teste de caixa preta sem possuir a
caixa, porém, em seus estudos, Crispin e Gregory (2009) afirmaram que os testes de
aceitação podem ser, ao menos, derivados e descritos antes de implementar o
código.
Ao transmitir as descrições de critérios de aceitação aos desenvolvedores, antes de
começarem a produzir o código, ajudou-os a compreender melhor as
funcionalidades do sistema. Além disso, os critérios de aceitação guiaram a equipe a
produzir códigos que melhor confrontariam as necessidades do cliente.
4.4. EXEMPLO SIMPLES DE UTILIZAÇÃO DO TDD
Para mostrar um exemplo de utilização do TDD será usada a linguagem de
programação Java em conjunto com o JUnit para implementação de teste unitário.
O JUnit é um framework que foi iniciado por Kent Beck e Erich Gamma no final de
1995. Desde então, sua popularidade vem crescendo, sendo hoje o padrão para
aplicações de testes unitários em Java (TAHCHIEV et al., 2011)..
O exemplo, retirado da obra de Beck (2002) e adaptado pelo autor, aborda uma
história de usuário simples que consiste em criar uma classe para controle de
dinheiro. O objetivo do exemplo é testar um método de multiplicação para a classe
Real.
Segundo o que foi estudado sobre o TDD, deve-se primeiro construir o teste antes
de implementar qualquer código para a história. A figura 13 apresenta a
implementação do teste.
53
Figura 13: Implementação do teste para o método vezes. Fonte: Beck (2002). Nota: Adaptado pelo autor.
Neste ponto há um teste no software que está falhando. Porém, ainda não se pode
rodar o teste, pois não é possível compilar o sistema enquanto a classe Dinheiro não
existir. Então deve-se criar a classe de tal maneira que se possa ao menos compilar
o sistema. A Figura 14 apresenta a implementação preliminar da classe Dinheiro.
Figura 14: Implementação da classe Dinheiro. Fonte: Beck (2002). Nota: Adaptado pelo autor.
54
Agora o sistema pode ser compilado normalmente e o teste pode ser executado.
Mas o método "vezes", o qual se deseja testar, foi implementado com o objetivo
apenas de fazer com que o teste possa ser executado.
Ao executar o teste, o JUnit alertará que há um teste que não passou, reportando
qual o teste e quais assertações dele que não obtiveram sucesso. O TDD sugere
que os testes que estão falhando sejam refatorados o mais brevemente possível
(BECK, 2002). O método refatorado é apresentado pela Figura 15.
Figura 15: Método vezes refatorado. Fonte: Beck (2002). Nota: Adaptado pelo autor.
Isso fará com que o teste seja executado sem falhas e com isso a história de usuário
pode ser dada como concluída. Pelo ciclo de vida do TDD, esse é o ponto em que
se busca por mais histórias de usuário para serem implementadas.
55
CAPITULO 5 - CONCLUSÃO
Durante os primeiros contatos com a metodologia de desenvolvimento ágil, pode ser
comum experientes programadores, arquitetos, testadores, gerentes de projeto e
outros stakeholders não olharem com bons olhos para os paradigmas e princípios
definidos pelo Manifesto Ágil.
Já os futuros desenvolvedores, que estão sendo lançados recentemente pelas
academias de computação e engenharia de software, e mesmo os que ainda estão
cursando, podem acabar formando opiniões erradas sobre o desenvolvimento ágil
pelo fato de, em muitos casos, não saberem como é difícil desenvolver software sem
um processo de desenvolvimento definido.
Nos primeiros contatos com o desenvolvimento ágil, os desenvolvedores podem
confundir esta metodologia, justamente com a falta de metodologia. Principalmente
ao encarar o segundo item do manifesto que diz: Software em funcionamento mais
do que documentação abrangente.
Os desenvolvedores da antiga academia podem acabar vendo o desenvolvimento
ágil como um risco ao se desenvolver o software deixando a documentação como
segundo plano. Já os novos desenvolvedores podem acabar pensando em
desenvolver software sem documentação nenhuma, usando o manifesto como
desculpa para isso.
Se o desenvolvimento ágil fosse realmente a falta de metodologia e documentação
precária, como ficariam os testes de software?
Chega-se a esta questão, pois o estudo sobre os testes apresentado neste trabalho
mostrou que os testes são extremamente dependentes da documentação produzida
e são eles que garantem que o software funciona e encontra-se em conformidade
com sua especificação de requisitos.
Com o estudo apresentado neste trabalho sobre o desenvolvimento ágil e alguns de
seus métodos mais utilizados, chega-se à conclusão de que o desenvolvimento ágil
não significa desenvolver sem regras, muito pelo contrário, existem as regras e as
56
recomendações que devem ser seguidas para uma organização ser considerada
como ágil.
O método ágil, ao ser comparado com métodos tradicionais e burocráticos de
desenvolvimento, se apóia no fato de que o software deve ser entregue
continuamente em uma seqüência de funcionalidades priorizadas pelo próprio
cliente, de modo a responder rapidamente a mudanças, ajudando o cliente a adquirir
vantagem em seu negócio, conquistando cada vez mais a sua confiança.
Quanto à documentação, o estudo mostra que o desenvolvimento ágil “recomenda”
a produção de documentos que realmente serão utilizados durante o
desenvolvimento. Nesse caso a organização de desenvolvimento deve ser
disciplinada na escolha dos documentos que irá utilizar.
Portanto, se a organização sentir a necessidade de produzir uma documentação que
facilitará a produção dos testes necessários para que o software entre em
conformidade com o desejo do cliente, então essa documentação pode ser
produzida.
Em alguns aspectos, o desenvolvimento ágil assemelha-se com métodos de
desenvolvimento tradicionais. Quando a especificação do software é decomposta em
várias histórias de usuário, cada uma dessas histórias acaba por ser desenvolvida
em um modelo muito próximo do modelo cascata. Porém, histórias de usuário
representam porções muito pequenas do sistema como um todo.
57
REFERÊNCIAS
BECK, K. Test-driven development by example. Boston: Addison Wesley, 2002. COHN, M. User stories applied: for agile software development. Boston: Addison Wesley, 2004. CRISPIN, L.; GREGORY, J. Agile testing: a practical guide for testers and agile teams. Boston: Addison Wesley, 2009. FUTRELL, R. T.; SHAFER, D. F.; SAFER, L. I. Quality software project management. Upper Saddle River: Prentice Hall, 2002. GRAHAM, D.; BLACK, R.; EVANS, I.; VEENENDAAL, E. Foundations of software testing. Stamford: Cengage Learning Business Press, 2006. HUMBLE, J.; FARLEY, D. Continuous delivery. Boston: Addison-Wesley, 2010. JONES, C.; BONSIGNOUR, O. The economics of software quality. Boston: Addison-Wesley, 2011. KANDT, R. K. Software engineering quality practices. Boca Raton: Auerbach Publications, 2006. LEFFINGWELL, D. Agile software requirements: lean requirements practices for teams, programs, and the enterprise. Boston: Addison-Wesley, 2011. LEWIS, W. E. Software testing and continuous quality improvement. 3. ed. Boca Raton: CRC Press, 2009. MADEYSKI, L. Test-driven development: an empirical evaluation of agile practice. Berlin: Springer, 2010. MANIFESTO. Manifesto ágil, 2001. Disponível em: <http://agilemanifesto.org>. Acesso em: 23 nov. 2011.
58
MYERS, G. J. The art of software testing. 2. ed. Hoboken: Wiley, 2004. NAIK, K.; TRIPATHY, P. Software testing and quality assurance: theory and practice. Hoboken: Wiley, 2008. PALMER, S. R.; FELSING, J. M. A Practical guide to feature-driven development. Upper Saddle River: Prentice Hall, 2002. PATTON, R. Software testing. Indianapolis: Sams Publishing, 2005. PHAM, A.; PHAM, P. Scrum in action: agile software project management and development. Stamford: Cengage Learning Business Press, 2011. PICHLER, R. Agile product management with scrum: creating products that customers love. Boston: Addison-Wesley, 2010. PRESSMAN, R. S. Software engineering: a practitioner's approach. 7. ed. New York City: McGraw-Hill, 2010. RASMUSSON, J. The agile samurai: how agile masters deliver great software. Raleigh: The Pragmatic Bookshelf, 2010. RÜPING, A. Agile documentation: a pattern guide to producing lightweight documents for software projects. Hoboken: Wiley, 2003. SHORE, J.; WARDEN, S. The art of agile development. Sebastopol: O'Reilly, 2008. SOMMERVILLE, I. Software engeneering. 9. ed. Boston: Addison-Wesley, 2011. SPILLNER, A.; LINZ, T.; SCHAEFER, H. Software testing foundations: a study guide for the certified tester exam. Kingston: Rocky Nook, 2007. TAHCHIEV, P.; LEME, F.; MASSOL, V.; GREGORY, G. JUnit in action. 2. ed. Greenwich: Manning, 2011.
59
TIAN. J. Software quality engineering: testing, quality assurance, and quantifiable improvement. Hoboken: Wiley, 2005. WATKINS, J. Agile testing: how to succeed in an extreme testing environment. Cambridge: Cambridge University Press, 2009. WOODWARD, E.; SURDEK, S.; GANIS, M. A Practical guide to distributed scrum. Upper Saddle River: IBM Press, 2010.