Agilidade em Testes de Software: Um Relato de Experiência

Transcrição

1 Agilidade em Testes de Software: Um Relato de Experiência Ciro Grippi Barbosa Lima, Neilson Carvalho, Marcelo Santos de Mello, Guilherme Horta Travassos

2 Motivação Agenda Contexto Procedimentos para inserção de práticas ágeis Próximos Passos 2

3 Motivação

4 Motivação Estabelecimento de um corpo de conhecimento contendo os mapeamentos de práticas e características de agilidade para apoiar sua adoção em atividades de teste (Abrantes, 2012). Oportunidade de aplicação deste mapeamento em organização apresentando um processo de software definido, gerenciado e controlado avaliada no nível C do Modelo MPS_br. 4

5 Abrantes (2012) Caraterísticas Ágeis 1-"Being incremental" (Incrementalidade) 13- Emergence (Emergência)- 2-"Being cooperative" (cooperação) 14- Modularity (Modularidade 3-"Time-Boxing" (restrição de prazo) 15- Convergence (Convergência) 4-"Leaness" (Parcimônia) 16- Small Teams (Equipes Pequenas) 5-"Adaptability" (Adaptabilidade) 17- Constant Testing (Testes constantes) 6-"Being iterative" (Iteratividade) 18- Local Teams (Equipes Locais) 7- Being Collaborative (colaboração) 8-"Reflection and introspection" (Períodos de reflexão e introspecção) 9-"Feedback incorporation" ( Incorporação de Feed-back rápido ) 10-"Reflection and introspection" (Períodos de reflexão e introspecção) 11- Transparency (Transparência) 12- Auto-Organization (Auto-organização) 5

6 Abrantes (2012) Práticas Ágeis Práticas são as atividades que implementam os princípios que regem os processos ou métodos. Estes por sua vez, são ideias, entendimentos ou objetivos que estão por traz das práticas (Jiang e Armin, 2009). 51 práticas mapeadas. 17 consideradas mais relevantes em pesquisa de opinião. 1. Desenvolvimento orientado a testes 2. Integração contínua 3. Programação em par 4. Jogo de planejamento 5. Cliente presente 6. Propriedade coletiva do código 7. Releases curtas 8. Metáfora 9. Refatoração 10.Backlog de produto 11. Ritmo sustentável 12. Design simples 13. Padrões de código 14. Equipe completa 15. Visibilidade de projeto 16. Reuniões diárias 17. Espaço de trabalho aberto 6

7 Processo de Testes Adoção Processo de Teste Baseado IEEE 829 (Dias Neto, 2006). Planejar Testes Monitoramento, Controle e Replanejamento Projetar Testes Especificar Casos de Testes Definir Procedimentos de Testes Executar Testes Analisar Resultados dos Testes Encerrar Atividades de Testes Práticas 7

8 Mapeamento Atividades de Testes X Práticas Ágeis Revisão por Pares conduzida por Abrantes(2012) \Atividades Planejar Testes Projetar Testes Especificar CTs Definir Procedimentos Executar Testes Analisar Resultados Reuniões Diárias Liberações Frequentes Metáfora Equipe Completa Cliente Presente Design Simples Visibilida de Projeto Backlog de Produto Jogo de Planejamento Monitorar e Controlar o Processo de Teste 8

9 Trabalhos Anteriores - Práticas Ágeis e Atividades Testes Práticas Ágeis associadas às atividades de Teste de processo baseado na IEEE-829 [Dias Neto, 2006], [Abrantes, 2012]. Atividade Embasamento: os Jogos de Planejamento,.. Planejar Testes sendo contínuo e progressivo, com prioridades estabelecidas pelo cliente, pode apoiar o estabelecimento de um plano de testes alinhado com as necessidades do projeto. Projetar Testes com prioridades estabelecidas pelo cliente, pode apoiar o estabelecimento de prioridades no projeto de teste. Atividade Projetar Testes Especificar Casos de Teste Definir Procedimentos de Testes. Embasamento: o Design Simples, sem complexidade desnecessária... pode facilitar a identificação de casos e procedimentos de teste. pode facilitar a identificação de restrições e dependências com outros casos de teste. pode facilitar a identificação dos passos a serem seguidos durante os testes 9

10 Agilidades em Processos de Teste Aplicação no Campo - Processos específicos adequados ao contexto de cada Organização Atividades Atividade B Atividade D Atividade A Atividade C Atividade E Práticas 10

11 Contexto

12 Contexto das atividade de SW da Organização Visão da evolução através do estabelecimento de um programa de melhoria contínua. Ciclo 1 Ciclo 2 Ciclo 3 Nível G e Certificação ISO 9001 [2006/2007] Nível E [2007/2009] Nível C com Práticas do Scrum [2010/2011] Ciclos de Melhoria 12

13 Contexto das atividade de SW da Organização Processo de desenvolvimento padrão com 3 fases. Atividades de VER e VAL dispostas conjuntamente com atividades de PCP, ITP, GPR,GDE, MED, GCO, GQA, GRE e DRE : Especificação e Planejamento de Projeto (18 atividades) Análise Projeto e Construção de Software (31 atividades) Homologação e implementação (25 atividades) Processo especializado baseado no ciclo de vida incremental com adoção de práticas do método SCRUM. Iniciativas para ganho de produtividade no desenvolvimento: Utilização de linguagem dinâmica. Automatização de Testes. Projeto em curso para modelagem de Novos processos especializados para manutenção e desenvolvimento de pequenos aplicativos. 13

14 Procedimentos para inserção de Agilidade em Processos de Testes

15 Etapas, Atores e Instrumentos Abordagem baseada no paradigma de Melhoria Contínua (Basili, 1992) (1) Caracterização (2) Planejamento (3) Execução (4) Empacotamento. Atores envolvidos: Engenheiro de Software responsável pela introdução das práticas. Equipe responsável pelas melhorias nas atividades de desenvolvimento e testes ( Escritório de Projetos, Grupo de Qualidade, SEPG) Instrumentos necessários para execução: Processo de Teste baseado na IEEE-829 (Dias Neto, 2006). Planilha a ser preenchida para comparação entre as atividades de teste da Organização e processo de Teste baseado na IEEE-829. Mapeamento atividades de teste x Práticas de Agilidade (Abrantes,2012). Adoção de uma linguagem ou ferramenta para documentação do Processo de Teste da Organização e publicação na Intranet. 15

16 Caracterização

17 Documentação Atividades Processo Padrão (IEEE-829) e Atividades Teste e Desenvolvimento Organização Eclipse Process Framework 17

18 Comparação Atividades Processo Padrão (IEEE-829) e atividades de Testes da Organização Macroatividade Atividade Oportunidades de Melhoria (-)Planejar Testes Caracterizar Testes Pode apoiar a antecipação da determinação de riscos associados aos Testes. Pode subsidiar uma melhor determinação do esforço necessário para teste. [Convergência] (-)Projetar Testes Identificar Casos e Procedimentos de Testes Especificar CTs e definir procedimentos são realizados em uma única atividade. Pode apoiar a padronização de Projeto de Caso de Teste. [Modularidade] Inserção de atividade de Caracterização dos Testes na Fase 1 18

19 Entrevistas com as equipes de testes e SEPG Desenvolvimento de versões em paralelo (5350 CTs volume acumulado desde março de 2008 Fábrica de Software Ferramenta de GP). Merge das versões do produto 2 x por semana. TRAC para registro e monitoramento do tratamento das falhas encontradas. O projeto do Caso de Teste (CT) inicia somente após a especificação técnica. Na etapa de projeto analistas de testes relataram que passos já escritos anteriormente em outros releases são reescritos, gerando retrabalho. Testes funcionais executados manualmente. Não são adotadas técnicas de Testes. Não existe classificação de severidade de defeitos. 19

20 Entrevistas com as equipes de testes e SEPG Desenvolvimento de versões em paralelo (5350 CTs volume acumulado desde março de 2008 Fábrica de Software Ferramenta de GP). Merge das versões do produto 2 x por semana. TRAC para registro e monitoramento do tratamento das falhas encontradas. O projeto do Caso de Teste (CT) inicia somente após a especificação técnica. Na etapa de projeto analistas de testes relataram que passos já escritos anteriormente em outros releases são reescritos, gerando retrabalho. Testes funcionais executados manualmente. Não são adotadas técnicas de Testes. Não existe classificação de severidade de defeitos. 20

21 Entrevistas com as equipes de testes e SEPG Nome do Caso de Teste ID :: Test Case CT002 Verificar criação do form da geração do Dashboard de Projetos Pré-condição - Preparação massa de dados - Entradas Objetivo (Summary) - Passos Logar no sistema como Adm (testar também com outros usuários para verificar que somente pessoa com permissão Acessar todos os projetos tem acesso à geração do relatório. Ou seja, se a pessoa não tiver esta permissão não verá nem a opção Visões personalizadas) Cadastrar 1 projeto com 1 componente sem fim real Acessar Biblioteca >> Visões Personalizadas. Resultados esperados Exibição do formulário conforme protótipo disponível do documento de especificação técnica (página Dashboard de Projetos) 21

22 Seleção de práticas ágeis para adoção nas atividades de Testes da Organização \Atividades Reuniões Diárias Liberações Frequentes Metáfora Equipe Completa Cliente Presente Design Simples Visibilida de Projeto Backlog de Produto Jogo de Planejamento Planejar Testes Projetar Testes Especificar CTs Definir Procedimentos Executar Testes Analisar Resultados Monitorar e Controlar o Processo de Teste Já utilizada pela Organização Difícil adoção ou não aplicável Oportunidade 22

23 DESIGN SIMPLES Práticas ágeis selecionadas para o estudo Atividade Embasamento: a prática Observação Projetar Testes Especificar CTs Definir procedimentos Pode facilitar a identificação de casos e procedimentos de teste Pode facilitar a identificação de restrições e dependências com outros casos de teste Pode facilitar a identificação dos passos a serem seguidos nos testes Macro-Atividade dos CTs não seguia sequencia de atividades Processo Padrão Testes: Especificar CTs Definir Procedimentos Como consequência dados de entrada e pré-condições são codificadas nos CTs junto com os procedimentos dificultando o reuso dos Casos de Teste Estabelecimento de um padrão para projeto dos CTs!! 23

24 Sobreposição de Testes (ENGSTRÖM e RUNESON, 2012) Ausência de ferramentas que apoiem a visualização dos artefatos dos testes li 2 Clientes REQUISITOS FUNCIONAIS MUD101 Ctf0101_V Ctf MUD102 Ctf0201_V Ctf li 1 Sistema Gerencia Proj V01 REQUISITOS FUNCIONAIS RF-001 Casos de Uso UC-001 Ctf Ctf MUD2 Ctf Sistema Gerencia Proj V02 Sistema Gerencia Proj V03 REQUISITOS FUNCIONAIS MUD101 Ctf0101_V Ctf MUD102 Ctf0201_V Ctf REQUISITOS FUNCIONAIS MUD201 Ctf0103_V Ctf MUD202 Ctf0201_V Sistema Gerencia Proj V04 REQUISITOS FUNCIONAIS MUD301 Ctf Ctf MUD401 Ctf0201_V RELEASE 01 RELEASE 02 RELEASE 03 Tempo 24

25 VISIBILIDADE DE PROJETO Práticas ágeis selecionadas para o estudo Atividade Embasamento: a prática Observação Planejar Testes Melhorar a comunicação e auxiliar a elaboração de um plano de teste alinhado a realidade do projeto. Demanda de maior facilidade de recuperação e reuso de Casos de Testes entre versões do software. Projetar Testes/ Especificar Casos de Testes / Definir Procedimentos de Teste / Executar Testes / Analisar Resultados / Monitorar e Controlar o Processo de Teste Facilitar a integração das atividades de Testes com as de Desenvolvimento Implementação de novas formas de visualização dos Casos de teste!! 25

26 Planejamento 26

27 Atividades Documentação das mudanças sugeridas (Publicada na Intranet da Organização); Fornecimento de suporte para as mudanças sugeridas; Plano do Estudo de Caso Caracterização dos Participantes; Realização de Treinamento sobre material suporte; Geração de nova versão do Processo) 27

28 Fornecimento de material de apoio PADRÃO ATUAL Nome do Caso de Teste ID :: Test Case CT002 Verificar criação do form da geração do Dashboard de Projetos Pré-condição - Preparação massa de dados - Entradas Objetivo (Summary) - Passos Logar no sistema como Adm (testar também com outros usuários para verificar que somente pessoa com permissão Acessar todos os projetos tem acesso à geração do relatório. Ou seja, se a pessoa não tiver esta permissão não verá nem a opção Visões personalizadas) Cadastrar 1 projeto com 1 componente sem fim real Acessar Biblioteca >> Visões Personalizadas. Resultados esperados Exibição do formulário conforme protótipo disponível do documento de especificação técnica (página Dashboard de Projetos) 28

29 Caso de Teste Précondição Entradas Objetivo (Summary) Passos Resultados esperados Fornecimento de material de apoio ID :: Test Case CT002 Verificar criação do form da geração do Dashboard a) usuário cadastrado na base que possua permissão "Acessar todos os projetos" b) Projeto cadastrado com 1 componente sem fim real Projeto X ="Proj", Login Y="usuallProj", Senha S="usuallProj" Verificar se o formulário dashboard está visível. "Visões Personalizadas" 1-Autenticar login Y senha S 2- Selecionar o projeto X. 3- Abrir menu "Biblioteca" Opção "Visões Personalizadas" disponivel. 29

30 Caso de Teste Précondição Entradas Objetivo (Summary) Passos Resultados esperados Fornecimento de material de apoio ID :: Test Case CT002 Verificar criação do form da geração do Dashboard a) usuário cadastrado na base que possua permissão "Acessar todos os projetos" b) Projeto cadastrado com 1 componente sem fim real Projeto X ="Proj", Login Y="usuallProj", Senha S="usuallProj" Verificar se o formulário dashboard está visível. "Visões Personalizadas" 1-Autenticar login Y senha S 2- Selecionar o projeto X. 3- Abrir menu "Biblioteca" Opção "Visões Personalizadas" disponivel. Caso de Teste ID :: Test Case CT003 Verificar criação do form da geração do Dashboard Pré-condição a) usuário cadastrado na base que possua permissão "Acessar todos os projetos" b) Projeto cadastrado com 1 componente sem fim real Entradas Projeto X ="Proj", Login Y="usuallProj", Senha S="usuallProj" Objetivo (Summary) Passos Resultados esperados Verificar se o formulário dashboard está visível. "Visões Personalizadas" 1- Autenticar login Y senha S 2- Selecionar o projeto X. 3- Abrir menu "Biblioteca" Opção "Visões Personalizadas" disponível. 30

31 Fornecimento de material de apoio Organizando os elementos de um Caso de Teste 31

