Post on 18-Mar-2021
Agilidade em Testes de Software: Um Relato de Experiência
Ciro Grippi Barbosa Lima, Neilson Carvalho, Marcelo Santos de Mello, Guilherme Horta Travassos
2
Agenda Motivação
Contexto
Procedimentos para inserção de práticas ágeis
Próximos Passos
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.
5
Caraterísticas Ágeis Abrantes (2012)
1-"Being incremental" (Incrementalidade) 2-"Being cooperative" (cooperação) 3-"Time-Boxing" (restrição de prazo) 4-"Leaness" (Parcimônia) 5-"Adaptability" (Adaptabilidade) 6-"Being iterative" (Iteratividade) 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)
13- “Emergence” (Emergência)- 14- “Modularity” (Modularidade 15- “Convergence” (Convergência) 16- “Small Teams” (Equipes Pequenas) 17- “Constant Testing” (Testes constantes) 18- “Local Teams” (Equipes Locais)
6
Práticas Ágeis Abrantes (2012)
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
7
Processo de Testes
Adoção Processo de Teste Baseado IEEE 829 (Dias Neto, 2006).
Planejar Testes
Projetar Testes
Especificar Casos de
Testes
Definir Procedimentos
de Testes
Analisar Resultados
dos Testes
Executar Testes
Monitoramento, Controle e
Replanejamento
Práticas
Encerrar Atividades de Testes
8
Mapeamento Atividades de Testes X Práticas Ágeis
Revisão por Pares conduzida por Abrantes(2012)
\Atividades
Reuniões Diárias
Liberações Frequentes
Metáfora Equipe Completa
Cliente Presente
Design Simples
Visibilidade 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
9
Trabalhos Anteriores - Práticas Ágeis e Atividades Testes
Atividade Embasamento: o Design Simples, sem complexidade desnecessária ...
Projetar Testes pode facilitar a identificação de casos e procedimentos de teste.
Especificar Casos de Teste
pode facilitar a identificação de restrições e dependências com outros casos de teste.
Definir Procedimentos de Testes.
pode facilitar a identificação dos passos a serem seguidos durante os testes
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.
Práticas Ágeis associadas às atividades de Teste de processo baseado na IEEE-829 [Dias Neto, 2006], [Abrantes, 2012].
10
Agilidades em Processos de Teste Aplicação no Campo - Processos específicos adequados ao contexto de cada Organização
Atividade A
Atividade B
Atividade C
Atividade E
Atividade D
Atividades
Práticas
Contexto
12
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]
Contexto das atividade de SW da Organização
Ciclos de Melhoria
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.
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.
Caracterização
17
Documentação Atividades Processo Padrão (IEEE-829) e Atividades Teste e Desenvolvimento Organização
Eclipse Process Framework
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
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 .
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 .
21
Entrevistas com as equipes de testes e SEPG
Nome do Caso de Teste ID 24292 :: 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)
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
Visibilidade 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
23
Práticas ágeis selecionadas para o estudo
DES
IGN
SIM
PLE
S Atividade Embasamento: a prática Observação
Projetar Testes Pode facilitar a identificação de casos e procedimentos de teste
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
Especificar CTs Pode facilitar a identificação de
restrições e dependências com
outros casos de teste
Definir procedimentos
Pode facilitar a identificação dos passos a serem seguidos nos testes
Estabelecimento de um padrão para projeto dos CTs !!
24
Sobreposição de Testes (ENGSTRÖM e RUNESON, 2012)
Ausência de ferramentas que apoiem a visualização dos artefatos dos testes
REQUISITOS FUNCIONAIS RF-001 Casos de Uso UC-001 Ctf0101 ----------- Ctf0102 ----------- MUD2 Ctf0201 -----------
Sistema Gerencia Proj V01 Sistema Gerencia Proj V02 Sistema Gerencia Proj V03
REQUISITOS FUNCIONAIS MUD101 Ctf0101_V02 ---------- Ctf0103 ---------- MUD102 Ctf0201_V02 ---------- Ctf0202 -------------
REQUISITOS FUNCIONAIS MUD201 Ctf0103_V01 ---------- Ctf0105 ---------- MUD202 Ctf0201_V02 ---------
REQUISITOS FUNCIONAIS MUD301 Ctf0106 ---------- Ctf0107 ---------- MUD401 Ctf0201_V03 ----------
Sistema Gerencia Proj V04
Tempo RELEASE 01 RELEASE 02 RELEASE 03
Clientes
Cli 1
Cli 2 REQUISITOS FUNCIONAIS MUD101 Ctf0101_V02 ---------- Ctf0103 ---------- MUD102 Ctf0201_V02 ---------- Ctf0202 -------------
25
Práticas ágeis selecionadas para o estudo V
ISIB
ILID
AD
E
DE
PR
OJE
TO
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 !!
26
Planejamento
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)
28
Fornecimento de material de apoio PADRÃO ATUAL
Nome do Caso de Teste ID 24292 :: 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)
29
Fornecimento de material de apoio
Caso de
Teste
ID 24292 :: Test Case CT002 –
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)
Verificar se o formulário
dashboard está visível.
"Visões Personalizadas"
Passos 1-Autenticar login Y senha S
2- Selecionar o projeto X.
3- Abrir menu "Biblioteca"
Resultados
esperados
Opção "Visões
Personalizadas" disponivel.
30
Fornecimento de material de apoio
Caso de
Teste
ID 24292 :: Test Case CT002 –
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)
Verificar se o formulário
dashboard está visível.
"Visões Personalizadas"
Passos 1-Autenticar login Y senha S
2- Selecionar o projeto X.
3- Abrir menu "Biblioteca"
Resultados
esperados
Opção "Visões
Personalizadas" disponivel.
Caso de Teste ID 24293 :: 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)
Verificar se o formulário
dashboard está visível.
"Visões Personalizadas"
Passos 1- Autenticar login Y senha S
2- Selecionar o projeto X.
3- Abrir menu "Biblioteca"
Resultados
esperados
Opção "Visões
Personalizadas" disponível.
31
Fornecimento de material de apoio
Organizando os elementos de um Caso de Teste
32
Fornecimento de material de apoio
Desenvolvimento de um Editor de Casos de Testes
33
Editor de CTs
Menu Procedimentos, Casos de Testes e Componentes
34
Editor de CTs
Lista de Registro de Ocorrências de Testes
35
Editor de CTS Uso de Componentes (Rotina Preparação de dados p/ Pré-Condição )
36
Editor de CTs
Associação de componente à rotina de Pré-Condição
37
Editor de CTs
Criação de Caso de Teste – Recurso Auto Complete
38
Editor de CTs
39
Editor de CTs
Rastreabilidade no sentido procedimentos -> Caso de Testes
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.
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;
42
Execução
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.
44
Execução do Estudo de Caso
Evento Atividades Descrição
Participantes
1
Projeto e Construção de CTs de Sistema para Gestão de
Projetos
Uso Processo de Teste antes das mudanças propostas e uso da
ferramenta TestLink.
AT
Execução de CTs de Sistema para Gestão de Projetos
Uso Processo de Teste antes das mudanças propostas e uso da
ferramenta TestLink.
TE
Coleta dos esforços realizados e Procedimentos de CTs
reutilizados
Recuperação de dados de baselines nos repositórios
de projetos da Organização
PE
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.
46
Evento 2 – Treinamento Editor e Mudanças Processo
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;
Identificação Atividades Descrição
Participantes
EVENTO 2
Treinamento Treinamento para uso
do Template e do Editor
AT, TE e PE
Avaliação do Treinamento
Aplicação de formulário de avaliação para participantes
AT e TE
47
Evento 3 - Projeto e Construção de CTs c/ adoção das mudanças
Identificação Atividades Descrição
Participantes
EVENTO 3
Projeto e Construção de CTs de Sistema para Gestão de
Projetos
Adoção do Processo de Testes contendo mudanças sugeridas e
Template baseado na especificação IEEE-829- Primeiro Ciclo
AT
Execução de Casos de Testes de Sistema para Gestão de
Projetos
Adoção do Processo de testes contendo mudanças sugeridas e
Template baseado na especificação IEEE-829 – Primeiro Ciclo
TE
Coleta dos esforços realizados e Procedimentos
de CTs reutilizados
Recuperação dados de Reuso e Esforços
PE
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 Release A Release B Consolidado
de A e B Release C
Qtde Total de CTs produzidos
231 100 331 168
Qtde CTs complexidade baixa
103 22 125 0
Qtde CTs complexidade média
117 68 185 41
Qtde CTs complexidade alta
11 10 21 127
49
Empacotamento
50
Avaliação e Análise Questão 1 - Reutilização de Procedimentos
No release C reuso ocorreu tanto à nível de procedimento de execução do CT, como rotina de pré-condição.
Release Categoria CT Total CTs Mesmo
procedimento
Reuso CTS usando rotina pré-condição
Total Reutilizações
Reutilização/ Total CTs
A
Baixa 103 36 0 36 0,35
Média 117 2 0 2 0,02
Alta 11 0 0 0 0
B
Baixa 22 5 0 5 0,23
Média 68 9 0 9 0,13
Alta 10 0 0 0 0
C
Baixa 0 0 0 0 0
Média 41 37 39 76 1,85
Alta 127 119 127 246 1,94
51
Avaliação e Análise - Questão 2 - Esforço Projeto e Construção CTs
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;
Médias Rel. A Rel. B Média Releases A e B Release C
Esforço médio Projeto CTs Baixa Complexidade (Min.)
10,22 13,80 10,85 -
Esforço médio Projetar CTs Média Complexidade (Min.)
18,56 20,41 19,24 16,11
Esforço médio Projetar CTs Alta Complexidade (Min.)
34,52 33,61 34,08 25,98
52
Avaliação e Análise - Questão 3 - Esforço Execução CTs
Melhor relação entre quantidade de CTs executados por quantidade de
defeitos revelados no release C.
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 231 100 331 168 Quantidade de defeitos 14 - - 35
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.
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.
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.
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.
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, 2012.
• 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, 2006.
• DYBA˚ T., DINGSØYR T., (2008) “Empirical studies of agile software development: A systematic review” Elsevier Science Direct, Information and Software Technology 50 (2008) 833–859
• ENGSTRÖM, E., RUNESON P., (2012) "Test overlay in an emerging software product line - An industrial case study, Inform. Software Technologies" (2012), http://dx.doi.org/10.1016/j.infsof.2012.04.009
• GILB, T. (1985) “Evolutionary Delivery versus the Waterfall Model” In ACM SIGSOFT Software Engineering Notes Vol. 10 No 3 Jul 1985.
• IEEE Std 829™-2008 (Revision of IEEE Std 829-1998).
• 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, 2004.
• SOFTEX, 2011. “MPS. BR: Melhoria de Processo do Software Brasileiro- Guia Geral (v.2011)”. Disponível em: http://www.softex.br/mpsbr
• STOLBERG, S., "Enabling Agile Testing through Continuous Integration", In Agile Conference, 2009, 2009
Agilidade em Testes de Software: Um Relato de Experiência
Ciro Grippi Barbosa Lima, Neilson Carvalho, Marcelo Santos de Mello, Guilherme Horta Travassos