centro universitário de araraquara núcleo de

Transcrição

CENTRO UNIVERSITÁRIO DE ARARAQUARA
NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
ESPECIALIZAÇÃO MBA EM GESTÃO DA QUALIDADE DE SOFTWARE (CMMI)
ANDRE LUIS DE ANDRADE
TESTADORES E PROGRAMADORES EM UM AMBIENTE DE
DESENVOLVIMENTO ÁGIL
ARARAQUARA / SÃO PAULO
2015
CENTRO UNIVERSITÁRIO DE ARARAQUARA
NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
ESPECIALIZAÇÃO MBA EM GESTÃO DA QUALIDADE DE SOFTWARE (CMMI)
Trabalho de Conclusão de Curso apresentado
como requisito parcial para a conclusão do
curso de Especialização em MBA em Gestão da
Qualidade de Software (CMMI)
Orientador(a): Prof. Esp. Carlos Alberto
Silva
ARARAQUARA / SÃO PAULO
2015
DECLARAÇÃO
Eu, Andre Luis de Andrade, declaro ser o(a) autor(a) do texto apresentado Trabalho de
Conclusão de Curso, no programa de pós-graduação lato sensu em (MBA em Gestão da
Qualidade de Software (CMMI)) com o título “ (Testadores e Desenvolvedores em um
Ambiente de Desenvolvimento Ágil)”.
Afirmo, também, ter seguido as normas da ABNT referentes às citações textuais que utilizei e
das quais eu não sou o(a) autor(a), dessa forma, creditando a autoria a seus verdadeiros
autores.
Através dessa declaração dou ciência de minha responsabilidade sobre o texto
apresentado e assumo qualquer responsabilidade por eventuais problemas legais, no tocante
aos direitos autorais e originalidade do texto.
Araraquara, ___ de _______ de ______.
_____________________________________
Assinatura do autor(a)
Trabalho de Conclusão de Curso apresentado
como exigência parcial para a finalização do
Curso de Especialização em MBA em Gestão
da Qualidade de Software (CMMI) pelo
Centro Universitário de Araraquara – Uniara.
Orientador(a): Prof. Carlos Alberto Silva
Data da defesa/entrega: ___/___/____
MEMBROS COMPONENTES DA BANCA EXAMINADORA:
Presidente e Orientador:
Membro Titular:
Membro Titular:
Média______
Centro Universitário de Araraquara
Araraquara- SP
Data: ___/___/____
Para todos que amo e serviram como inspiração e, àqueles que prezam por um mundo pacíf-ico em
que a qualidade das ações faça a diferença.
AGRADECIMENTOS
Este trabalho foi algo idealizado para auxiliar meus colegas a compreenderem melhor
o cotidiano dos profissionais de desenvolvimento e qualidade de software, estes os quais
foram muito importantes em meus dezoito anos de carreira com seus ensinamentos e
paciência a cada pergunta que fiz. Mas, as mais importantes inspirações para continuar os
estudos e jamais desistir nos tortuosos caminhos do destino, são: minha digníssima esposa
Fabiane, meus incríveis filhos Fabiane Victoria e Ricardo Augusto, meus pais e sogros que
sempre me auxiliaram quando preciso. É preciso acreditar que sempre é possível encontrar
um destino acima da expectativa, basta agradecer ao próximo e fazer tudo com muita
perseverança e com a maior qualidade possível.
“Trabalhar pela qualidade é uma lição de vida, deve ser algo intrínseco em cada um de nós a
fim de possibilitar uma vida melhor para todos.”, (Andre Luis de Andrade)
RESUMO
No ciclo de vida de desenvolvimento de software (SDLC) é preciso reconhecer o valor de
cada uma das etapas envolvidas durante o andamento de um projeto, desde seu planejamento
até a sua implementação. Por muitos anos os analistas não se utilizaram de ferramentas
formais de análise e controle deste ciclo, o que resultava em projetos desenvolvidos fora de
escopo, mesmo que parcialmente, não adequados ao prazo de entrega solicitado pelo cliente e
excedendo a um orçamento, provavelmente. Portanto, após alguns profissionais perceberem
este equivoco, nos anos 60 (século XX), o termo “engenharia de software” começou a ser
utilizado para certificar-se de que os projetos estavam seguindo sólidos princípios de
engenharia que respeitem critérios básicos durante as etapas de desenvolvimento de sistemas.
Nesta visão, iniciaram-se estudos de metodologias para a área, resultando inicialmente em
modelos tradicionais, tais como as metodologias estruturadas, evoluindo para as metodologias
em orientação a objetos e as metodologias de desenvolvimento Ágil. No primeiro modelo, sua
aplicação está relacionada com projetos complexos e que demandem uma organização mais
estrita, pois cada etapa de processo precisa ser finalizada para que a outra seja iniciada
(modelo em cascata, por exemplo). Entretanto, neste, o relacionamento entre as equipes é
limitado e não há o conhecimento e nem o reconhecimento sobre o que está sendo feito por
outrem. Deste modo, o foco da pesquisa em buscar o aprimoramento da integração entre
programadores e testadores tornar-se-ia inviável, fato que pode causar atrasos no projeto
devido a menor qualidade alcançada por defeitos que poderiam ter sido anteriormente
evitados. A partir disso, a metodologia Ágil tornou-se mais vantajosa e adequada para
projetos que exigem maior dinamismo e integração entre seus pares, já que desde o início o
cliente e as equipes de planejamento, desenvolvimento e qualidade estão a trabalhar unidos
pelo propósito principal, o sucesso, o respeito ao cronograma, ao orçamento e conquistar a
menor rejeição possível do usuário final. Os programadores precisam estar atentos à forma
Ágil de se realizar os testes de unidade e integração, seguindo o roteiro de testes com os
cenários prescritos para o sistema, transformando esta atividade no perfeito relacionamento
entre os profissionais responsáveis pela codificação e aqueles responsáveis por prezar pela
mitigação de riscos e redução de defeitos.
Palavras Chave: Qualidade de Software. Teste de Software. Metodologia Ágil. Testes Ágeis.
Desenvolvimento de Software. SDLC
ABSTRACT
In the software development life-cycle (SDLC) is necessary to recognize the value of each
steps involved during a project, since the planning step to implementing step. For years, the
analysts didn’t use formal tools to do analysis and take the control of this cycle, which results
in out of scope projects, even partially not appropriate to the schedule defined for the
customer and out of the budget. Therefore, after some professionals verifying this mistake in
the 60’s (XX century), the term “software engineering” started to be used to certified that the
projects are following the principles of the engineering, respecting the basic criterias during
the systems development steps. In this vision, the study of methodologies for the area has
been started, resulting in the firsts traditional models, such as structured methodologies,
evoluting to object oriented methodologies and the Agile development methodologies. In the
first model, its application is related with projects with high level of complexity and that need
a more strict organization, because each step of this process must be concluded to another be
started (waterfall model, for example). However, in this model, the relationship between the
teams are limited and have no knowledge and no recognition about what is being doing for
each professional. In this way, the focus of the research to search a mode to improve the
integration between the programmers and testers would become unviable, a fact that should
cause late in the project due lower quality achieved for defect that should being previously
avoided. Since this time, the Agile methodology it became more advantageous and adequate
for projects which need dynamism and integration between the teams, because since the
beginning the customer and the planning, development and quality teams are working
together for the same goal, the success of the project, respecting the schedule and the budget
with the propose to conquest the lower bounce of the end-user. The programmers must be
alert to the Agile way to make unit tests, integration tests, following the test plans created for
the system, changing this activity in the perfect relationship between the code professionals
and that professionals responsible for the risks mitigations and less bugs.
Keywords: Software Quality; Software Testing. Agile Methodology. Agile Testing. Software
Development. SDLC
LISTA DE ABREVIATURAS
ATDD
Acceptance Test-Driven Development
GCS
Gestão de Configuração de Software
QA
Quality Assurance
RAM
Random Access Memory
SDLC
Software Development Life-Cycle
SI
Sistema de Informação
TC
Test Case
TDD
Test-Driven Development
TI
Tecnologia de Informação
UAT
User Acceptance Test / Teste de Aceitação de Usuário
UT
Unit Test / Teste Unitário
XP
eXtreme Programming
SUMÁRIO
1
INTRODUÇÃO ...................................................................................................... 13
2
OBJETIVOS............................................................................................................ 16
2.1
Objetivo Geral ..................................................................................................... 16
2.2
Objetivos Específicos .......................................................................................... 16
3
METODOLOGIA ................................................................................................... 17
4
DESENVOLVIMENTO x QUALIDADE DE SOFTWARE ................................. 18
4.1
A Qualidade Inserida no Contexto da Engenharia de Software .......................... 18
4.2
Diretrizes da Qualidade de Software ................................................................... 20
4.3
Ciclo de Vida de Desenvolvimento do Software ................................................ 24
4.4
A Qualidade no Ciclo de Vida do Desenvolvimento de Software (SDLC) ........ 25
5
O AMBIENTE DE DESENVOLVIMENTO ÁGIL ............................................... 28
5.1
Descrevendo a Metodologia Ágil ........................................................................ 28
5.2
Comparação Entre Metodologia Ágil e Metodologias Tradicionais ................... 29
5.3
Os Testadores no Desenvolvimento Ágil ............................................................ 31
6
TÉCNICAS UTILIZADAS EM UM AMBIENTE ÁGIL ...................................... 33
6.1
Uma Visão Sobre o eXtreme Programming (XP) ............................................... 33
6.2
Uma Visão Sobre o Test-driven Development (TDD) ........................................ 35
6.3
Uma Visão Sobre os Testes de Aceitação (UAT) ............................................... 38
7
CONSIDERAÇÕES FINAIS .................................................................................. 41
REFERÊNCIAS ............................................................................................................. 42
ÍNDICE DE ILUSTRAÇÕES
Figura 1 - Modelo de Processo em Cascata .............................................................................. 19
Figura 2 - Modelo de Processo de Desenvolvimento Incremental ........................................... 19
Figura 3 - Modelo Orientado a Reuso ...................................................................................... 20
Figura 4 - Árvore de Características de Qualidade de Boehm ................................................. 22
Figura 5 - Modelo Espiral de Boehm ....................................................................................... 23
Figura 6 - Ciclo Básico de Desenvolvimento de Sistemas (SDLC) ......................................... 24
Figura 7 - Qualidade no ciclo de vida do software ................................................................... 26
Figura 8 - Modelo Simplificado do Processo XP ..................................................................... 34
Figura 9 - Modelo do Ciclo ATDD (Acceptance Test-driven Development) .......................... 36
Figura 10 - Ciclo do Test-driven Development (TDD) ............................................................ 37
Figura 11 - Modelo em V do Teste de Software ...................................................................... 40
13
1
INTRODUÇÃO
Em um modelo tradicional de desenvolvimento de software, comumente se verifica a
necessidade intrínseca de finalizar um módulo de cada vez, aonde jamais fora cogitado
entregar a etapa atual em partes, ou seja, por exemplo, um determinado código apenas é
enviado para testes após sua implementação tiver sido concluída. Entretanto, quando o
desenvolvedor aguarda este período a fim de utilizá-lo para pensar, excessivamente, em
refinar seu código, para então entregar a equipe de Testadores, isto pode acarretar perda de
tempo, orçamento e causar um conflito entre as equipes.
Para facilitar e agilizar a comunicação entre estas duas equipes de profissionais,
agilizando os processos dentro do SDLC (Software Development Life-Cycle), uma equipe de
especialistas fundou a Agile Alliance, a qual propôs em 2001, o "Agile Manifesto".
[...] o intuito foi o de promover a eficiência, humanidade e uma forma
colaborativa de desenvolver programas de computador e sistemas de
informação”. As fases de testes de software são uma amostra do envolvimento
de todo o ambiente global de colaboração, envolvendo desenvolvedores a
partir dos testes de unidade e testadores profissionais nos testes de aceitação,
além das demais fases de testes de integração e testes de sistema [...]".
(HUSTON, (2015)
A metodologia de Testes Ágeis (Agile Testing) foi criada para facilitar o andamento
dos projetos de uma forma paralela, na qual os Desenvolvedores e os Testadores trabalham
juntos para entregar um produto de qualidade, no tempo prometido e com os requisitos
propostos. Assim, a cadeia produtiva dos softwares tende a quebrar barreiras de discriminação
entre estes profissionais, o que pode tornar um ambiente de trabalho menos hostil e mais
colaborativo, encorajando todos a executar o melhor trabalho possível.
“Na abordagem Ágil, desenvolvedores e testadores são vistos como dois lados
da mesma moeda de produção, duas linhas paralelas que precisam sempre
atender e comparar notas diariamente.” (HUSTON, 2015, tradução nossa) 1
Ao mesmo tempo em que os desenvolvedores precisam pensar com maior
responsabilidade sobre cada linha de código a ser produzida, é de mesma valia que os
testadores trabalhem de uma forma ágil e com um interesse jamais antes mencionado ao
código desenvolvido, pois a partir deste passo tornar-se-á possível sua automação em testes
1
In the Agile approach, developers and testers are seen as two sides of the same production coin, two parallel lines that
should always meet and compare notes daily (HUSTON, 2015)
14
ágeis e com resultados mais concretos, descobrindo suas ineficiências antes mesmo da
implementação daquele. Dentro da metodologia Ágil há filosofias como o SCRUM e a
metodologia XP (eXtreme Programming), este o qual será levada em consideração durante as
pesquisas. Neste contexto, destacam-se o Test-Driven Development (TDD), o qual pode ser
utilizado com um exemplo de prática de testes planejado e executado pelos profissionais de
desenvolvimento, por se tratar de testes unitários. E, em contrapartida, os testes de aceitação
(User Acceptance Testing – UAT) são a visão mais próxima possível do cliente final, tendo os
analistas de testes funcionais a responsabilidade de analisar as funcionalidades do sistema de
um modo global e com pouco ou nenhum conhecimento técnico.
Um (desenvolvimento de software) processo define que está fazendo o que,
quando e como. Isto quer dizer que, provê princípios, técnicas e práticas para a
eficiência, predição e repetição na produção de sistemas de software. Além
disso, o processo serve como um template para a criação de projetos
(DUDZIAK, 1999/2000, tradução nossa, p. 4) 2
Já, a automação dos testes de software é importante na análise em questão, pois é
sempre de interesse de todos que haja o aprimoramento da eficiência de um ou mais processos
de um projeto, fato que tende a conceber uma adequação ao cronograma deste e também,
auxiliar em uma melhor eficácia da codificação em todo o ciclo de desenvolvimento de
software. Por haver a possibilidade de reutilização de códigos dos processos automatizados,
isto faz com que os testes tornem-se ágeis e precisos, pois quanto menor for à ação humana,
mais eficaz é o procedimento.
[...] os projetos de automação de testes bem sucedidos são aqueles que se
baseiam em processos de testes formais e estruturados. Afinal, como é
possível esperar alguma coisa de testes automatizados que são baseados em
testes manuais errados, ambíguos ou inconsistentes, sucedidos são aqueles que
se baseiam em processos de testes formais e estruturados [...]. (CAETANO,
2008, p. 42)
Portanto, com esta visão que se torna possível à visualização do contexto explicitado
até o momento introduzido, pois a integração entre as equipes de desenvolvimento e testes é
mais importante do que nunca para os processos de automação, unindo a experiência de
codificação do primeiro, com as qualidades processuais do outro, com a criação de casos de
testes de qualidade e baseados em uma estrutura sólida de relacionamento entre os fluxos de
2
A (software development) process defines who is doing what when and how. This means, it provides
principles, techniques and practices for the efficient, predictable and repeatable production of software systems.
Therefore, the process serves as a template for creating projects (DUDZIAK, 1999/2000, p. 4)
15
execução de cada módulo da aplicação (Fluxo Principal, Fluxos Alternativos e Fluxos de
Exceção), sendo ainda mais importante em situação aonde os casos de uso são inexistentes,
requisitando testes regressivos e testes exploratórios.
16
2
2.1
OBJETIVOS
Objetivo Geral
Teoricamente, o objetivo deste trabalho será o demonstrar de uma forma analítica e
com resultados descritivos o contexto de integração de profissionais de desenvolvimento e de
qualidade de software (no caso, testadores de software), focando nos requisitos técnico e nãotécnicos envolvidos durante o Ciclo de Vida de Desenvolvimento de Software (conhecido
como SDLC - Software Development Life-Cycle).
Em prática, o propósito básico será o de fortalecer o vínculo de desenvolvedores com
as atividades de teste de software, auxiliando no entendimento destes para com os
profissionais de qualidade de software, os quais são erroneamente conhecidos como
irresponsáveis, sendo tachados de responsáveis pelo atraso no cronograma de um projeto.
2.2
Objetivos Específicos
O teste de software é importante para a qualidade do produto e redução da rejeição perante
os clientes, mas para o andamento de um projeto ele pode passar a impressão de causar um
atraso no cronograma, fazendo com que seja rejeitado por alguns gestores e desenvolvedores.
Então, para que esta visão deturpada seja contornada, serão analisados métodos e realizadas
análises sobre os seguintes assuntos:
 Desenvolvimento x Qualidade de Software
 A Importância dos Testes Ágeis (Agile Testing)
 Uma Visão Sobre o eXtreme Programming (XP methodology)
 Uma Visão Sobre o Test-Driven Development (TDD)
 Uma Visão Sobre os Testes de Aceitação (UAT – User Acceptance Testing)
 O Aprimoramento da Relação Entre Desenvolvedores e Testadores
17
3
METODOLOGIA
Esta pesquisa será baseada em informações concretas e em modo comparativo sobre
desenvolvimento de software e qualidade de software a partir de artigos, teses e dissertações
de especialistas, bibliografias reconhecidas pelo mercado e, normas brasileiras e
internacionais relacionadas às áreas em questão nos assuntos alçados como relevantes para a
compreensão desta, definindo-se em um estudo qualitativo (este definido por Lüdke & André,
1986). A análise dos dados foi feita com a realização da análise do conteúdo (este definido
por Bardin, 2011) 3. Como critério principal para a busca de referências tem-se o uso de dados
teóricos levantados nos últimos quinze anos, pois tendem a estar atualizados, apesar de
reconhecer a importância de manter o relacionamento com bibliográficas históricas, tais como
os princípios básicos da engenharia de software envolvendo a evolução das metodologias de
projeto.
.
3
[...] um conjunto de técnicas de análise das comunicações visando a obter, por procedimentos sistemáticos e
objetivos de descrição do conteúdo das mensagens, indicadores (quantitativos ou não) que permitam a inferência
de conhecimentos relativos às condições de produção/recepção (variáveis inferidas) destas mensagens [...]
(BARDIN, 2011, p. 47)
18
4
4.1
DESENVOLVIMENTO x QUALIDADE DE SOFTWARE
A Qualidade Inserida no Contexto da Engenharia de Software
O antigo pensamento sobre o funcionamento dos processos envolvendo o
desenvolvimento de software tende a ser equivocada, a princípio, tendo em vista a sua
máxima de que a simples implementação de sequências de instruções é o fator primordial para
que o resultado final, a aplicação, seja alcançado. “A programação foi conhecida por ser uma
tarefa sofisticada que exige dedicação e pesquisas minuciosas, e uma paixão por códigos
obscuros e truques”. (WIRTH, 2008, p. 32). Entretanto, estes posicionamentos se tornaram
obsoletos logo no primeiro momento em que o termo “Engenharia de Software” esteve
presente nas primeiras discussões entre os especialistas da área de desenvolvimento, fato
ocorrido exatamente no ano 1968, durante a NATO-Sponsored conference4. De acordo com
Wirth (2008, p. 32, tradução nossa)5, “nesta conferência as dificuldades e falhas de design em
sistemas complexos foram exploradas em profundidade, e a busca por soluções iniciaram
concentradas em melhores metodologias e ferramentas”.
Em formato teórico, Pressman (2011, p. 29) definiu a engenharia de software como
“[...] aquela que abrange um processo, um conjunto de métodos (práticas) e um leque de
ferramentas que possibilitam aos profissionais desenvolverem software de altíssima
qualidade”. A partir desta definição, pode-se analisar a importância dos processos dentro do
contexto de desenvolvimento de software:
[...] são atividades fundamentais para promover uma integração entre as
diversas equipes e seus profissionais, começando com a especificação do
software (software specification)6 e o design e a implementação do software
(software design and implementation)7, finalizando com a validação do
software (software validation)8 e a evolução do software (software
evolution)9” (SOMMERVILLE, 2011, p. 28, tradução nossa).
4
O termo programação era comumente usado durante meados dos anos 1960, e essencialmente referenciado a
tarefas de codificação em computador. O termo de referência, engenharia de software, é altamente disciplinado,
uma abordagem sistemática para o desenvolvimento de software e manutenção - o que advêm logo após a
NATO-sponsored conference, em 1968. (WIRTH, 2008, p. 32, tradução nossa)
5
At that conference, the difficulties and pitfalls of designing complex systems were explored in depth, and a
search for solutions began that concentrated on better methodologies and tools. (WIRTH, 2008, p. 32)
6
A funcionalidade do software e dependências nestas operações precisam ser definidas.
7
Uma especificação para conhecer o software precisa ser produzido.
8
O software precisa ser validado para garantir que o foi produzido como o cliente solicitou.
9
O software deve evoluir para responder às novas necessidades dos clientes
19
Deste modo, pode-se perceber atentamente que um projeto de software é
interdependente entre cada um dos processos, estando as etapas de planejamento e
desenvolvimento muito próximas à qualidade de software, momento de validar se todos os
requisitos foram atendidos de acordo comas solicitações do cliente. Há diversos modelos de
processos de software que provam estas relações, tais como o modelo em cascata (waterfall
model), o desenvolvimento incremental (incremental development) e o modelo orientado a
reuso (reuse-oriented software engineering). Em todos estes modelos de processos, atividades
relacionadas à qualidade de software estão especificadas de alguma forma, podendo ser
visualizadas nos fluxos a seguir:

Modelo em Cascata: design de sistema e software (system and software design),
implementação e teste de unidade (implementation and unit testing) e teste de
sistema e integração (integration e system testing)
Figura 1 - Modelo de Processo em Cascata
(SOMMERVILLE, p. 30, 2011)

Desenvolvimento Incremental: validação (validation).
Figura 2 - Modelo de Processo de Desenvolvimento Incremental
20

Modelo Orientado a Reuso: validação do sistema (system validation)
Figura 3 - Modelo Orientado a Reuso
4.2
Diretrizes da Qualidade de Software
A garantia da qualidade de software tem como objetivo “[...] avaliar a aderência das
atividades executadas, padrões, processos, procedimentos, proporcionando uma avaliação
objetiva dos produtos e dos processos em relação aos padrões” (MACIEL; VALLS;
SAVOINE, 2011,p. 2). A qualidade de software tem definições genéricas, mas importantes,
que traçam a linha-base da compreensão sobre algo tão importante para o contexto do
desenvolvimento de software, sendo elas:
[...] gerenciamento da qualidade de software em que o sistema será testado a
partir de seus requisitos. [...] o time de QA (Quality Assurance) deve revisar
os testes que foram desenvolvidos e examinar os testes registrados para checar
se o teste foi realizado corretamente. [...] subjetivamente, a qualidade de um
sistema de software é largamente baseada em características não funcionais.
[...] a qualidade de software não é apenas sobre se a funcionalidade do
software foi implementada corretamente, mas também depende dos atributos
não funcionais. (SOMMERVILLE, 2011, p.656, tradução nossa)
Os modelos de qualidade de software podem ser cruciais para que este seja
desenvolvido com total apreço às necessidades do(s) cliente(s), tendo em vista a possibilidade
de se realizar medições de atributos internos, externos e de qualidade. Desta forma, o produto
final desenvolvido tem uma relação importantíssima com o usuário final, sendo este o real
analista sobre a qualidade deste. Retornando a Sommerville (2011, p. 144), este descreve de
forma sucinta os objetivos dos processos de teste envolvidos nas atividades de qualidade:

“Demonstrar ao desenvolvedor e ao cliente que o software atende a seus
requisitos.”
21

“Descobrir situações em que o software se comporta de maneira incorreta,
indesejável ou de forma diferente das especificações:”
o “Essas são consequências de defeito de software.”
o “O teste de defeito preocupa-se com a eliminação de comportamentos
indesejáveis do sistema, tais como panes, interações indesejáveis com
outros sistemas, processamentos incorretos e corrupção de dados.”
Em 1977, o guru da qualidade Jim McCall apresentou um modelo de qualidade que
ficou conhecido como o Modelo da General Electrics (General Electrics Model – GE Model /
Modelo GE), sendo este “[...] uma ponte entre os usuários e os desenvolvedores com foco no
número de fatores de qualidade que refletirá em ambos, nas visões dos usuários e nas
prioridades dos desenvolvedores”.
No Modelo GE, foram descritos três perspectivas de identificação da
qualidade de um software: Revisão de Produto (Product revision), Transição
de Produto (Product transition) e Operações de Qualidade de Produto (Quality
of product operations), possuindo hierarquias de onze fatores (factors)10 para
especificar, ainda de vinte e três critérios de qualidade (quality criteria)11 para
construir e métricas (metrics)12 para controlar. (BERANDER et al, 2005, p. 67, tradução nossa)
No ano seguinte, outro guru da qualidade, Barry W. Boehm (1978) descreveu que:
[...] modelo hierárquico da qualidade de software possui três níveis de
características: alto, intermediário e baixo, cada qual contribui em seus níveis
para a qualidade, tendo características como: correção, confiabilidade,
integridade, usabilidade, eficiência, manutenabilidade, flexibilidade,
reusabilidade, clareza, modificabilidade, documentação, resiliência,
compreensibilidade, validação, generalização e economia. (BOEHM, 1978
apud BERANDER et al, 2005, p. 8, tradução nossa)13.
10
Fatores: Eles descrevem uma visão externa do software, o que é visualizado pelos usuários.
11
Critérios de Qualidade: Eles descrevem uma visão interna do software, tal como visto pelo desenvolvedor.
12
Métricas: Eles são definidos e usados para prover uma escala e método de mensuração.
13
Quality characteristics of Boehm's quality mode model: correctness, reliability, integrity, usability, effiency,
maintainability,
flexibility,
reusability,
portability,
clarity,
modifiability,
understandability, validity, generality and economy (BERANDER et al, 2005, p. 8)
documentation,
resilience,
22
Figura 4 - Árvore de Características de Qualidade de Boehm
(BOEHM, 1978)
Cada nível possui suas características específicas, portanto podem ser individualmente
descritos da seguinte forma:

Alto Nível
Estas características representam requisitos de alto nível para avaliação da
qualidade de software.
o As-is-Utility - A medida em que a As-is utility pode ser utilizado, tal como
fácil de usar, confiabilidade e eficiência.
o Manutenabilidade (Maintainability) - Facilidade em identificar qual será a
melhor modificação a ser feita e retestá-la.
o Facilidade em alterar o software para ser inserido em um novo ambiente
(ex. novo sistema operacional)

Nível Intermediário
As características de nível intermediário são representadas por 7 fatores, os quais
juntos representam as qualidades esperadas de um software.
o Portabilidade - Na medida em que o software irá trabalhar em
computadores de diferentes configurações.
23
o Confiabilidade - Na medida em que o software executado como esperado.
o Eficiência - Uso otimizado de recursos durante a execução.
o Usabilidade - Fácil de usar.
o Testabilidade - Fácil validação, pois o software atende aos requisitos.
o Compreensibilidade - Na medida em que o software é de fácil compreensão
com a requerida proposta e estrutura.
o Flexibilidade - Quando o software é de fácil alteração a fim de atender aos
requisitos revisados.

Nível Baixo
As características de baixo nível são caracterizadas por prover os fundamentos
para definição das métricas de qualidade.
Para ser utilizado como informação, Boehm (1988) propôs um framework processos
de software orientado a risco (A risk-driven software process framework) chamado Modelo
Espiral de Boehm (Spiral Mode), em que cada volta na espiral representa uma fase do
processo de software combinando prevenção e tolerância a mudança, possibilitando que a
volta mais interna se preocupe com a viabilidade do sistema, o próximo com a definição de
requisitos, a seguir com o projeto do sistema, entre outros. Algo importante a acrescentar é a
visualização de que mudanças são um resultado de risco de projeto e inclui atividades
explícitas de gerenciamento de riscos para sua redução (mitigação de riscos).
Figura 5 - Modelo Espiral de Boehm
(BOEHM, 1988)
24
4.3
Ciclo de Vida de Desenvolvimento do Software
De acordo com Gordon & Gordon (2006), o “Ciclo de Vida do Desenvolvimento de
Sistemas (SDLC – Systems Development Life-Cycle), conhecido também com o “ciclo de vida
do software” (SDLC - Software Development Life-Cycle), refere-se aos estágios de concepção,
projeto, criação e implementação de um Sistema de Informação (SI)”. Um desdobramento
possível para SDLC é mostrado a seguir:
Figura 6 - Ciclo Básico de Desenvolvimento de Sistemas (SDLC)
(GORDON & GORDON, 2006)
Para padronizar os conceitos sobre o SDLC, foi elaborada a ISO/IEC 12207 –
Processos de Ciclo de Vida do Software, a qual tem como objetivo principal:
“[...] fornecer uma estrutura única para que o adquirente, fornecedor,
desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o
desenvolvimento de software utilizem uma linguagem comum que é
estabelecida na forma de processos bem definidos. A estrutura da norma foi
concebida de maneira a ser flexível, modular e adaptável às necessidades de
quem a utiliza. Para isto, ela está fundamentada em dois princípios básicos:
modularidade e responsabilidade. Modularidade, no sentido de processos com
mínimo acoplamento e máxima coesão”. (LAHOZ; SANT’ANNA, 2003, p. 2)
Enfim, o SDLC também possui classificações em seus processos, sendo elas:
primários, de apoio e organizacionais.
[...] ao utilizar a norma todo o ciclo de vida do desenvolvimento de software
será realizado, desde os requisitos até a manutenção. Os processos são
classificados em três categorias: primários – aquisição, fornecimento,
desenvolvimento, operação e manutenção -, de apoio – documentação,
gerência de configuração, garantia da qualidade, verificação, validação,
revisão conjunta, auditoria e resolução de problemas -, e organizacionais –
gerência, infraestrutura, melhoria, treinamento ou recursos humanos, gestão de
ativos e programa de reuso. (MACIEL; VALLS; SAVOINE, 2011, p. 4)
25
4.4
A Qualidade no Ciclo de Vida do Desenvolvimento de Software (SDLC)
Durante o ciclo de vida de desenvolvimento do software, diversas visões de qualidade
podem ser consideradas, e cada qual com seus atores, e como diz na ISO/IEC 9126-1, "As
tecnologias utilizadas para atingir o nível de qualidade necessário, como especificação e
avaliação de qualidade, precisam apoiar estes diversos pontos de vista.”. Esta norma descreve
um modelo de qualidade de produto de software, o qual é composto por qualidade interna e
qualidade externa – limita-se a especificar as seis características para qualidade interna e
externa, as quais são subdivididas em subcaracterísticas - e, por qualidade em uso – é, para o
usuário, o efeito combinado das seis características de qualidade do produto de software, as
quais são:

Validar a completitude de uma definição de requisitos;

Identificar requisitos de software;

Identificar objetivos de projeto de software;

Identificar objetivos para teste de software;

Identificar critérios para garantia de qualidade;

E, Identificar critérios de aceitação para produtos finais de software.
Ainda de acordo com a Norma NBR ISO/IEC 9126-1, há mudanças entre o SDLC e a
qualidade, aonde as tecnologias utilizadas para atingir o nível de qualidade necessário, como
especificação e avaliação da qualidade, precisam apoiar os diversos pontos de vista como da
qualidade interna e do desenvolvedor. A finalidade é alcançar a qualidade necessária e
suficiente para atingir as reais necessidades do usuário. Nesta visão, os estágios da SDLC
contemplados são necessidades de qualidade do usuário, requisitos de qualidade externa,
requisitos de qualidade interna, qualidade interna, qualidade externa e qualidade em uso.
Interno a estes estágios, há etapas de validação e verificação, os quais tem funções
completamente opostas, mas Sommerville (2011, p. 207, tradução nossa) descreve que “[...]
ambos são processos [...]”, tendo em vista que, de acordo com Boehm (1979), “são definidos
como”:
 “Validação: Estamos construindo o produto certo? 14”
 “Verificação: Estamos construindo o produto da forma correta? 15”
14
Validation: Are we building the right product?
15
Verification: Are we building the product right?
26
Figura 7 - Qualidade no ciclo de vida do software
(Norma NBR ISO/IEC 9126-1)
Em referência a Figura 7, os estágios da qualidade no ciclo de vida do software são
detalhados da seguinte forma:
Necessidades de Qualidade do Usuário
[...] obter um produto que satisfaça as necessidades do usuário normalmente
requer uma abordagem iterativa para o desenvolvimento de software com
feedback continuo sob a perspectiva do usuário. (Norma ISO/IEC 9126-1)
Requisitos de Qualidade Externa
[...] especificam o nível de qualidade requerido sob o ponto de vista externo.
[...] incluem requisitos derivados das necessidades de qualidade dos usuários,
incluindo os requisitos de qualidade em uso. [...] os requisitos de qualidade
externa são usados como meta para validação em vários estágios de
desenvolvimento. (Norma ISO/IEC 9126-1)
Requisitos de Qualidade Interna
[...] especificam o nível de qualidade requerido sob o ponto de vista interno do
produto. [...] os requisitos de qualidade interna são usados para especificar as
propriedades dos produtos intermediários. [...] podem incluir modelos
estáticos, dinâmicos, outros documentos e código-fonte. [...] requisitos de
qualidade interna podem ser usados como metas para validação em vários
estágios de desenvolvimento. (Norma ISO/IEC 9126-1)
27
Qualidade Interna
[...] é a totalidade das características do produto de software do ponto de vista
interno. [...] Detalhes da qualidade do produto de software podem ser
melhorados durante a implementação do código, revisão e teste. (Norma
ISO/IEC 9126-1)
Qualidade Externa Estimada (ou prevista)
[...] é a qualidade estimada ou prevista para o produto final de software, em
cada estágio de desenvolvimento e para cada característica de qualidade,
baseada no conhecimento de qualidade interna. (Norma ISO/IEC 9126-1)
Qualidade Externa
[...] é a totalidade das características do produto de software do ponto de vista
externo. [...] é a qualidade quando o software é executado, o qual é
tipicamente medido e avaliado enquanto está sendo testado num ambiente
simulado, com dados simulados e usando métricas externas. [...] durante os
testes, convém que a maioria dos defeitos seja descoberta e eliminada (sempre
quando possível) [...] (Norma ISO/IEC 9126-1)
Qualidade em Uso Estimada (ou prevista)
[...] é a visão da qualidade do produto de software do ponto de vista do
usuário[...] [...] ele mede o quanto usuários podem atingir seus objetivos num
determinado ambiente e não as propriedades do software em si. (Norma
ISO/IEC 9126-1)
A partir das comprovações teóricas sobre a inserção da qualidade dentro do ciclo de
desenvolvimento de software, torna-se possível em sua plenitude à absorção da proposta em
que a qualidade de software e as atividades de teste envolvidas possuem um valor inestimável
para o planejamento, desenvolvimento, implementação e entrega do produto de software que
se deseja modelar. Entretanto, para uma visão prática e otimizada dos requisitos envolvidos
em todo este processo, no início do Século XXI fora feita a primeira especificação sobre a
abordagem Ágil de desenvolvimento, o qual no Capítulo 5 será apresentado em detalhes, com
seus métodos e práticas, mais especificamente o método de desenvolvimento eXtreme
Programming (XP) e a prática Test-driven Development (TDD) – ambas serão importantes
para a compreensão e aprimoramento do relacionamento integrado entre Programadores e
Testadores de Software.
28
5
O AMBIENTE DE DESENVOLVIMENTO ÁGIL
5.1
Descrevendo a Metodologia Ágil
No ano de 2001, um grupo formado por dezessete desenvolvedores, produtores e
consultores de software procuravam uma alternativa aos métodos tradicionais de
desenvolvimento de software, então criaram a Aliança Ágil (Agile Alliance), fator que
culminou no estudo, planejamento e definição do Manifesto de Desenvolvimento Ágil (Agile
Manifesto). Tal documento tem como proposta base seguir doze princípios que envolvem
desde ao relacionamento com os clientes até questões técnicas que envolvem funcionalidade,
negócios, desenvolvimentos e processos ágeis. Entretanto, os valores intrínsecos a este
manifesto estão questões como: “indivíduos e interação entre eles mais que processos e
ferramentas”,
“software
em
funcionamento
mais
que
documentação
abrangente”,
“colaboração com o cliente mais que negociação de contratos e responder a mudanças mais
que seguir um plano” (AGILE ALLIANCE, 2001a).
No âmbito ágil é importante que os códigos sejam executados no mesmo
momento em que forem desenvolvidos, principalmente para longos
desenvolvimentos, pois assim os problemas não serão descobertos de forma
tardia, quando eles ficam mais caros para serem corrigidos. (BOEHM, 2004,
p. 42, tradução nossa) 16
No contexto de desenvolvimento de software, a partir de estudos de Westfechtel &
Hoek (2001), a abordagem Ágil tem uma cultura primordial para que o bom funcionamento
do ciclo seja alcançado em cada uma de suas etapas de programação.
[...] a abordagem Ágil tem como requisito uma estratégia otimista que permite
aos desenvolvedores trabalharem em paralelo, mas a maior independência
possível. Isto, entretanto, precisa ser balanceado com o princípio da filosofia
Ágil, onde os desenvolvedores precisam trabalhar com proximidade e em
conjunto, tomando cuidado em como uma pessoa afeta o trabalhar de outra”.
(WESTFECHTEL; HOEK; 2001, p. 192, tradução nossa) 17.
16
It requires that the code be developed and executed, which means that for long developments, problems will
not be discovered until late in the development cycle, when they are expensive to fix. (BOEHM, 2004, p. 42)
17
An agile approach to sodtware development requires an optimistic strategy to permit as much independent
parallel development as possible. This, however, must also be balanced with another tenet of the agile
philosophy, namely that developers should work closely together and be aware of how one person's wotk affets
another (WESTFECHTEL; HOEK, 2001, p. 192).
29
Por outro lado, Paetsch (2003) analisou princípios com uma visão a partir do cliente,
pois ele é o responsável pela existência do projeto, merecendo assim uma atenção mais
próxima sobre o processo.
[...] a verdadeira necessidade dos projetos que trabalham com os métodos
Ágeis é a de que atendam aos requisitos definidos/alterados pelo cliente.
Ainda, afirma que os princípios comuns compartilhados neste modelo de
projeto são o de promover a satisfação do cliente, adotar as mudanças de
requisitos, frequentemente fornecer softwares em funcionamento e, haver um
relacionamento próximo entre as equipes de negócio e os desenvolvedores.
(PAETSCH, 2003, p.1, tradução nossa) 18
Deste modo, prova-se de forma teórica o quão importante é a cooperação entre as
equipes que integram um projeto, pois o resultado final será entregue ao cliente, este o qual
além de avaliá-lo, fornecerá um feedback sobre o fornecedor do software que, por fim, terá a
possibilidade de aprimorar seus processos e atrair mais clientes para seu catálogo. Mas, para
uma empresa, internamente, o princípio mais valoroso quando as diretrizes da metodologia
ágil são seguidas à risca, é o fato da integração entre seus recursos humanos ter sido
aprimorada, o que tenderá a facilitar no desenrolar de projetos no futuro.
5.2
Comparação Entre Metodologia Ágil e Metodologias Tradicionais
A partir de análises percebeu-se que nas metodologias ágeis, ao invés das atividades
serem realizadas de forma individual pelas equipes - como em uma metodologia tradicional19
de desenvolvimento de software -, era preciso um trabalho em conjunto. No contexto em
questão, torna-se necessário descrever em modo comparativo entre elas, aonde é possível
iniciar pela cultura envolvida em ambas.
No modelo tradicional, é utilizada a cultura da eliminação de riscos baseada em um
planejamento, podendo ser utilizados ciclos em cascata, espiral, iterativo, entre outros. Apesar
da possibilidade de se reutilizar códigos durante a produção, as suas restrições em aceitar
18
All these approaches share some common principles: Improved customer satisfaction, adopting to changing
requirements, frequently delivering working software, and close collaboration of business people and developers.
(PAETSCH, 2003, p. 1)
19
Estas metodologias surgiram em um cenário de construção de software muito diferente do atual.
A sequência de tarefas para desenvolvimento do software era realizada em terminais burros e
mainframes, onde o custo para correção de erros ou qualquer outra alteração era muito elevado,
pois o acesso aos computadores era muito limitado e não havia ferramentas de apoio à construção
de software (PRESSMAN, 2002).
30
mudanças durante o processo devido ao contexto global trás complexidades bastante visíveis
quanto ao relacionamento com o cliente. Tal afirmação é validada por Pressman (2002),
quando expõe os critérios básicos responsáveis por um projeto complexo e com muitas
variáveis o qual, enfim, é difícil de ser gerenciado.
[...] a maneira de minimizar os problemas durante o desenvolvimento de um
software foi planejar e documentar muito bem este antes do início de seu
desenvolvimento. Esse foi um dos fatores primordiais para a existência de um
processo de gerenciamento de software baseado em documentação detalhada,
planejamento extenso e etapas bem delimitadas. (PRESSMAN, 2002)
Assim, apesar dos métodos tradicionais serem ainda os mais utilizados no mercado, um
fator importante o torna impróprio em momentos essenciais, pois o tamanho do projeto tende
a inviabilizar melhorias durante o seu andamento, pois muitos requisitos anteriormente
aprovados estão envolvidos.
Entretanto, o uso de metodologias ágeis apareceu como uma alternativa a situações
arbitrárias dentro do contexto do gerenciamento de projetos, pois suas características tendem a
otimizar o processo de desenvolvimento de todo e qualquer projeto de software, reduzindo,
principalmente, a rejeição por parte do cliente. Em seu artigo “Balancing Agility and
Discipline”, Boehm (2004, p. 25, tradução nossa) realizou comparações entre os métodos
tradicionais e os ágeis, encontrando as características distintas entre si, apesar de descrever
que uma comparação entre ambas pode ser difícil e imprecisa devido a complexidade natural
do desenvolvimento de software e suas variedades de métodos e as variáveis envolvidas. Este
levantamento resultou nas seguintes características:
 “Aplicação, incluindo objetivos de projeto, tamanho e ambiente de aplicação.”
 “Gerenciamento, incluindo relacionamento de clientes, planejamento e controle, e
projetos de comunicação.”
 “Técnicas, incluindo abordagens de definição de requisitos, desenvolvimento, e teste.”
 “Pessoais, incluindo características do cliente, características de desenvolvimento, e
cultura organizacional.”
As comparações entre os métodos tradicionais e ágeis realizadas por Boehm (2004, p. 3031, tradução nossa) são “[...] concretas e comprovam que ambas as metodologias são
importantes no contexto correto, pois o número de variáveis envolvidas podem ser diferentes,
tornando-se mais eficiente no modelo correto”. O quadro abaixo é um comparativo bastante
detalhado desta pesquisa: (BOEHM, 2004, p. 42, tradução nossa)
31
Metodologia Ágil
Metodologia Tradicional
Métodos ágeis devem ser quase inteiramente cumpridos em
Métodos tradicionais necessitam de estabilidade
ambiente in-house – de maneira caseira – ou em um
Métodos tradicionais trabalham melhor quando os requisitos
ambiente de desenvolvimento dedicado, como em nuvem
são largamente determinados em modo avançado (incluindo
(cloud solutions).
via protótipo) e em permanência estabilidade.
Esta metodologia faz com que haja um relacionamento
Métodos tradicionais também cobrem um espectro mais
próximo para com os usuários locais, mas difícil de controlar
amplo de atividades do que métodos ágeis
vários formulários de distribuição de desenvolvimento,
evolução, e uso.
Taxas de mudança na ordem de 1% dos requisitos por mês
são aceitáveis.
5.3
Os Testadores no Desenvolvimento Ágil
A partir da aceitação de metodologias ágeis para o desenvolvimento de um projeto de
software, tal como o uso do eXtreme Programming (XP) e SCRUM, é importante haver a
percepção de todos sobre como será a integração entre as equipes, tendo em vista a redução da
burocracia e a percepção de que mudanças frequentes podem acontecer por diversos motivos,
sendo o principal as solicitações do(s) cliente(s). As metodologias tradicionais são
comumente ineficientes para trabalhar com mudanças em situações assim, mesmo que haja
um sistema organizado com uma Gestão de Configuração de Software (GCS) adequada, pois
as alterações tendem a ser feitas como um todo, impedindo a visualização parcial do projeto
pelo usuário final. Assim, de modo mais eficaz, o contexto Ágil tende a trabalhar em módulos
independentes, baseados em User Stories, fazendo com que em caso de mudanças, melhorias
ou defeitos de desenvolvimento (bugs), o “reteste” possa ser rápido, sem causar impacto sobre
o projeto como um todo.
[...] os Testes Ágeis (Agile Tests) podem reduzir a quantidade de falhas nos
primeiros estágios e ainda, estes métodos de teste habilitam a possibilidade da
realização destes em todos os estágios, sendo que, entretanto, o mais
importante é que este tipo de teste é realizado em pequenas unidades (short
iterations). (KOTESKA; MISHEV, 2012, p. 122) 20
Nestas circunstâncias, os programadores tendem a atuar no desenvolvimento em
módulos, havendo assim uma agilidade no processo e uma oportunidade maior de adequação
ao cronograma e orçamento do projeto. Uma prática muito utilizada para o desenvolvimento
20
Agile software testing can help reducing the errors in the first stages... Agile software testing methods enable
testing during all stages and the most important thing is that testing is performed on small units. (KOTESKA &
MISHEV, 2012, p. 122)
32
de códigos mais eficientes e limpos é o TDD, que faz parte da metodologia de
desenvolvimento de software XP, servindo como a verdadeira conexão entre analistas de
programa e analistas de teste. Como já dito, a fim de que a qualidade do software seja tratada
com primazia, é importante haver um planejamento de testes adequado, sendo seus fluxos
executados a partir da entrega de cada módulo. De acordo com as especialistas Crispin &
Gregory (2009, p. 7), os “[...] testadores (testers) estão presentes tanto no time do cliente
(customer team), quanto no time dos desenvolvedores (developer team), o que demonstra a
importância destes profissionais em um ambiente Ágil”.
Testadores são membros integrantes do time do cliente (customer team),
auxiliando os clientes a extrair requisitos, moldar exemplos, ajudando-lhes a
expressar seus requisitos como um teste. Testadores são também parte
integrante do time dos desenvolvedores, pois testar é um componente central no
desenvolvimento ágil de software. Testadores advogam pela qualidade em nome
dos clientes e auxiliam o time de desenvolvimento em realizar as entregas com o
melhor valor para o negócio. (CRISPIN; GREGORY, 2009, tradução nossa)21
Por muito tempo o mercado de trabalho separou, literalmente, os profissionais em
questão, tendo uma visão equivocada de que o desenvolvimento de software era apenas
focado no planejamento do projeto e programação, deixando os testadores em segundo plano,
com uma visão de que apenas pertenciam a equipes de testes funcionais que tratam da análise
de defeitos de usabilidade e validação de dados. Esta é uma análise real visualizada em muitos
anos de experiência profissional, mas totalmente distante dos critérios da metodologia Ágil,
pois nesta a conexão entre desenvolvimento e testes é visualizada desde o começo.
[...] Times Ágeis tendem a ofuscar as distinções entre os profissionais,
particularmente desenvolvedores e testadores. Desenvolvedores Ágeis são
infectados por testes, e Testadores Ágeis tendem há usar muito tempo sujando
as mãos codificando. O método Ágil cresce, de modo que o papel hifenizado
testador-desenvolvedor/desenvolvedor-testador cresce 22”. (HENDRICKSON,
2007, tradução nossa)
21
Testers are integral members of the customer team, helping elicit requirements and examples and helping the
customers express their requirements as tests. Testers are also on the developer team, because testing is a central
component of agile software development. Testers advocate for quality on behalf of the customer and assist the
development team in delivering the maximum business value. (CRISPIN; GREGORY, 2009, p. 7-8)
22
Agile teams tend to blur the distinction between jobs, particularly developers and testers. Agile developers are
test infected, and Agile testers tend to spend time mucking about in code. As Agile grows, so the hyphenated
tester-developer/developer-tester role grows. (HENDRICKSON, 2007)
33
6
TÉCNICAS UTILIZADAS EM UM AMBIENTE ÁGIL
6.1
Uma Visão Sobre o eXtreme Programming (XP)
O eXtreme Programming (XP) é um composto de técnicas e métodos que tendem a
auxiliar os analistas no desenvolvimento de projetos que envolva codificação, mas mantendo
equipes de pequeno porte durante cada passo. Ainda, segundo Williams (2004, p. 1, tradução
nossa), “o XP tem duas importantes práticas, o Test-driven Development (TDD) e o Teste de
Aceitação - estas serão detalhados nos tópicos seguintes 23”.
[...] o eXtreme Programming (XP) é tanto um processo de desenvolvimento de
software quanto uma metodologia. É também um framework, pois ele pode (e
provavelmente o será) adaptado para as necessidades específicas de times,
projetos, companhias, etc. Além disso, algo importante a comentar, é o fato de
que o XP tende a ser usado em equipes com dois a doze membros, sendo
sempre recomendado manter times deste tamanho. (DUDZIAK, 1999/2000,
p.4 tradução nossa) 24
Há quatro variáveis primordiais do XP, que são o custo, tempo, qualidade e escopo.
No momento, será abordada a variável “Qualidade’ a qual contempla ações responsáveis pelas
indicações das correções necessárias no sistema, além de determinar quais práticas serão
utilizadas para testar a aplicação. Na prática, o início dos processos em XP necessita de um
contato-base com os clientes, pois estes serão os responsáveis por participar junto ao(s)
desenvolvedor(es) para definir suas User Stories em Index Cards, com estimativa de trabalho
(Ideal Engineering Time) de uma a três semanas, descrevendo o que cada módulo do projeto a
ser desenvolvido deve conter de uma forma literal e de fácil compreensão, tomando como
inspiração o modo detalhado de um caso de uso, apesar de manter cada fluxo independente,
ou seja, não há a necessidade de uma relação entre fluxos.
[...] é imprescindível saber se a User Story é passível de ser testada. A razão
para isso tem relação com os Testes Funcionais e Aceitação, estes os quais
serão resultantes destas histórias as quais irão auxiliar o cliente a verificar se o
sistema está em funcionamento conforme o planejado. (DUDZIAK,
1999/2000, p.9, tradução nossa) 25
23
The test practices discussed in this chapter come from the test-centric XP methodology. XP has two important
test practices: test-driven development (TDD) and customer acceptance testing. (WILLIAMS, 2004, p. 1)
24
eXtreme Programming (XP) is a software development process as well as a methodology. XP is also a process
framework because it can be (and most likely will be) tailored to the specific needs of teams, projects, companies
etc. (DUDZIAK, 1999/2000)
25
Another desirable property of a user story is that it is testable. The reason for this is that Functional Tests are
derived from the stories which will help the customer verifying that the system does what it is expected to.
(DUDZIAK, 1999/2000, p.9)
34
Figura 8 - Modelo Simplificado do Processo XP
(SERENA, 2007)
A Figura 8 representa um modo simplificado de visualizar o processo XP,
demonstrando de uma forma prática as principais etapas de aceitação até o lançamento
individual de versões interativas dos módulos de um projeto. A parte resultante (Small
Release) deste processo tem seu cronograma, User Stories e desenvolvedores responsáveis
definidos no Plano de Projeto (Release Plan), sendo este a parte resultante do Release
Planning. Entretanto, para que haja conhecimento sobre a eficiência das iterações (Iterations),
ou seja, saber se o que fora entregue está adequado ao planejado e o mais próximo possível ao
tempo estimado, a Velocidade (Velocity) de cada desenvolvedor precisa ser monitorada,
levando em consideração o Load Factor definido para este, pois caso esteja em desacordo,
para mais ou menos, tem-se então uma falha de projeto que precisa ser corrigida, sendo isto
possível apenas devido a estas análises.
O load factor é calculado a partir do número de horas trabalhadas dividido
pelo número de horas gastas diretamente nas tarefas pela equipe. Assim,
quanto menor o número, mais eficiente o time é. Um perfeito load factor é
2.0, o que significa que cada equipe está trabalhando em uma tarefa sem parar
quando está no trabalho. (LOVAASEN, 2001, p. 4, tradução nossa) 26
Após estas iterações, seu resultado é a Versão Final (Latest Version), os Testes de
Aceitação (Acceptance Testing) são executados a partir dos Casos de Teste (Test Cases - TC)
criados com informações das User Stories definidas e selecionadas durante o planejamento.
26
The load factor is calculated as the number of hours worked divided by the number of pair hours spent directly
on tasks. Thus, the lower the number, the more efficient the team is. A perfect load factor is 2.0, which means
that every pair was working on a task at every moment they were at work. (LOVAASEN, 2001, p. 4)
35
Em caso de rejeição de algum cenário de teste pelo encontro de algum(ns) defeito(s) (Bugs), o
ciclo retorna à iteração em que a equipe de desenvolvimento terá que corrigi-lo. Por fim, este
ciclo de testes se mantem até que todas as estórias sejam testadas com cautela e atenção, pois
deste modo será possível manter a qualidade do software desenvolvido e entregue ao final do
release (Small Release).
6.2
Uma Visão Sobre o Test-driven Development (TDD)
O Test-Driven Development (TDD) tem um papel importante em um ambiente de
desenvolvimento ágil, pois é uma prática que prioriza a realização de testes por unidade (unit
tests), tendo que ser escrito com antecedência à programação. De acordo com Hendrickson
(2008, p.1, tradução nossa), “a prática TDD vai além do concreto, sendo algo mais detalhado
e que permite atingir às expectativas sobre o comportamento do código para guiar a
implementação, muito mais do que servir como guia para os testes em si
27
”. Este pode
também auxiliar os desenvolvedores na entrega de projeto no prazo, com menos defeitos
(bugs) e com códigos mais limpos e otimizados, já que o planejamento dos testes faz com que
àqueles conheçam mais sobre o que se espera como resultado. Sob a visão de Vicente (2010,
p. 50), “[...] a execução dos testes de forma automatizada pode ajudar os desenvolvedores a
determinar quando novas funcionalidades estão completas ou se alguma funcionalidade
existente está com algum defeito”.
Martin (2007, p. 1, tradução nossa), os praticantes do TDD devem seguir as seguintes
regras:
 “Você não pode escrever um código para produção sem primeiro escrever um código
que falhe no teste unitário;”
 “Você não pode escrever mais testes unitários do que o necessário para falhar.”
 “Você não pode escrever mais códigos para produção do que o suficiente para fazer o
teste unitário falho ser aprovado.”
Antes do início dos trabalhos de codificação do TDD pelos programadores, há
questões analíticas a serem tratadas pela equipe a partir de sugestões dos patrocinadores do
projeto. Este brainstorm será a base para o planejamento e codificação dos testes unitários,
englobando etapas como discussão dos requisitos, refinamento dos testes e desenvolvimento
27
Practicing Test Driven Development is much more about setting concrete, detailed expectations in advance,
and allowing those expectations of code behavior to guide the implementation than it is about testing
(HENDRICKSON, 2008, p.1)
36
do código, para então, enfim, implementar o código e, em seguida, testá-lo de forma
exploratória. Todo este contexto foi denominado como Acceptance Test-Driven Development
(ATDD), tendo seu ciclo definido pelo Dr. James Shore e aprimorado por Grigori Melnick,
Brian Marick e Elisabeth Hendrickson.
Test-driven Development é uma disciplina que ajuda o profissional
desenvolvedor de software a trabalhar com códigos limpos, flexíveis e
entregues no tempo. (MARTIN, 2007, p. 32, tradução nossa) 28
Figura 9 - Modelo do Ciclo ATDD (Acceptance Test-driven Development)
(HENDRICKSON, 2008)
Com o planejamento dos métodos a serem utilizados na automatização dos testes, a
codificação dos programas tende a ser postergada, pois deste modo o desenvolvedor poderá
ter uma visão ampliada do que deve ser feito. Deste modo, uma questão levantada por
Gatezowski (2015, p. 8, tradução nossa) envolve este caso como um todo, pois "Por quantas
vezes temos que invocar uma aplicação para ter certeza de que esta funciona corretamente?"
29
. As ferramentas de automação de testes criam uma biblioteca chamada “Test List”, a qual
possui todos os métodos (Test Method) a serem utilizados durante a execução dos testes,
28
Test-driven development is a discipline that helps professional software developers ship clean, flexible code
that works, on time. (MARTIN, 2007, p. 32)
29
How many times would we have to invoke the application to make sure every operation works correctly?
(GATEZOWSKI, 2015, p. 8)
37
reduzindo assim a necessidade de inserir as chamadas destes diretamente na classe principal.
Com a reutilização de código dos métodos de teste implementados, torna-se possível garantir
a isonomia quando executados por diversas vezes, pois sem manipulação humana a cada teste,
a testabilidade torna-se mais viável e a garantia de qualidade é ampliada consideravelmente.
Figura 10 - Ciclo do Test-driven Development (TDD)
(JEFFRIES; MELNIK, 2007 apud VICENTE, 2010, p. 48)
A partir do ciclo de funcionamento do TDD exposto na Figura 10, é possível perceber
a simplicidade do fluxo de implementação desta técnica de validação, aonde são verificados
os caminhos de falha, aprovação (Passa) e refatoração para cada caso de teste criado. No
primeiro, é preciso realizar testes que validem as regras de negócio, inserindo dados
incorretos ou que possam sobrecarregar o sistema, conferindo assim qual é o nível de
integridade do que fora desenvolvido. Em seguida, é preciso confirmar o “caminho feliz”,
executando a aplicação com dados verídicos e que precisam ser aceitos durante os testes,
confirmando que as regras de negócio foram utilizadas de forma correta na implementação. E,
por fim, há sempre a possibilidade de se otimizar uma aplicação a fim de deixar-lhe mais
eficiente, o que provavelmente resultará em um projeto mais eficaz, utilizando menos
recursos como memória RAM (Random Access Memory), armazenamento permanente (disco
rígido), armazenamento em nuvem (Cloud Computing), recursos de rede, entre outros.
38
6.3
Uma Visão Sobre os Testes de Aceitação (UAT)
Durante o desenvolvimento de qualquer produto é preciso estar atento aos critérios de
qualidade, principalmente àqueles que refletem diretamente à percepção dos clientes, tendo
em vista que estes são os contratantes ou, os compradores, sendo de toda forma, o usuário
final. A partir deste critério, é fácil a visualização de que a aceitação de um produto após o
seu desenvolvimento deve ser um processo crítico e capaz de detectar a completude do
projeto de acordo com os critérios desejados. E, esta aprovação requere a execução de
validações e verificações com uma visão peculiar, esta chamada de “Testes de Aceitação”.
[...] Teste de Aceitação (User Acceptance Testing – UAT) é o estágio final do
processo de teste antes que o sistema seja liberado para uso operacional. O
sistema é testado com dados reais fornecidos pelo mantenedor ao invés de
dados hipotéticos. O teste de aceitação pode revelar erros e omissões na
definição dos requisitos do sistema, uma vez que o dado real exercita o
sistema de diferentes maneiras a partir do dado de teste. Ele também pode
revelar problemas de requisitos, onde as facilidades do sistema realmente não
atendem às necessidades do usuário ou o desempenho do sistema não é
aceitável. (FERREIRA, 2007, p. 185)
O teste de aceitação é um teste formal conduzido para determinar se o Sistema
satisfaz ou não os critérios de aceitação (os critérios de sistema precisam ser
satisfeitos para serem aceitos pelo cliente) e para habilitar o cliente para
determinar se ele aceita ou não o Sistema. (IEEE, 1990, tradução nossa) 30
Diversos autores tratam de forma teórica sobre os testes de aceitação, mas em sua
maioria o contexto de análise é muito similar ao descrito por Bentley & Bank (2005), os quais
comentam sobre as formas de nomenclatura desta atividade, quais são os profissionais
envolvidos durante a execução dos cenários de teste e as expectativas para quando o resultado
final for alcançado.
“[...] o Teste de Aceitação de Usuário (UAT) também pode ser chamado de
Beta testing, Teste de Aplicação (application testing) e Teste de Usuário (enduser testing). Este tipo de teste tende a utilizar dados reais de negócio a partir
dos Sponsors e da equipe de TI para que seja possível desenhar os casos de
teste a fim de que tudo seja executado de forma mais precisa. Entretanto, não
se pode utilizar de usuários randômicos para a execução dos testes, é preciso
haver uma variedade de níveis de conhecimento que participem ativamente e
em um ambiente controlado. (BENTLEY; BANK; 2005, tradução nossa, p. 1)
31
30
Acceptance testing is formal testing conducted to determine whether or not a system satisfies its acceptance criteria (the
criteria the system must satisfy to be accepted by a customer) and to enable the customer to determine whether or not to
accept the system. (IEEE, 1990)
31
User Acceptance Testing is also called Beta testing, application testing, and end-user testing. [...] Performance,
stress, and load testing are all major undertakings and will require substantial input from the business sponsors
39
[...] Uma ocorrência comum na UAT é quando os usuários começam a
trabalhar com a aplicação e eles descobrem que não está fazendo exatamente o
que eles queriam que estivesse fazendo ou está e, embora correto, não é o
ideal. (BENTLEY; BANK; 2005, tradução nossa, p. 1) 32
[...] durante os testes de aceitação é quando o controle de mudança (sendo esta
uma das atribuições da Gerência de configuração de software) precisa ser
seriamente forçado, mas ee vai além do escopo estipulado. Basta dizer que o
aumento de escopo é especialmente perigoso nesta fase final e deve ser
evitado. (BENTLEY; BANK; 2005, tradução nossa, p. 1) 33
Durante os testes de aceitação em maior escala é preciso planejar com maior cautela os
casos de teste e como estes deverão ser executados, pois o cliente estará condicionado a atuar
efetivamente nos processo de validação do produto. É preciso estar ciente de que serão
testadas não apenas regras de negócio, mas também a performance do sistema e como ele se
comporta em situações inesperadas, tendo em vista os perfis distintos dos usuários (experts,
leigos, etc). A cada etapa iniciada torna-se necessário que o líder do projeto esteja atento a
esta etapa do ciclo de desenvolvimento, pois qualquer dano tenderá a impactar mais no
orçamento e no uso de recursos humanos e tecnológicos. Então, é neste momento que a visão
conjunta de programadores e testadores ao início do projeto, durante a etapa de
implementação do código, tende a ter um valor acima do normalmente percebido por ambos.
O relacionamento entre estes profissionais é essencial a fim de mitigar os riscos logo nos
primeiros passos, e o uso de metodologias ágeis auxiliam muito no comprometimento de
ambos para que o sucesso seja alcançado.
Com o intuito de amplificar ainda mais este comparativo, é viável a relação da questão
com o Modelo em V (V-Model), “[...] incorpora o teste dentro de todo o ciclo de vida do
desenvolvimento de software [...]” (BENTLEY; BANK, 2005, p. 4, tradução nossa). Neste, é
possível visualizar quão importante significa cada fluxo do SDLC, exibindo o relacionamento
and IT staff in setting up a test environment and designing test cases that can be accurately executed. Because of
this, these tests are sometimes delayed and made part of the User Acceptance Testing phase. [...] UAT cannot be
random users playing with the application. A mix of business users with varying degrees of experience and
subject matter expertise need to actively participate in a controlled environment. (BENTLEY; BANK, 2005, p.
1)
32
A common occurrence in UAT is that once the business users start working with the application they find that it doesn’t do
exactly what they want it to do or that it does something that, although correct, is not quite optimal. (BENTLEY; BANK,
2005, p. 1)
33
During UAT is when change control must be most seriously enforced, but change control is beyond the scope of this paper.
Suffice to say that scope creep is especially dangerous in this late phase and must be avoided. (BENTLEY; BANK, 2005, p.
1)
40
entre as etapas e deixando claro que, em caso de falhas durante os testes de aceitação, todo o
processo terá que regredir para a especificação de requisitos a fim de afirmar a solicitação do
cliente para que seja recodificado (correção do defeito), fazendo assim com que todo o projeto
entre em uma possível rota de descumprimento ao cronograma, o que gerará maiores custos
ao negócio.
Figura 11 - Modelo em V do Teste de Software
(CRAIG e JASKIEL, 2002)
Na Figura 11, é possível visualizar V-Model e o pleno relacionamento entre as etapas
de Desenvolvimento e de Teste de Software.
[...] a execução do “V” inicia de baixo para cima, da esquerda para a direita,
descrevendo a sequência básica do desenvolvimento e das atividades de teste.
O modelo destaca a existência de diferentes níveis de testes e descreve o
caminho de cada diferente fase do desenvolvimento [...] (BENTLEY; BANK,
2005, p. 4, tradução nossa) 34
De acordo com Dias Neto (2007), o V-model defendido por Craig & Jaskel (2002) descreve
que “o planejamento e projeto de testes deve ocorrer na sequência oposta, de cima para
baixo”:
1. “Inicialmente é planejado o teste de aceitação a partir do documento de requisitos;”
2. “Após isso é planejado o teste de sistema a partir do projeto de alto nível do software;”
3. “Então, ocorre o planejamento dos testes de integração a partir o projeto detalhado;”
4. “E por fim, o planejamento dos testes a partir da codificação.”
34
[...] incorporates testing into the entire software development life cycle. In a diagram of the V-Mode*l, the V
proceeds down and then up, from left to right depicting the basic sequence of development and testing activities.
The model highlights the existence of different levels of testing and depicts the way each relates to a different
development phase. (BENTLEY; BANK, 2005, p. 4)
41
7
CONSIDERAÇÕES FINAIS
Toda esta análise sobre a qualidade e seus processos dentro do contexto de
desenvolvimento de software tem, indubitavelmente como resultado, o reconhecimento de sua
importância para com todo o ambiente e seus atores, sejam eles internos ou externos,
provando também aos programadores que o nível de relacionamento e dependência entre estes
e os times de qualidade de software é mais alto do que aparenta ser durante o cotidiano.
Entretanto, é preciso ter o conhecimento de que, como explicitado por Li (1990, p.3, tradução
nossa)35, “o teste de software não deve ser confundido com atividades de validação de código
(debugging), pois é um processo de encontrar erros “desconhecidos” aonde antes apenas havia
erros ‘conhecidos’”. O objetivo da atividade de teste não é apenas o de encontrar erros em um
software caso este não faça o que devia fazer, mas se o fizer devem-se buscar defeitos e mau
funcionamento.
Desta forma, a proposta de auxiliar os programadores na visualização da importância
das atividades de teste está em cada uma das linhas deste artigo, tendo como papel principal,
provar aos programadores a importância das atividades de teste e dos analistas de
qualidade/testadores no contexto do desenvolvimento de software. O modo encontrado para
isso remete a explicações teóricas sobre como a qualidade está inserida no ciclo de
desenvolvimento de software (SDLC), a partir de seus modelos de processo e análises sobre o
contexto de desenvolvimento sob os aspectos das metodologias Ágeis, pois nestas, estes
profissionais atuam com funções agregadas, muito além da programação, tendo em vista que a
simples existência de User Stories (estórias) – na eXtreme Programming – havendo aqui uma
similaridade para com os casos de uso (use cases), muito usados nos processos de
desenvolvimento e de testes funcionais.
Os Testes Ágeis trazem a tona o relacionamento dos programadores às atividades de
teste, pois o desenvolvimento de roteiros para que se possa iniciar a implementação de código
revela a necessidade de adequação ao princípio da criação de casos de teste (test cases), pois
mesmo quando automatizados, cada etapa finalizada passará pelo crivo de atividades de testes
unitários (unit tests - UT), demonstrando assim que toda a tese que conteste a importância dos
profissionais de teste é inadequada e desnecessária, desmistificando o preconceito para com
estes.
35
Software testing should not be confused with software debugging. The former is a process of finding
"unknown" errors whereas the latter a process of removing "known" errors. […] the objective of testing is to find
errors in a software and to see not only if this software does not do what it is supposed to do (i.e. a deficiency),
but if it does what it is not supposed to do (i.e. a malfunction). (LI, 1990, p. 3)
42
REFERÊNCIAS
AGILE ALLIANCE, Manifesto For Agile Software Development, 2001a, tradução:
Manifesto para o desenvolvimento ágil de software, 2001a. Disponível em:
http://manifestoagil.com.br/. Acesso em: 08 out. 2015.
BARDIN, L., Análise de conteúdo, p. 47, São Paulo: Edições 70, 2011, ISBN: 8562938041.
BASTOS, Anderson et al. Base de conhecimento em testes de software, 2007, pg. 41,
I.S.B.N.: 8599102893.
BENTLEY, John E.; BANK, Wachovia. Software Testing Fundamentals—Concepts,
Roles, and Terminology, Planning, Development and Support, Paper 141-30, SUGI 30,
Volume 30, Charlotte, NC, 2005.
BERANDER, Patrik, et al., Software quality attributes and trade-offs, Blekinge Institute of
Technology, June 2005. Disponível em:
http://www.uio.no/studier/emner/matnat/ifi/INF5180/v10/undervisningsmateriale/readingmaterials/p10/Software_quality_attributes.pdf. Acesso em: 19 de out. 2015.
BOEHM, B., Software Engineering Economics, Prentice-Hall, 1981.
BOEHM, B. e TURNER, R. Balancing Agility and Discipline, p. 25,30,31,42, Boston,
Addison-Wesley, 2004, ISBN ISBN 0-321-18612-5. Disponível em:
http://ptgmedia.pearsoncmg.com/images/9780321186126/samplepages/0321186125.pdf.
Acesso em: 25 out. 2015.
CAETANO, Cristiano. Melhores Práticas na Automação de Testes. Revista Engenharia de
Software Magazine, Ed. 5, p. 42-47, 2008. Disponível em:
http://www.devmedia.com.br/artigo-engenharia-de-software-5-melhores-praticas-naautomacao-de-testes/10249. Acesso em: 24 set. 2015.
CRAIG, R.D., JASKIEL, S. P., Systematic Software Testing, Artech House Publishers,
Boston, 2002.
CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide For Testers and
Agile Teams, 1st edition, The Addison Wesley Signature Series, A Mike Cohn Signature
Book, Pearson Education Inc., 2009. Disponível em: http://chellie.com.au/blog/wpcontent/uploads/2013/08/Addison-Wesley-Agile-Testing-A-Practical-Guide-for-Testers-andAgile-Teams-2009.pdf. Acesso em: 08 out. 2015.
DIAS NETO, Arilo C. D., Introdução a Teste de Software, In: Qualidade de Software:
Entenda os principais conceitos sobre Testes e Inspeção e Software, Engenharia de Software
Magazine, Ano 1, Edição 1, Edição Especial, DevMedia, 2007. Disponível em:
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-desoftware/8035#ixzz3r6uzKKVH. Acesso em: 10 nov. 2015.
DUDZIAK, Thomas. eXtreme Programming An Overview - Methoden und Werkzeuge
der Softwareproduktion (WS), p. 4, 1999/2000. Disponível em:
http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf. Acesso em: 25 set. 2015.
FERRARI, Sandra. Proposta de Metodologia Para Controle de Qualidade em Uma
Fábrica de Software, Tese de Doutorado, Programa de Pós-Graduação em Engenharia de
Produção, Universidade Federal de Santa Catarina, 2007, p. 185
43
GAŁĘZOWSKI, Grzegorz. Test-Driven Development: Extensive Tutorial, Leanpub.com,
Creative Commons Attribution 3.0 Unported License, 03 de Setembro de 2.015. Disponível
em: http://leanpub.com/tdd-ebook. Acesso em: 08 set. 2015.
GORDON, Steven R.; GORDON, Judith R. Sistemas de Informação Uma Abordagem
Gerencial, LTC, 3ª edição, 2006, 377 páginas, ISBN 8521614799, 9788521614791.
HENDRICKSON, Elisabeth. Driving Development with Tests: ATDD and TDD, Quality
Tree Software, Inc., 2008. Disponível em: http://testobsessed.com/wpcontent/uploads/2011/04/atddexample.pdf. Acesso em: 08 set. 2015.
HENDRICKSON, Elisabeth. Tester Developers, Developer Testers, Test Obsessed, 2007.
Disponível em: http://testobsessed.com/2007/01/tester-developers-developer-testers/. Acesso
em: 12 out. 2015.
HUSTON, Tom. What is Agile Testing? A Brief Overview of the Agile Approach to
Software Development and Testing, SmartBear Software, 2015. Disponível em:
http://smartbear.com/allresources/articles/whatisagiletesting/. Acesso em: 21 set. 2015.
IEEE (1990). IEEE Standard 610.12-1990, IEEE Standard Glossary of Software
Engineering Terminology.
JEFFRIES, R.; MELNIK, G., Guest editor's introduction: TDD-the art of fearless
programming, IEEE Software, v. 24, n. 3, p. 24-30, 2007.
LI, Eldon Y., Ph. Software Testing In A System Development Process: A Life-Cycle
Perspective, Journal of Systems Management, 41 (8), August 1990, 23-31. Disponível em:
http://www.cob.calpoly.edu/~eli/pdf/jsm-90.pdf. Acesso em: 21 out. 2015.
LAHOZ, Carlos;SANT'ANNA, N. Os padrões ISO/IEC 12207 e 15504 e a modelagem de
processos da qualidade de software, Anais, III Workshop dos Cursos de Computação
Aplicada do INPE, p. 2, 2003 . Disponível em: http://mtcm18.sid.inpe.br/col/lac.inpe.br/worcap/2003/10.20.14.01/doc/LahozWorkcap_versaofinal.pdf.
KOTESKA, Bojana; MISHEV, Anastas. Agile Software Testing Technologies in a Large
Scale Project, Faculty of Sciences, University of Novi Sad, Novi Sad, Serbia, 2012, p. 122,
ISBN 978-86-7031-200-5. Disponível em: http://ceur-ws.org/Vol-920/p121-koteska.pdf.
LOVAASEN, G. Brokering with eXtreme Programming, 2001, p. 4, XP Universe
Conference Papers. Disponível em:
http://cf.agilealliance.org/articles/system/article/file/983/file.pdf. Acesso em: 08 out. 2015.
MACIEL, Ana C. F., VALLS, Carmem, SAVOINE, Márcia M. Análise da Qualidade de
Software Utilizando as Normas 12207, 15504, ISO 9000-3 e os Modelos CMM/CMMI e
MPS.BR, Revista Científica do ITPAC, Araguaína, v. 4, n. 4, Pub. 5, p. 4, Outubro 2011,
ISSN 1983-6708.
MARTIN, Robert C. Professionalism and Test-Driven Development, IEEE Software, IEEE
Computer Society, Maio/Junho 2007, p. 32-36. Disponível em: http://www-public.itsudparis.eu/~gibson/Teaching/CSC7302/ReadingMaterial/Martin07.pdf. Acesso em: 08 set.
2015.
NBR ISO/IEC 9126-1: 2003, Engenharia de Software – Qualidade de produto, ABNT –
Associação Brasileiras de Normas Técnicas, 21 páginas.
44
PRESSMAN, Roger S. Engenharia de software. 5. ed. São Paulo: Makron Books, 2002.
872p.
PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional, 7, p. 29,
AMGH Editora Ltda., Porto Alegre, 2011. 780p, I.S.B.N. 9788563308337.
SERENA SOFTWARE. An Introduction To Agile Software Development, Junho 2007.
Disponível em: http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf.
Acesso em: 25 set. 2015.
SOMMERVILLE, Ian. Software Engineering, 9th. edition, 2011, p. 28,30,33,35,656,657,
ISBN-13: 978-0-13-703515-1, ISBN-10: 0-13-703515-2.
SOMMERVILLE, Ian. Engenharia de Software, 9ª edição, Pearson, Prentice Hall, São
Paulo, SP, 2011, tradução OLIVEIRA, Kalinka; BOSNIC, Ivan, p.32-33,144, ISBN 978-857936-108-1.
VICENTE, André A., Definição e gerenciamento de métricas de teste no contexto de
métodos ágeis, Tese de Mestrado, Instituto de Ciências Mateáticas e de Computação ICMC/USP, Universidade de São Paulo, São Carlos, SP, p. 50, Março de 2.010.
WESTFECHTEL, Bernhard; HOEK, André V. D., Software Configuration Management,
Springer Science & Business Media, p. 192, ICSE Workshops SCM 2001 and SCM 2003,
Toronto, Canada, May 14-15, 2001, and Portland, OR, USA, May 9-10, 2003. Selected
Papers, Volumes 10-11, 273 pages, ISSN 0302-9743, ISBN 3-540-14036-0 Springler-Verlag
Berllin Heidelberg New York.
WILLIAMS, Laurie. Agile/Automated Testing, North Carolina State University, 2004.
Disponível em: http://agile.csc.ncsu.edu/SEMaterials/AgileTesting.pdf. Acesso em: 21 set.
2015.
WIRTH, Niklaus. A Brief History of Software Engineering, ETH Zürich, IEEE Annals of
the History of Computing, IEEE Computer Society, p. 32, 2008. Disponível em: http://wwwpublic.int-evry.fr/~gibson/Teaching/CSC7003/ReadingMaterial/Wirth08.pdf. Acesso em: 17
out. 2015.

centro universitário de araraquara núcleo de

Transcrição

Documentos relacionados

Agile•1 Anuncia os vencedores dos Prêmios de Excelência para

Adoção das práticas ágeis: Uma verificação de realidade em

Abrir PDF

Prof. Dr. Abdulhusein Hasanali Paliwala

FLYER RIO20.indd

I CBSoft 2015

O FUTURO GLOBAL DO CAPITALISMO VERDE Dr. Marc A. Weiss

Desenvolvimento

RESUMO PONTES, Matheus Dantas Madeira. POLÍTICAS

Plano de Curso