32 Fornecimento de material de apoio Desenvolvimento de um Editor de Casos de Testes 32

33 Editor de CTs Menu Procedimentos, Casos de Testes e Componentes 33

34 Editor de CTs Lista de Registro de Ocorrências de Testes 34

35 Editor de CTS Uso de Componentes (Rotina Preparação de dados p/ Pré-Condição ) 35

36 Editor de CTs Associação de componente à rotina de Pré-Condição 36

37 Editor de CTs Criação de Caso de Teste Recurso Auto Complete 37

38 Editor de CTs 38

39 Editor de CTs Rastreabilidade no sentido procedimentos -> Caso de Testes 39

40 Planejamento do Estudo de Caso. Objetivo: Observar a inserção das práticas ágeis Visibilidade de projeto e Design Simples através da proposição de mudanças nas atividades de projeto de teste, e adoção de um template para projeto e construção de Casos de Teste, com respeito ao favorecimento da visualização dos procedimentos e Casos de Testes e facilidade de projeto e reúso destes artefatos. Questões: Q1) Taxa de reutilização de procedimentos de Casos de Testes. Q2) O esforço dispendido nas atividades de Projeto e Construção dos Casos de Testes e procedimentos. Q3) O esforço dispendido na execução dos Casos de Testes. 40

41 Confounding Factors Características dos requisitos dos releases do software podem influenciar em baixa probabilidade de oportunidade de reuso; A forma escolhida para a implementação das práticas de Design Simples e Visibilidade de Projeto no projeto de Testes; Critério para classificação da complexidade dos Casos de Testes analisados; Tempo necessário para obter fluência no uso do template proposto, e efetividade do treinamento sobre o uso do template; Precisão dos registros de esforço dispendido em cada atividade; 41

42 Execução 42

43 Preparação para Execução do Piloto Aplicação Formulário de consentimento individual e de caracterização. Desenvolvimento material de treinamento do Editor e das mudanças no processo Instalação do Editor Seleção de procedimentos de CTs de releases anteriores para reescrita com adoção do template sugerido para avaliação de reuso Seleção e transformação em componentes de alguns procedimentos de verificação de pré-condições de CTs desenvolvidos originariamente com reincidência de uso em vários CTs. 43

