ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE SISTEMAS GUSTAVO KATAOKA

Transcrição

1 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

2 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

3 GUSTAVO KATAOKA USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL Monografia aprovada em... de... de Banca Examinadora CAMPO GRANDE MS 2012

4 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.

5 SUMÁRIO CAPITULO 1 - INTRODUÇÃO JUSTIFICATIVA OBJETIVOS Objetivo geral Objetivos específicos DELIMITAÇÃO DO TRABALHO METODOLOGIA ORGANIZAÇÃO DO TRABALHO... 9 CAPITULO 2 - TESTE DE SOFTWARE VALIDAÇÃO DE REQUISITOS QUALIDADE DE SOFTWARE ATRAVÉS DE TESTES DEFINIÇÕES DO QUE OS TESTES PODEM IDENTIFICAR Falha Falta Erro Defeito VALIDAÇÃO E VERIFICAÇÃO VISÃO GERAL DAS TÉCNICAS DE TESTE DE SOFTWARE Testes de caixa branca Testes de caixa preta Testes de caixa cinza FASES DE TESTE DE SOFTWARE Teste Unitário Teste de Integração Teste de Sistema Teste de Aceitação CONSIDERAÇÕES SOBRE O CAPÍTULO CAPITULO 3 - DESENVOLVIMENTO ÁGIL PLANEJAMENTO NO DESENVOLVIMENTO ÁGIL ESTIMANDO AS HISTÓRIAS DE USUÁRIO Planning Poker... 36

6 3.3. EXECUÇÃO DO PLANEJAMENTO MÉTODOS ÁGEIS Feature Driven Development Extreme Programming Scrum CAPITULO 4 - TEST DRIVEN DEVELOPMENT O QUE É O TDD? CICLO DE VIDA DO TDD TIPOS DE TESTES UTILIZADOS NO TDD Teste Unitário Teste de Integração Teste de Aceitação EXEMPLO SIMPLES DE UTILIZAÇÃO DO TDD CAPITULO 5 - CONCLUSÃO REFERÊNCIAS... 57

7 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,

8 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 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 OBJETIVOS Os objetivos estabelecidos para esse estudo foram definidos conforme apresentado a seguir.

9 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 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 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 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.

10 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.

11 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 bugs 1, é 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.

12 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) 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 stakeholders 2 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).

13 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 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:

14 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.

15 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

16 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 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 Falha A incapacidade de um sistema ou componente para executar suas funções requeridas dentro de requisitos de desempenho especificados (TIAN, 2005) 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) 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).

17 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.

18 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).

19 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 baluarte 3 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.

20 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.

21 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) 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 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

22 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.

23 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) 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;

24 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 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 caixacinza é 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

25 24 desenvolvedor e entende o design interno e arquitetura, muitos testes serão eliminados, pois a funcionalidade será testada apenas uma única vez 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 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 referese 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).

26 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 subsistema 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

27 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 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

28 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) 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.

29 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) 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

30 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.

31 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

32 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 autoorganizáveis. 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

33 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 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.

34 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.

35 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:

36 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 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.

37 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.

38 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) 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.

39 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;

40 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

41 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 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 Feature Driven Development O Feature Driven Development (FDD), conhecido também em nosso idioma como "Desenvolvimento Orientado à Funcionalidade", é um modelo de processo de

42 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:

43 42 Teste Unitário; Teste de Integração; Teste de Sistema; Teste de Aceitação 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.

44 43 o 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. 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.

45 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).

46 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 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 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.

47 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

48 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.

49 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 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) 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

50 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 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: