Agilidade em Testes de Software: Um Relato de … · controlado avaliada no nível C do Modelo...

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


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


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


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


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


Caso de

Teste

ID 24292 :: Test Case CT002 –



Pré-

condição

a) usuário cadastrado na base







S="usuallProj"

Objetivo

(Summary)




Passos 1-Autenticar login Y senha S



Resultados

esperados

Opção "Visões

Personalizadas" disponivel.

Caso de Teste ID 24293 :: Test Case CT003 –



Pré-condição a) usuário cadastrado na base







S="usuallProj"

Objetivo

(Summary)




Passos 1- Autenticar login Y senha S



Resultados

esperados

Opção "Visões

Personalizadas" disponível.

31


Organizando os elementos de um Caso de Teste

32


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

http://dx.doi.org/10.1016/j.infsof.2012.04.009

http://dx.doi.org/10.1016/j.infsof.2012.04.009

http://www.softex.br/mpsbr

http://www.softex.br/mpsbr

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

Ciro Grippi Barbosa Lima, Neilson Carvalho, Marcelo Santos de Mello, Guilherme Horta Travassos

Agilidade em Testes de Software: Um Relato de … · controlado avaliada no nível C do Modelo...

Documents

Transcript of Agilidade em Testes de Software: Um Relato de … · controlado avaliada no nível C do Modelo...