44 Execução do Estudo de Caso Evento Atividades Descrição Participan tes Uso Processo de Teste Projeto e Construção de CTs de antes das mudanças Sistema para Gestão de propostas e uso da Projetos ferramenta TestLink. AT 1 Execução de CTs de Sistema para Gestão de Projetos Coleta dos esforços realizados e Procedimentos de CTs reutilizados Uso Processo de Teste antes das mudanças propostas e uso da ferramenta TestLink. Recuperação de dados de baselines nos repositórios de projetos da Organização TE PE 44

45 Evento 1 - Coleta dados de reuso de Procedimentos de CTs nos release A e B Abrangência procedimentos, rotinas de verificação de pré-condições e resultados esperados. Situações identificadas: CTs distintos com o mesmo nome, sugerindo serem responsáveis pelo mesmo conjunto de ações e no entanto apresentarem ações diferentes. Mesmo procedimento de CT sendo reutilizado em funcionalidades distintas, e a descrição do procedimento duplicada em cada CT. (REUSO) Utilizados esforços de projeto e construção por estória. Calculado esforço médio de projeto e execução de cada passo de cada estória. Esforço de projeto e execução de cada CT utilizou esforço médio e quantidade de passos do CT. 45

46 Evento 2 Treinamento Editor e Mudanças Processo Identificação Atividades Descrição Particip antes Treinamento Treinamento para uso AT, TE e do Template e do PE Editor EVENTO 2 Aplicação de Avaliação do formulário de Treinamento avaliação para AT e TE participantes Enfoque nos seguintes tópicos: Mudanças realizadas no processo padrão ; Novo template de projeto de CT; Diretrizes para identificação e Especificação de Cenários, CTs, Procedimentos e Pré- Condições de CTs; Funcionalidades da Ferramenta de Edição de CTs; 46

47 Evento 3 - Projeto e Construção de CTs c/ adoção das mudanças Identificação Atividades Descrição Participan tes Projeto e Construção de CTs Adoção do Processo de Testes de Sistema para Gestão de contendo mudanças sugeridas e Projetos Template baseado na especificação AT EVENTO 3 Execução de Casos de Testes de Sistema para Gestão de Projetos Coleta dos esforços realizados e Procedimentos de CTs reutilizados IEEE-829- Primeiro Ciclo Adoção do Processo de testes contendo mudanças sugeridas e Template baseado na especificação IEEE-829 Primeiro Ciclo Recuperação dados de Reuso e Esforços TE PE 47

48 Evento 3 - Categorização dos CTs Utilização de mediana ( 5 passos p/ CT ), primeiro quartil (3 passos p/ CT ) e terceiro quartil (8 Passos p/ CT ) Avaliados um Total de 499 Casos de Testes Categorização: Complexidade Baixa: Qtde Passos <= Primeiro Quartil Complexidade Média: Primeiro Quartil > Qtde de Passos <= Terceiro Quartil Complexidade Alta: Qtde de Passos > Terceiro Quartil Totalizadores Qtde Total de CTs produzidos Qtde CTs complexidade baixa Qtde CTs complexidade média Qtde CTs complexidade alta Release A Release B Consolidado de A e B Release C

49 Empacotamento 49

50 Avaliação e Análise Questão 1 - Reutilização de Procedimentos Release Categoria CT Total CTs A B C Mesmo procedimento Reuso CTS usando rotina pré-condição Total Reutilizações Reutilização / Total CTs Baixa ,35 Média ,02 Alta Baixa ,23 Média ,13 Alta Baixa Média ,85 Alta ,94 No release C reuso ocorreu tanto à nível de procedimento de execução do CT, como rotina de pré-condição. 50

51 Avaliação e Análise - Questão 2 - Esforço Projeto e Construção CTs Médias Rel. A Rel. B Média Releases A e B Release C Esforço médio Projeto CTs Baixa Complexidade (Min.) Esforço médio Projetar CTs Média Complexidade (Min.) Esforço médio Projetar CTs Alta Complexidade (Min.) 10,22 13,80 10,85-18,56 20,41 19,24 16,11 34,52 33,61 34,08 25,98 Esforços de retrabalho (replanejamento e re-teste) nos CTs decorrente de mudanças de requisitos não foram contabilizados separadamente e também podem constituir uma influência a ser avaliada; 51

52 Avaliação e Análise - Questão 3 - Esforço Execução CTs Médias Rel. A Rel. B Média Releases A e B Rel. C Esforço médio Execução CTs de Baixa Complexidade (Min) 4,16 6,62 4,59 - Esforço médio Execução CTs de Média Complexidade (Min) 9,67 13,03 10,90 7,50 Esforço médio Execução CTs de Alta Complexidade (Min) 17,76 13,52 15,74 12,41 Quantidade de CTs Quantidade de defeitos Melhor relação entre quantidade de CTs executados por quantidade de defeitos revelados no release C. 52

53 Avaliação Participantes Mudanças no Processo Antecipação atividade Planejar Testes para ser executada concorrentemente às atividades de Preparação da Integração do Produto e Especificação Técnica na fase de Análise, Projeto e Construção do Software. Pode trazer mais agilidade -> logo após a geração e validação do Documento de Requisitos, o projeto dos testes pode ser iniciado. (Gerente VVT) Equipe de testes tem atuação mais intensa nos projetos, diminui disponibilidade de alocação paralela. (Gerente Projetos ) Em relação à inserção da atividade Projetar testes do Produto pode promover um melhor projeto de Testes, por ajudar na priorização e identificação prévia dos CTs. 53

54 Avaliação dos Participantes Editor de CTs Contribuiu para o entendimento dos conceitos e definições das boas práticas para planejamento e realização de testes. Outro respondente contrapôs que a codificação de cada passo separadamente demanda um tempo de adequação pela equipe e costume. Uso de mapas para visualização da rastreabilidade apoiam a manutenção dos procedimentos dos CTs, e facilitam a recuperação dos CTs reutilizados um determinado procedimento. 54

55 Ameaças à Validade Fatores de riscos que não puderam ser mitigados: (a) Por conta de adiamentos solicitados pelos stakeholders não foi possível estender a observação para mais Sprints. (b)profissionais originariamente selecionados para participar do estudo foram alocados em outros projetos. (c) O lançamento no Time-Sheet dos esforços dispendidos pela organização não distinguem esforço associado ao projeto de testes daqueles decorrente de mudanças de requisitos. E nem o esforço gasto em teste do esforço de re-teste. 55

56 Próximos Passos Avaliação dos componentes criados pelo Processo de Gerencia de Reuso. Uso da ferramenta e Template nas próximas versões do software de GP. Incorporação do EPF para modelagem de processos. Nova coleta de dados de esforço e reuso do projeto em curso. Avaliação das propostas de evolução das medidas de Testes. 56

57 Referências ABRANTES J. F., (2012) Práticas e Características de Agilidade em Processos de Testes de Software, In UFRJ Tese de Doutorado, DIAS NETO, A. C., TRAVASSOS, G. H. (2006) Uma Infraestrutura Computacional para apoiar o planejamento e controle de testes de software Dissertação de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, DYBA T., DINGSØYR T., (2008) Empirical studies of agile software development: A systematic review Elsevier Science Direct, Information and Software Technology 50 (2008) ENGSTRÖM, E., RUNESON P., (2012) "Test overlay in an emerging software product line - An industrial case study, Inform. Software Technologies" (2012), GILB, T. (1985) Evolutionary Delivery versus the Waterfall Model In ACM SIGSOFT Software Engineering Notes Vol. 10 No 3 Jul IEEE Std (Revision of IEEE Std ). JIANG, LI. EBERLEIN, ARMIN. (2009), An Analysis of the History of Classical Software Development and Agile Development, In: IEEE International Conference on Systems, Man, and Cybernetics San Antonio, TX, USA October Persson, C., Yilmaztürk, N., (2004) Establishment of Automated Regression Testing at ABB: Industrial Experience Report on Avoiding the Pitfalls, 19th IEEE ICASE, SOFTEX, MPS. BR: Melhoria de Processo do Software Brasileiro- Guia Geral (v.2011). Disponível em: STOLBERG, S., "Enabling Agile Testing through Continuous Integration", In Agile Conference, 2009,

58 Agilidade em Testes de Software: Um Relato de Experiência Ciro Grippi Barbosa Lima, Neilson Carvalho, Marcelo Santos de Mello, Guilherme Horta Travassos