Utilização de Agile e Testes de Software: uma abordagem sobre a melhoria da
produção de software com redução de custos
Using Agile and Software Testing: an approach about to improving software
production with cost reduction
Augusto Nogueira Zadra1
Deivid Edson Andrade Vilela2
Rudger Marcellos Reis Dias Freitas3
Resumo: Este artigo tem como por objetivo fazer um contraponto entre as metodologias ágeis e a importância de se testar um software em desenvolvimento buscando a máxima qualidade e o menor custo, em busca de uma base conceitual e teórica realizou-se a pesquisa do tipo exploratória.
Palavras-chave: Software, Métodos Ágeis, Teste.
Abstract: This article aims to make a counterpoint between agile methodologies and the importance of testing a software in development seeking a maximum quality and lower cost, in search of a conceptual and theoretical basis when there was a research of the exploratory type.
Keywords: Software, Agile Methodology, Test.
1Mestre em Tecnologia da Informação Aplicada à Biologia Computacional. Professor na Faculdade
Infórium de Tecnologia.
2Graduando em sistemas de informação na Faculdade Infórium de Tecnologia..
3Graduando em sistemas de informação na Faculdade Infórium de Tecnologia..
1 INTRODUÇÃO
Historicamente a fabricação de software apresenta alguns percalços: a
qualidade se opõe ao prazo, a burocracia se opõe ao desejo do cliente. Contudo,
espera-se que os desenvolvedores consigam fazer softwares de qualidade com
prazos cada vez menores observando as boas praticas e buscando o menor custo
possível; diante disso, devemos considerar as metodologias ágeis, os modelos de
teste, sem deixar que o orçamento extrapole.
Sabemos que todas as ciências são passíveis de falhas, e o mesmo ocorre
com os sistemas e softwares desenvolvidos pelos programadores. Grandes foram as
evoluções no âmbito da criação de software, mas ainda há muito o que ser
feito.Schach (2009, p. 04) diz que “é fato que os geradores de energia elétrica
falham, porém com uma frequência muito menor que a dos programas de folha de
pagamento. As pontes de vez em quando caem, mas com frequência
consideravelmente menor que os sistemas operacionais”.Schach (2009) lembra
ainda que a OTAN, em 1967, cunhou o termo “Engenharia de Software” equiparando
assim a ato de se construir um software com a construção de um projeto de
engenharia civil, mecânica e etc. Foi com base nessa alegação que em 1976, na
Conferencia de Engenharia de Software da OTAN, realizada em Garmisch na
Alemanha, os conferencistas (Naur, Randell e Buxton) concluíram que a engenharia
de software deveria usar as filosofias e os paradigmas das disciplinas de engenharia
já estabelecidas para resolver o que eles denominaram crise de software. (SCHACH,
2009)
Mesmo com as boas práticas já bem estabelecidas, diversos projetos ainda
são entregues fora dos prazos, com erros, com orçamentos estourados ou até
mesmo são abortados ou, em outras palavras, cancelados, causando, assim, um
grande prejuízo financeiro para as software house.
Para mitigar um problema, um defeito, uma falha, os softwares devem ser
testados. Inicialmente, acreditava-se que os próprios programadores seriam as
pessoas mais indicadas para fazerem essa tarefa, que eram os recursos que
possuíam um conhecimento afundo da matéria, linguagem de programação. Com o
passar do tempo, essa prática caiu em desuso e passou a ser vista como uma má
pratica desenvolvimento, tendo em vista que, ao disponibilizar o produto final para o
cliente, era possível detectar diversas falhas em um software já finalizado.
Bartié(2002, p. 3) lembra que “nos primórdios do desenvolvimento de software, a
atividade de teste era encarada como a simples tarefa de navegar pelo código e
corrigir problemas já conhecidos. Tais tarefas eram realizadas pelos próprios
desenvolvedores, não existindo recursos dedicados a essa atividade”, Bartié (2002,
p. 4) cita ainda que “Em 1957, o conceito Teste de Software conseguiu ampliar seus
valores e se tornou um processo de detecção de erros de software, mas testar ainda
era encarado como uma atividade que ocorria no final do processo de
desenvolvimento.”, com o conceito de engenharia de software é que o teste passou
a ter uma abordagem mais profunda.
Em meados da década de 1980, com o surgimento dos padrões sugeridos por
grandes instituições, como Institute of Eletrical and Eletronics Engineers (IEEE),
American Nacional Standart Institutes (ANST), International Stantards Organization
(ISO) e Compability Maturity Model (CMM) é que o conceito de qualidade de
software foi criado, e os modelos de padrões visavam garantir a qualidade do
produto final, a fim de se mitigar os riscos de futuras falhas, retrabalhos e perdas
financeiras.
Visando a economizar tempo e diminuir custos, empresas de
desenvolvimento de software tendem a ignorar a engenharia de software e seus
processos. Engholm (2013, p. 30) afirma que “...essa ideia é falsa, pois a não
utilização dos métodos adequados no desenvolvimento gera softwares de má
qualidade, que trazem frustação aos usuários, custos adicionais relacionados a
manutenção corretiva e problemas na utilização dos sistema”; cita, ainda, uma
armadilha associada a não utilização da engenharia de software onde é apresentado
um cenário no qual você é precisa dar manutenção em software muito complexo,
qual você não possui nenhuma documentação para consulta, software esse que
você não participou da construção e que um determinado erro precisa ser resolvido
com urgência, Enghom (2013) cita que em média se gasta cerca de 50% dos
esforço profissional para entender o código.
Gomes (2013, p. 68) questiona:
O que é mais barato: descobrir que uma alteração em uma parte do software
criou um defeito em outra através do feedback de um testes de unidade
durante o desenvolvimento e então resolver o problema na mesma hora,
enquanto ainda se está com as regras de negócio em mente; ou descobrir
posteriormente que o defeito existe porque não passou pela qualidade ou,
ainda pior, descobrir que o problema existe apenas quando o software já
estiver em produção?
2 METODOLOGIAS AGILE
Com intuito de desburocratizar os processos que envolviam a construção de
um software o movimento Agile surgiu na década de 90 com o nascimento de
algumas metodologias, tais como Scrum, Extreme Programming, dentre outras
buscando melhorarias no tempo de concepção de um software e consequentemente
uma melhoria nos custos.
Um grande marco se deu em 2001. Gomes (2013) lembra que em 2001
houve uma conferência entre 17 grandes nomes ligados ao desenvolvimento de
software da época, Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber,
Jeff Sutherland e Dave Thomas. A reunião desse grupo teve como intuito discutir as
melhores práticas para o desenvolvimento de um software. Desse encontro se
originou “O Manifesto Ágil, que rege os princípios do desenvolvimento ágil.
O manifesto busca a valorização dosindivíduos e interações mais que os
processos e ferramentas, software em funcionamento mais do que documentação
abrangente, colaboração com o cliente mais que negociação contratual, responder a
mudanças mais que seguir um plano (GOMES, 2013). Com base nesses valores
foramconstituídos os 12 princípios da metodologia ágil:
- Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
- Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
- Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
- Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
- O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
- Software funcional é a medida primária de progresso.
- Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
- Contínua atenção a excelência técnica e bom design, aumenta a agilidade.
- Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
- As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.(GOMES, 2013, p. 3)
Os métodos ágeis geralmente possuem ciclos curtos devido à imprevisibilidade e,
uma vez que o próprio cliente pode não saber de fato o quer, os ciclos
tambémconhecidos como interações e normalmente duram poucas semanas,
sempre fazendo rodadas de feedbacks visando melhorar o tempo de respostas a
mudanças (GOMES, 2013).
Ao contrário dos métodos tradicionais, o ágil busca fazer com início meio e fim
em cada interação abordando o planejamento, análise, design, codificação, testes e
documentação. Já no método tradicional essas etapas são cumpridas em cascata,
cada uma é finalizada para se dá início a outra.
“O processo cascata costuma ser realizado através de fases de análise de
requisitos, projeto (design), implementação, testes, integração e manutenção, de
forma que uma fase é iniciada somente quando a anterior termina”. (GOMES, 2013,
p. 5)
O termo cascata existe desde 1970, foi criado pelo Wiston W. Royce, o modelo
segue um formato conforme Figura 1.
Figura 1 – Desenvolvimento de software em cascata (Waterfall)
Fonte: GOMES, 2013, p.6
Fazendo uma comparação entre os métodos prescritivos e métodos
adaptativos, no qual os adaptativos possuem uma ampla vantagem devido a sua
aderência e flexibilidade, métodos adaptativos possuem melhor adaptação a
projetos distintos. Com comparação temos RUP que possui mais que 120
prescrições enquanto o XP possui 13,Scrum possui somente 9 e o Kanban 3.
“Quanto mais prescritivo um método for, mais específico para um determinado tipo
de contexto ele será” (GOMES, 2013, p.8).
A utilização dos métodos ágeis trazem diversas vantagens, a principal está
relacionada ao valor que é agregado ao cliente com um índice de assertividade
maior e um ganho substancial no quesito tempo. Gomes (2013) cita uma pesquisa
realizada em 2011 pela VersionOne.com, no qual 6.000 pessoas e organizações
foram submetidas. Essa pesquisa teve o intuito de mostra os principais benefícios da
utilização dos métodos ágeis após a mudança do modelo tradicional para o ágil.
Os principais benefícios são:
- Melhor Time-to-market e Maior Retorno sobre o Investimento: Quanto mais cedo
os clientes puderem começar a utilizar o produto, mais rápido receberá o retorno
do valor investido no desenvolvimento do produto, seja através de lucros diretos
gerados pelo produto ou através dos benefícios gerados pela utilização do
produto na organização.
- Maior Satisfação do Cliente e Melhor Gestão de Mudanças de Prioridades: O
planejamento iterativo permite que o cliente facilmente mude suas prioridades
com impacto reduzido na produtividade da equipe porque planeja-se
detalhamento apenas daquilo que está mais próximo de ser feito, evitando
também desperdícios e custos desnecessários. A comunicação constante e a
proximidade com o cliente frequentemente resulta também em um melhor
alinhamento entre os objetivos de TI e com os objetivos de negócio da
organização.
- Melhor Visibilidade dos Projetos: Faz parte da cultura ágil manter as
informações do projeto visíveis e transparentes através de ferramentas como
burndown-charts, e card walls (discutidas posteriormente), com as quais a equipe
e gestão podem acompanhar dia a dia a evolução do projeto em relação às metas
do projeto e das iterações.
- Maior Produtividade: Infelizmente, não há uma forma universalmente aceita de
se medir produtividade de equipes de desenvolvimento de software. Muitos
consideram essa tarefa até impossível ou algo subjetivo demais, mas na pesquisa
supracitada, 75% dos participantes afirmaram ter alcançado melhor produtividade
depois da transição para métodos ágeis.
- Equipes mais Motivadas: Métodos ágeis promovem ritmos sustentáveis de
trabalho, são muitos os casos em que organizações reportaram uma diminuição
significativa nas horas extras e madrugadas trabalhadas depois da transição para
métodos ágeis. A promoção do ritmo sustentável, de uma cultura de qualidade,
de constante comunicação e trabalho em equipe são alguns dos fatores que
contribuem para equipes mais motivadas e satisfeitas com seu ambiente de
trabalho.
- Melhor Disciplina na Engenharia e Melhor Qualidade Interna: A utilização de
práticas ágeis como redução de dívida técnica (melhorar a qualidade interna do
produto), refactoring, desenvolvimento orientado a testes e programação em par,
unido ao mindset de qualidade estimulado de pelos métodos ágeis, contribuem
para a entrega de produtos com melhor mantenabilidade, extensibilidade e com
menos defeitos.
- Processo de Desenvolvimento Simplificado: Os método ágeis são, em regra
geral, menos prescritivos do que os métodos tradicionais, definem menos papéis
e menos artefatos. São mais facilmente compreendidos pela equipe, e oferecem
maior margem para otimização e adaptação para a maior eficiência no contexto
da organização em que está sendo aplicado.
- Redução deRisco: Oplanejamento iterativo e as releases frequentes permitem
que as prioridades do projeto sejam reajustadas constantemente.Métodos ágeis
possibilitam que as incertezas do projeto, no nível dos requisitos, ou no nível
técnico, sejam estimadas e distribuídas de forma inteligente nos releases, para
manter o risco sempre balanceado. Além disso, as entregas em prazos curtos
oferecem maior visibilidade da velocidade do time, oferecendo maior
previsibilidade do prazo necessário para concluir o projeto.
- Redução de Custos: Equipes ágeis são menos propensas a desenvolver
funcionalidades de baixa prioridade ou que se tornaram desnecessárias ao longo
do tempo. Abordagens não ágeis geralmente tendem a cair nesse problema
devido ao grande espaço de tempo entre o levantamento dos requisitos e entrega
do produto. (GOMES, 2013, p. 10)
Principais Métodos Ágeis e seus benefícios
Extreme Programming – XP
O conceito Extreme Programming foi inicialmente divulgado por Kent Beck na
década de 90, esse método busca uma abordagem técnica sobre o desenvolvimento
de um software abordando a codificação, design e testes. Ele é pautado por quatro
atividades chaves Ouvir, Desenhar, Codificar e Testar (TELES, 2006).
Planejamento
O planejamento da metodologia ágil em XP para as empresas desenvolvendo
um software com requisitos disponíveis para que possam ser mudados.
Vai ser baseado na revisão do código fonte, fazendo todos os testes sendo
repetidos em curtos prazos, participações dos usuários finais, integração continua,
planejamento, projeto e sendo projetado novamente quando necessário em qualquer
hora.
O XP é uma das mais conhecidas metodologias de desenvolvimento de
software que seguem os princípios ágeis; foi criado em 1996 tendo a total
colaboração nas boas práticas de programação (TELES, 2006).
As metodologias tradicionais de desenvolvimento foram criadas em um
cenário atual. Anteriormente as limitações tecnológicas e a falta de ferramentas para
a criação de softwares, tinham um custo muito elevado para o seu desenvolvimento
e manutenção. Portanto, era essencial planejar e documentar todo o software para
então implementá-lo (VIANA & DESCHAMPS, 2007).
Para Teles (2006) as boas práticas da XP que as equipes XP teriam um
conjunto de atividades para produzirem softwares. Antes de qualquer coisa teria que
ter confiança nas práticas a serem desenvolvidas para aplica-las em conjunto, pois
aplicadas separadas não trazem os resultados esperados, pois os pontos fracos de
cada prática é protegida pelos pontos fortes das demais práticas.
Em projetos do XP o cliente tem que participar ativamente do processo de
desenvolvimento, seria uma prática que necessita e que acreditamos ter a presença
do cliente para mostrar e facilitar a clara comunicação dos processos com os
desenvolvedores. O cliente sempre presente facilita a total comunicação e quaisquer
dúvidas para que os desenvolvedores sejam sanadas de forma rápida, fazendo com
que o cliente deve possuir a capacidade de responder as perguntas sobre o negócio
e tomar decisões relativas a prioridades no projeto (TELES, 2006).
Realease é uma funcionalidade de uma versão pequena do sistema porém
com recursos completos e importantes ao cliente. A versão é colocada em produção
mais rápida para o cliente usar e usufruir do seu investimento no software e avaliar
dando assim o feedback para os desenvolvedores sobre o release. Representa uma
pequena versão do sistema com todos os recursos completos para o cliente.
A programação em dois ou (programação em par) como costumam dizer, os
desenvolvedores escolhem uma user story em um único computador para que seja
feita a codificação de uma determinada função do sistema. Sempre o desenvolvedor
com menos experiência tem a responsabilidade de assumir o teclado e guiar
ativamente a programação do seu código, enquanto o outro desenvolvedor com
mais experiência examina o código para procurar os erros e defeitos, além de
questionar as decisões e pensar em soluções mais simples para o código (TELES,
2006).
Teles (2006) diz que as vantagens com a programação em par, proporciona a
“ pressão do parceiro” de uma forma bem saudável de manter a disciplina durante
toda a jornada de trabalho e mostrar um desempenho melhor de uma forma de que
um programador ajuda sempre o outro a não deixar passar pelos erros
despercebidos.
O processo de refactoring é um processo de organização do código fonte do
software e melhorar a qualidade interna, melhorando sempre a sua leitura de
diminuir o tempo gasto em manutenção e não prejudicar o seu desempenho ou
alterar o comportamento externo. Essa prática é necessária para que possa fazer
alterações e novas inclusões de suas funcionalidades constantes no sistema, isso é
possível com um software de qualidade e bem organizado e de fácil compreensão. A
XP determina que qualquer equipe faça o refactoring em todos os códigos que
sejam pouco legível. Testes garantem a segurança, e, após cada alteração, eles
informam se o código continua produzindo os resultados esperados (TELES, 2006).
Os riscos vão depender da complexidade ou do próprio ambiente de
desenvolvimento, pois alguns riscos são universais que são considerados pela
Engenharia de software. Os riscos vão depender, como, por exemplo: alteração nos
requisitos, significa mudanças não previstas ou atrasos na especificações, que
seriam essenciais não disponíveis no prazo, a documentação completa pois os
clientes exigem a documentação, perda de alguns membros da equipe em períodos
cruciais que pode ocasionar por doenças ou ate mesmo demissões, entrada de
novas pessoas nesse caso a perda de mão-de-obra teria que treinar novas pessoas
e mudanças gerenciais para a organização com prioridades diferentes, e claro
tamanho do sistema bem maior do que o estimado e acarreta em atrasos pois o
tamanho subestimado bem maior que o planejado. (SOMMERVILLE, 2007);
(TELES, 2006).
Baseando-se no que foi estudado até o momento sobre Desenvolvimento
Tradicional e Desenvolvimento Ágil, dando níveis de Alto e Baixo nas questões
levantadas por (SOMMERVILLE, 2007); (TELES, 2006).
Essa prática deve ser utilizada para que alguns usuários possam utilizar o
software e avaliar, pois dessa forma vários tipos de defeitos podem ser detectados
rapidamente, possibilitando à equipe de desenvolvimento saber se está no caminho
certo ou não.
O XP é composto por partes, Teles (2006) fala que as partes são os valores
,estabelecem a forma do desenvolvimento; princípios, guiam o desenvolvimento do
software; atividades, sendo executadas por todo o ciclo do XP; e praticas; utilizada
pelas equipes XP para desenvolver sistemas.
Os valores do XP são compostos por comunicação, simplicidade
retroalimentação e coragem (TELES, 2006).
Várias práticas do XP promovem uma maior comunicação entre os membros
da equipe.Comunicação não limita por procedimentos formais. Deve-se usar o
melhor meio possível, que podendo ser conversas ou reuniões informaise-mail, bate-
papo, telefonemasou até mesmo o próprio código (TELES, 2006).
Preferencialmente a comunicação ágil deve ser simples.XP incentiva ao
extremo as práticas que reduzam a complexidade do sistema. A solução adotada
deve ser sempre a mais simples para que alcance os objetivos esperados.
O usodas tecnologias, algoritmos e técnicas mais simples que permitirão
atender aos requisitos do usuário final.
Várias práticas de XP garantem um rápido feedback sobre várias
etapas/partes do processo.A solução adotada deve ser sempre a mais simples que
alcance os objetivos esperados.
Feedback sobre qualidade do código (testes de unidade, programação em
pares, posse coletiva)sobre estado do desenvolvimento (estórias do usuário-final,
integração contínua, jogo do planejamento). Elementos que possibilitam maior
agilidade possibilitando que erros detectados sejam corrigidos imediatamente,
requisitos e prazos são reavaliados mais cedo e permite estimativas mais precisas
(TELES, 2006).
Testes, integração contínua, programação em pares e outras práticas de XP
aumentam a confiança do programador e ajudam-no a ter coragem para melhorar o
código que está funcionando para torná-lo mais simples possibilitando investir tempo
no desenvolvimento de testes, mexer no design em estágio avançado, pedir ajuda
aos que sabem mais, abandonar processos formais e ter o projeto e a
documentação em forma de código (TELES, 2006).
Para Teles (2006) os princípios XP são:
- Rapid Feedback - (retorno rápido).
- Assume Simplicity - (simplicidade).
- Incremental Change - (mudanças incrementais).
- Embrace Change - (aceitar mudanças).
- Quality work - (trabalho de qualidade).
Rapid Feedback
O retorno entre os desenvolvedores é rápido. Cliente sabe se o produto que
está sendo desenvolvido atende às suas necessidades. Modele um pouco, mostre
ao cliente e então modele novamente. Garante que o seu modelo será preciso
enquanto seu conhecimento do projeto aumenta (TELES, 2006).
Assuma Simplicity (simplicidade)
Deixe o seu modelo tão simples quanto possível e assuma que a solução
mais simples é a melhor. O design do sistema deve ser feito para a iteração
corrente. Não deve ser feito design sobre uma possível necessidade futura (TELES,
2006).
Mudanças Incrementais
O modelo não será feito na primeira tentativa, irá mudar de acordo com o
desenvolvimento do projeto ao seu decorrer. Os problemas será sempre solucionado
com um conjunto de pequenas modificações (TELES, 2006).
Aceite as mudanças
Mudanças no projeto ocorrerão de acordo com o crescimento do
entendimento do mesmo. Aceite as mudanças e tenha coragem para reconstruir
(TELES, 2006).
Trabalho de qualidade
A qualidade do trabalho nunca deve ser comprometida, XP leva a importância
da codificação e do teste antes da programação (TELES, 2006).
Testes de aceitação
Testes de aceitação são elaborados pelos clientes, são testes automáticos, se
rodam com sucesso afuncionalidade foi implementada são repetidos a cada
alteração,se tem a informação de quanto já foi implementado e quanto falta,
(feedback) (TELES, 2016).
Scrum
O Scrum é um processo de desenvolvimento iterativo e incremental para
gerenciamento de projetos e desenvolvimento ágil de software. Apesar de a palavra
não ser um acrônimo, algumas empresas que implementam o processo a soletram
com letras maiúsculas como SCRUM. Isto pode ser devido aos primeiros artigos de
Ken Schwaber, que capitalizava SCRUM no título (GOMES, 2013).
Apesar de Scrum ter sido destinado para gerenciamento de projetos de
software, ele pode ser utilizado em equipes de manutenção de software ou como
uma abordagem geral de gerenciamento de projetos/programas (SABBAGH, 2013).
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de
projetos em empresas de fabricação de automóveis e produtos de consumo,
por Takeuchi e Nonaka em 1986. Eles notaram que projetos usando equipes
pequenas e multidisciplinares (cross-functional) produziram os melhores
resultados, e associaram estas equipes altamente eficazes à formação Scrum
do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland,
John Scumniotales e Jeff McKenna conceberam, documentaram e
implementaram o Scrum, conforme descrito abaixo, na empresa Easel
Corporation em 1993, incorporando os estilos de gerenciamento observados
por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de
Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o
mundo. Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo
de Hirotaka Takeuchi e Ikujiro Nonaka. A função primária do Scrum é ser
utilizado para o gerenciamento de projetos de desenvolvimento de software.
Ele tem sido usado com sucesso para isso, assim como Extreme
Programming e outras metodologias de desenvolvimento. Porém,
teoricamente pode ser aplicado em qualquer contexto no qual um grupo de
pessoas necessitem trabalhar juntas para atingir um objetivo comum, como
iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o
planejamento de um casamento. (FREITAS, 2016, p. 173).
O Scrum pode ser utilizado para gerenciamento de equipes de manutenção
ou abordado para gerir programas, sua metodologia não se aplica apenas aos
projetos de desenvolvimento de software.
Sabbagh (2013)fala que dentre os benefícios do Scrum, podemos incluir:
- Entregas frequentes de retorno ao investimento dos clientes;
- Redução dos riscos dos projetos;
- Maior qualidade no produto gerado;
- Mudanças utilizadas como vantagem competitiva;
- Visibilidade do progresso do projeto;
- Redução dos desperdícios;
- Aumentando a produtividade.
O projeto pode ser entregue desde cedo e partes do produto funcionando, o
Scrum possibilita essa entrega e proporciona o investimento realizado pelos clientes
do projeto, e possibilita o feeedback rápido do produto para que realize as mudanças
necessárias ou inclusões de forma necessária para os clientes.O Scrum possibilita
um curto prazo para introdução do produto no mercado, sendo que cada entrega
representa um produto funcional (SABBAGH, 2013).
Scrum visa à redução dos riscos do projeto ajudado pela colaboração com os
clientes e os demais interessados durante e no decorrer do projeto.Esses riscos são
a reduzidos no decorrer da produção em ciclos curtos nas entregas das partes
prontas do produto, das partes mais importantes em volta as menos importantes
(SABBAGH, 2013).
A cada ciclo de desenvolvimento tem que possuir a qualidade necessária para
ser entregue para os clientes do projeto. A equipe que trabalha com o Scrum é
responsável pelo trabalho, e possui todas as qualidades necessárias para fazê-los.
As mudanças ocorridas como vantagem são acolhidas como oportunidades e
não como acontecimentos indesejáveis, essas mudanças compreendem a
descoberta dos detalhes do produto, é um processo incremental que ocorre durante
todo o projeto.
O progresso do projeto visa a diversas praticas e artefatos do Scrum para
garantir a visibilidade do progresso do projeto para os participantes envolvidos.
Para reduzir os desperdícios e reduzir evitando por meio da busca da
simplicidade. A equipe que usa Scrum produz e utilize apenas o que é necessário e
suficiente.
Sabbagh (2013) cita algumas regras que ajudam a evitar alguns tipos de
desperdícios.
- Produzir apenas o que os usuários irão utilizar;
- Planejar apenas com nível de detalhes possível;
- Utilizar apenas os artefatos necessários e suficientes.
Uma pesquisa da Standish Group divulgada em 2002, época em que Scrum e
Agilidade eram pouco utilizados, mostra que mais da metade das funcionalidades
solicitadas pelos clientes para o projeto e produzidas nunca ou raramente eram
utilizadas,caracterizando um enorme desperdício.
O desperdício pode ocorre quando define o produto de um alto nível de
detalhes no começo do seu desenvolvimento mesmo que já passaram despendam
em reuniões para levantamento e analise dos requisitos. O desperdício ao se
concentrar em criar e manter apenas o que de fato será utilizado(SABBAGH, 2013).
A documentação além do suficiente e necessário desperdício. Essa
documentação em excesso muda o foco do que realmente é necessário e gera
maior desperdício.
Sabbagh, (2013) diz que o aumento da produtividade e os diversos fatores
que podemos aumentar produtividade com a utilização do Scrum:
- O trabalho em equipe e a autonomia do time na realização desse trabalho;
- A existência de facilitação e de remoção de impedimentos;
- A melhoria continua dos processos de trabalho;
- Um ritmo sustentável de trabalho;
- A maior motivação do time.
O time de um projeto com Scrum é pequeno, de forma que seus membros
possam
interagir e se comunicar durante todo o dia para realizar o trabalho. Trabalhar em
equipe é considerado essencial para o sucesso do projeto.
O time tem autonomia para decidir o quanto é possível de se fazer em um
ciclo e como irá fazê-lo e, assim, ajusta a meta de forma que possa se comprometer
com ela. Os membros do time, então, tornam-se igualmente responsáveis por atingir
essa meta, o que estimula a cooperação entre eles em busca desse objetivo. Assim,
a responsabilidade sobre o trabalho não é individual, mais coletiva(SABBAGH,
2013).
O time que utiliza Scrum está sempre em busca de melhorar a forma de
realizar o trabalho, para tornar mais eficiente. A reunião de sprint retrospective,
sempre realizada ao final de cada ciclo de desenvolvimento, e busca garantir essa
prática (SABBAGH, 2013).
A melhoria contínua promovida pelo time o leva a um aumento progressivo da
sua eficiência na realização do trabalho, o que por sua vez o leva a um aumento
progressivo na sua produtividade.
O ritmo sustentável de trabalho e as praticas de horas-extras forçada do ritmo
de trabalho, utilizado para cumprir o trabalho no prazo determinado, sempre vai
gerar estresse no time que desenvolve o produto e não tardam em derrubar a sua
produtividade e a qualidade do produto gerado.
Cada ciclo de desenvolvimento possui uma duração fixa. De forma similar,
todas as reuniões prescritas pelo Scrum possuem uma duração máxima dentro da
qual
devem ocorrer. São os chamados timeboxes que, quando respeitados com rigor,
auxiliam o time a alcançar esse ritmo constante e sustentável de trabalho.
A motivação do time é ao mesmo tempo consequência dos fatores descritos
anteriormente e causador de um aumento na produtividade. São fatores que
aumentam a motivação, se o time trabalhar em um ambiente que apoie o trabalho, o
que inclui a disposição de todas as ferramentas necessárias para realizar o trabalho
e a organização e confiança de sua gerência(SABBAGH, 2013).
KANBAN
Kanban se difere das outras metodologias ágeis no quesito interação, ele
basicamente não possui interações, seu foco está voltado para cadência, repetições
que ocorrem em intervalos regulares. O Kanban desacopla o planejamento,
priorização, desenvolvimento e entrega, assim cada etapa possui sua própria
cadência. (GOMES, 2013)
O Kanban trabalha com fluxo contínuo não dependendo da finalização do
trabalho planejado para que uma entrega seja realizada, no momento da entrega as
atividades prontas serão entregues e as que ainda não foram concluídas ficaram
para a próxima, sua adaptação é baseada no contexto.
Figura 2 – Fluxo do Kanban
Fonte: GOMES, 2013, p. 16
Baseado no modelo de produção da Toyota (TPS), o Kanban possui uma
ligação direta entre as etapas, onde uma etapa do processo é acionada pela etapa
anterior, “poderíamos dizer que a demanda para se trabalhar em uma nova
funcionalidade seria gerada quando alguma outra fosse entregue” (GOMES, 2013, p.
17).
Segundo Gomes (2013) esse é um método com poucas prescrições, ele
descreve somente três:
- Visualizar o fluxo de trabalho (workflow);
- Limitar o trabalho em progresso;
- Gerenciar e medir o fluxo.
Esse método é altamente adaptativo, pois não possui quase nenhuma
interação tornando-o assim aplicável em qualquer contexto desde que observado as
devidas adequações.
3 TESTES DE SOFTWARE
Falhas ocorrem em qualquer projeto. Somos humanos e estamos suscetíveis
a erros, que podem ocorrer em qualquer etapa do projeto. Mas o quanto antes for
descoberto menor será o prejuízo. Com a tentativa de mitigar as falhas foram
criados vários tipos de testes de software, segundo Pressman (1995, p. 786), “Não é
incomum que uma organização de software gaste 40% do esforço de projeto total
em teste”. O teste tem como seus principais objetivos:
1. A atividade de teste é o processo de executar um programa com intenção de descobrir um erro.
2. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.
3. Um teste bem sucedido é aquele que revela um erro ainda não descoberto. (PRESSMAN apud MYERS, 1995, p. 788)
O teste de softwares tem se mostrado uma das formas mais eficaz de se
chegar ao objetivo pretendido, ou seja, entregar o produto final fazendo aquilo que
foi proposto, para Sommerville (2013, p. 144), os teste tem dois objetivos
“Demonstrar ao desenvolvedor e ao cliente que o software atende seus requisitos” e
“Descobrir situações em que o software se comporta de maneira incorreta,
indesejável ou de forma diferente das especificações”.
Pressman(1995) cita dois tipos de testes, os testes caixa branca, no qual se
busca executar cada funcionalidades ao menos uma vez, colocando a prova a lógica
do programa e garantindo assim seu funcionamento. O outro tipo são os testes caixa
preta onde que buscam validar os requisitos funcionais não levando em
consideração o funcionamento interno do programa. Pressman (1995) lembra que o
teste não acaba ao entregar ao finalizar o projeto, a atividade de teste é transferida
para o cliente e que toda vez que o cliente executa o programa um teste é realizado.
Pressman apud Hetzel (1995, p. 830) diz que testes de caixa branca são “testes de
em pequeno porte” e testes de caixa preta são “teste de grande porte”.
Temos que ter em mente que o teste também pode falhar o fato de realizar
testes e não encontrar mais erros não quer dizer que o software está livre de
imperfeições, Pressman lembra que a única coisa que a atividade de teste não pode
fazer é mostrar a ausência de bugs, ele somente evidencia a existência de defeitos.
Bartié (2002) cita que temos testes que garantem a qualidade do processo e
testes que garantem a qualidade do produto. Os testes de verificação ou estáticos
analisam cada fase do desenvolvimento assim é possível definir a qualidade de cada
etapa do processo analisando o conjunto de documentos produzidos. Os testes de
verificação ou dinâmico consiste em aplicar sistematicamente testes durante os
diversos estágios de desenvolvimento, a verificação valida a estrutura interna e a
fidelidade aos requisitos estabelecidos.
Engholm Jr (2013) lembra que devemos nos prevenir e evitar que erros
ocorram, deve se abordado tanto os teste unitários, avaliando cada componente
isoladamente, ou com testes em conjunto onde é analisado a integração e o correto
funcionamento dos componentes desenvolvidos bem como as interfaces de
comunicação. Engholm Jr (2013, p. 281) diz que devemos elaborar um plano de
teste visando “identificar os métodos de verificação e validação, observando-se os
níveis de testes a serem executados, testes de integração e de desempenho, junto
com os testes de aceitação”.
Os testes são essenciais para garantia da qualidade de um software, quantas
vezes já não nos deparamos com um problema no dia a dia devido à falha de um
programa, seja no trabalho, na faculdade, na espera de um serviço público, se
pararmos para analisar muita gente já passou por situações de estresse devido a
alguma falha de um sistema. “Os Estados Unidos estimam que bugs de software
lhes custam aproximadamente 60 bilhões de dólares por ano” (ANICHE, 2014).
Tipos de Teste
Teste de Caixa Branca
É a técnica no qual o teste será baseado no código fonte do software, se
tratando de hardware cada nó de um circuito pode ser testado. Os componentes
internos são analisados com o intuito de encontrar possíveis falhas. Esse modelo de
teste exige um conhecimento técnico uma vez que a avalição será com base na
codificação e estrutura do software. Para definição do teste e suas métricas
em conta a complexidade, a estrutura e criticidade do software a ser testado.
Um exemplo seria definir uma função f(
programa, na sua especificação essa função não poderia aceitar valores negativos,
no teste seria inserido um valor negativo para descobrir se o tratamento de exceções
está funcionando conforme o esperado.
Teste de Caminho Básico
Método proposto por Thomas McCabe baseado na teoria de grafos. O teste
consiste em fazer com que o fluxo do programa passe por um número mínimo de
caminhos entre a entrada e a saída do programa, visa percorrer cada instrução do
programa ao menos uma vez
Para a representação do teste de caminho básico precisamos definir uma
notação para sua representação denominada grafo de fluxo (
grafo de fluxo representa a logica utilizada, na figura 3
ou mais instruções programada
Listagem 1 - Representação do có
/*1*/ import javax.swing.JOptionPane;
/*1*/ public class PotencialTeste {
codificação e estrutura do software. Para definição do teste e suas métricas
em conta a complexidade, a estrutura e criticidade do software a ser testado.
Um exemplo seria definir uma função f() qualquer em um determinado
programa, na sua especificação essa função não poderia aceitar valores negativos,
no teste seria inserido um valor negativo para descobrir se o tratamento de exceções
está funcionando conforme o esperado.
Método proposto por Thomas McCabe baseado na teoria de grafos. O teste
consiste em fazer com que o fluxo do programa passe por um número mínimo de
caminhos entre a entrada e a saída do programa, visa percorrer cada instrução do
programa ao menos uma vez.
Para a representação do teste de caminho básico precisamos definir uma
notação para sua representação denominada grafo de fluxo (PRESSMAN, 1995
a logica utilizada, na figura 3 cada circulo representa uma
rogramada ou de código fonte sem ramificação.
Figura 3 - Representação de Grafos
Fonte: PRESSMAN, 1995, p.795
Representação do código fonte de cálculo potencial
/*1*/ import javax.swing.JOptionPane;
PotencialTeste {
codificação e estrutura do software. Para definição do teste e suas métricas, leva-se
em conta a complexidade, a estrutura e criticidade do software a ser testado.
) qualquer em um determinado
programa, na sua especificação essa função não poderia aceitar valores negativos,
no teste seria inserido um valor negativo para descobrir se o tratamento de exceções
Método proposto por Thomas McCabe baseado na teoria de grafos. O teste
consiste em fazer com que o fluxo do programa passe por um número mínimo de
caminhos entre a entrada e a saída do programa, visa percorrer cada instrução do
Para a representação do teste de caminho básico precisamos definir uma
PRESSMAN, 1995). O
cada circulo representa uma
/*1*/ public static void main( String args[] )
/*1*/ {
/*1*/ String PrimeiroNumero,SegundoNumero;
/*1*/ float Base, Expoente,Resultado, Potencial;
/*1*/ PrimeiroNumero = JOptionPane.showInputDialog( "Entra com a
base:" );
/*1*/ SegundoNumero = JOptionPane.showInputDialog( "Entra com o
expoente:" );
/*1*/ Base = Integer.parseInt( PrimeiroNumero );
/*1*/ Expoente = Integer.parseInt( SegundoNumero );
/*1*/ if (Expoente < 0 ){
/*2*/ Potencial=0-Expoente;
/*3*/ }
/*3*/ else {
/*3*/ Potencial=Expoente;
/*4*/ }
/*4*/ Resultado=1;
/*4*/ while (Potencial !=0 ){
/*5*/ Resultado = Resultado * Base;
/*5*/ Potencial=Potencial-1;
/*5*/ }
/*6*/ if (Expoente<0 && Base !=0){
/*7*/ Resultado=1/Resultado;
/*8*/ }
/*8*/ else{
/*8*/ if(Base ==0){
/*9*/ JOptionPane.showMessageDialog( null, "A potencia é
um valor finito " );}
/*10*/ }
/*10*/ JOptionPane.showMessageDialog( null, "A potencia é " +
Resultado, "Resultado", JOptionPane.PLAIN_MESSAGE );
/*10*/ System.exit( 0 );
/*10*/ }
/*10*/ }
Fonte: DEVMEDIA Site: http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-
branca/15610
Figura 4 - Representação do grafo de fluxo da listagem 1
Fonte: DEVMEDIA4
4 Disponivel em: < http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-
branca/15610> Acesso em 12 mar. 2017.
Caminho independente de programa
São caminhos ao longo do código fonte que executa um novo comando e no
grafo de fluxo é uma nova área que não exercida anteriormente (PRESSMAN,
1995).
É possível calcular um valor para os atributos do software e de complexidade
ciclomática (V(G)) para o grafo de fluxo (BURNSTEIN, 2003).
V(G) é o calculo de complexidade referentea estruturação do código fonte, é o
número de caminhos independentes possíveis e o numero mínimo de caminhos que
pode ser testado, garantindo que o código não possua defeitos (MCCABE, 2010).
Conforme Pressman (1995) a V(G) são calculadas de três formas:
- Primeira forma - Pelos números de regiões do grafo de fluxo.
- Segunda forma - V(G)= E – N + 2.
Onde:
V(G) = e a complexidade ciclomática.
G = representa o grafo de fluxo.
E = representa a quantidade de arestas no grafo.
N = representa a quantidade de ramos no grafo.
- Terceira forma - V(G)= P + 1.
Onde:
V(G) = e a complexidade ciclomática.
G = representa o grafo de fluxo.
P = representa a quantidade de ramos predicativos.
Com os grafos de fluxo representados na Figura 4 serão exemplificados os
valores dos V(G) da seguinte formas:
1. Cinco regiões.
2. V(G) = 13 arestas – 10 ramos + 2 = 5.
3. V(G) = 4 ramos predicativos + 1 = 5.
Por estas formulas calculada chegamos que o grafo de fluxo usado tem cinco
caminhos diferentes para testar o código fonte por completo. Tais como:
- Caminho 1: 1-2-4-5-4-6-7-10.
- Caminho 2: 1-2-4-5-4-6-8-9-10.
- Caminho 3: 1-3-4-6-8-10.
- Caminho 4: 1-3-4-5-4-6-8-10.
- Caminho 5: 1-3-4-5-4-6-8-9-10.
Usando uma estrutura de dados é possível executar todos os caminhos
possíveisno grafo de fluxo de forma automática, para issoéusada uma estrutura de
dados. Usamos uma matriz quadrada onde seu tamanho é igual à quantidade de
ramos encontrados no grafo de fluxo, no qual cada uma das linhas e colunas da
matriz é correspondente às quantidades de ramos (PRESSMAN, 1995).
A Figura 5 representa a utilização da matriz de grafos para um grafo de fluxo
qualquer.
Figura 5 - Representação da matriz de grafos
Fonte: PRESSMAN, 1995, p. 875
Para exemplificar a utilização dos grafos, descreveremos a na figura 6 a
estrutura de controle de um programa e sua lógica.
Figura 6 - Estrutura de controle de um programa e sua lógica
Fonte: DEVMEDIA5
Teste de estrutura de controle
O teste de estrutura do de controle é um conjunto de testes lógicos que
servem como complemento ao teste de caminho básico levando em consideração as
condições lógicas do sistema, busca melhorar a qualidade do teste de caixa branca
(PRESSMAN, 1995).
Teste de condição
Estes tipos de teste busca encontrar erros nas condições booleana simples,
composta ou uma expressão relacional, onde o teste examina os lados positivos ou
falsos da condição booleana. Se uma condição estiver incorreta então é certo um
5Disponivel em: < http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-
branca/15610> Acesso em 12 mar. 2017.
dos componentes que a compões está incorreto. Segundo Pressman(1995), há
erros em uma condição das seguintes formas:
- Erros de operador booleano.
- Erros de variável booleana.
- Erros de parêntese booleano.
- Erros de operador relacional.
- Erros de expressão aritmética.
Teste de fluxo de dados
O teste de fluxo de dados percorre o programa de acordo com a localização
das definições e os usos das variáveis no programa. Esse teste busca verificar a
relação entre as instruções de acordo com as definições de usos de variáveis. Ao
percorrer determinas dos caminhos do código é possível verificar se todas as
atribuições de uma determinada variável estão funcionando (PRESSMAN, 1995).
Para demonstrar o fluxo de dados de cada comando do código fonte é
representada por números.
Categorias do fluxo de dados:
- Bloco básico ou ramos;
- Todos os usos;
- Todos usos computacionais (c-uso);
- Todos usos predicativos (p-uso);
- Caminho livre de def (Todos-du-Caminhos).
A figura 6 mostra como usar o teste de fluxo de dados no grafo de fluxo.
Figura 6 – Teste de fluxo de dados
Fonte: DEVMEDIA6
Teste de Caixa Preta
A nomenclatura se dá devido ao fato de se fazer necessário conhecer a
estrutura interna do software para se realizar o teste de caixa preta.
O teste de caixa preta visa testar as funcionalidades do software, testam-se
os requisitos funcionais. Para Pressman (1995), esse teste é uma complementação
do teste de caixa branca. Não devemos abordar o teste caixa preta como uma forma
de dispensar a aplicação de teste de caixa branca.
Pressman(1995) cita que os testes de caixa preta geralmente são aplicados
em um estágio mais avançado do desenvolvimento do programa, visando descobrir
erros tais como:
6Disponivel em: < http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-
branca/15610> Acesso em 12 mar. 2017.
- Funções incorretas ou ausentes;
- Erros de Interface;
- Erros nas estruturas de dados ou no acesso ao banco de dados externos;
- Erros de desempenho;
- Erros de inicialização de termino.
Particionamento de Equivalência
Esse teste cria classe de dados para testar as condições de inputs no
programa, o particionamento de equivalência procura definir o caso de teste que
descubra a classe de erro, cada classe deve testar ao menos uma das faixas de
opções dentre as possíveis. Segundo Pressman (1995, p. 817), “uma classe de
equivalência representa um conjunto de estados válidos ou inválidos para condições
de entrada”.
Como exemplo podemos citar um programa no qual as regras de cadastro de
usuários prevê que o usuário seja o e-mail da pessoa e que a senha tenha no
mínimo seis dígitos e seja alfanumérico. Para a situação exemplificada deveremos
ter ao menos três classes de equivalência uma atendendo a especificação de
usuário, outra atendendo a especificação da senha e uma terceira que não atenda
nenhuma das duas especificações, dessa forma exercitaria ao menos uma cada
entrada de dados tanto com dados válidos quanto com dados inválidos.
Teste de Sistema de Tempo Real
Os testes de sistema de tempo real consistem em testar cada tarefa
independentemente, levando em consideração os testes de caixa preta e de caixa
branca, buscando revelar erros de lógica e de função. Para complementar as tarefas
testadas, é preciso testar o comportamento do sistema de tempo real, levando em
consideração eventos externos como interrupções de usuários. Após isolarmos erros
de tarefas individuais e comportamentais observa-se as tarefas assíncronas ou
intertarefas, onde são analisadas as comunicações e o tempo gasto entre elas
(PRESSMAN, 1995).
Teste de Unidade
O teste de unidade se dá na menor parte de um programa, tendo essa seu
funcionamento independente das demais partes que compõe o software com um
todo. “Um teste de unidade não se preocupa com todo o sistema; ele está
interessado apenas em saber se uma pequena parte do sistema funciona” (ANICHE,
2014, p. 5). Se considerarmos um sistema orientado a objeto seria uma classe.
Teste Ponta a Ponta
São testes que buscam testar o software de uma forma mais ampla,
representando o contexto completo de uma interação do usuário ou caso de uso,
são baseados na regra de negócio, podem ser realizados manualmente ou
automatizados. (GOMES, 2013)
Esse teste geralmente é o teste final, quando a aplicação está por ser
liberada, são testes mais complexos e visam a garantir que a funcionalidade
desenvolvida está em ordem com o especificado.
Teste de Integração
Cada nova artefato criado deverá ser testado quando for adicionada aquilo
que já foi entregado, segundo Scharch (2009) deve-se avaliar se após a introdução
do novo artefato de código não causou nenhum prejuízo após ser integrado ao
código fonte.
Teste do Produto
Para Scharch (2009) o teste de produto acontece após o processo de
integração estiver completo, devendo assim haver um teste do produto como um
todo, quando os testes de produto tiverem sido completados, após os testes de
robustez onde sãoanalisados os picos de tensões como, por exemplo, um grande
número de acessos simultâneos ao sistema, teste de volumes onde é verificado a
upload de grandes arquivos, podemos partir para a etapa de teste de versão com a
disponibilização de releases alfa e beta para possíveis compradores a fim de obter
feedbacks observando se não há falhas individuais.
Teste de Desempenho
Esse teste visa verificar se o tempo de resposta do software está aceitável
conforme especificado no requisito de desempenho. Pressman (1995, p. 865)
lembra que o teste de desempenho pode ser realizado durante todo o processo de
criação do software podendo até mesmo ser aplicado em nível de unidades, “o
desempenho de um módulo individual pode ser avaliado quando são realizados os
testes de caixa branca”. Mas é quando o software está com todos os seus
elementos de sistemas integrados é que podemos verificar o desempenho real de
um sistema.
Teste de Stress
O teste de stress visa confrontar o sistema com situações anormais,
buscando ver até que ponto o software chegará sem falhas. Para Pressman (1995) o
analista ao executar esse teste tenta destruir o programa, causando-lhe ou
condicionando-o a situações extremas e severas, seja quantidade, frequência ou
volume anormais. Ele cita como exemplo o aumento do índice de entrada de dados
para ver como o software responderia com essa taxa aumentada de inputs.
3.1.16 Teste de Segurança
Para Pressman (1995), os motivos para um software ser invadido são
diversos, passando de hackers que tentam invadir um sistema por esporte;
empregado que desejam se vingar da empresa; indivíduos desonestos ou
criminosos que tentam obter alguma vantagem ilícita.
O teste de segurança busca minimizar a vulnerabilidade do software
verificando se todos os mecanismos de proteção estão funcionando corretamente. O
analista desempenha o papel de uma pessoa que deseja invadir o sistema, para
Pressman (1995) qualquer coisa vale, desde tentativa de adquirir senhas via
contatos externos, tentativas de burlar ou ultrapassar o mecanismo de defesa, até
mesmo tentativa derrubar o sistema deixando-o indisponível. Todo sistema pode ser
invadido, o papel do projetista é fazer com que o tempo e o custo de invasão não
vala a pena.
Ferramentas de Teste Automatizadas
Os prazos para entrega dos projetos estão cada vez mais apertados e muitas
vezes os gestores dos projetos não testam seus softwares devido ao seu
cronograma apertado, Pressman (1995) diz que frequentemente os testes são
responsáveis por 40% de todo esforço gasto em um projeto de desenvolvimento de
software. Devido ao grande esforço e falta de tempo começou-se a adotar
ferramentas de teste automatizadas, essa ferramenta são software capazes de
simular ações e computar resultados sobre teste que seriam feitos pelo recurso
humano.
Categoria de ferramentas de teste:
Analisadores estáticos. Esses sistemas de análise de programa suportam a “comprovação” de afirmações estáticas – afirmações fracas sobre a estrutura e o formato de um programa.
Auditores de código. Esses filtros de propósito especial são usados para verificar a qualidade do software, afim de garantir que ele atenda os padrões mínimos de codificação.
Processadores de asserção. Esse sistema pré-processadores/ pós-processadores são empregados para dizer se as afirmações fornecidas pelo programador, denominadas asserções, sobre o comportamento de um programa são de fato cumpridas durante as execuções reais do programa.
Geradores de arquivo de teste. Esses processadores geram, e preenchem com valores previamente determinados, arquivos de entrada típicos para programas que estão em teste.
Geradores de dados de teste. Esses sistemas de análise automatizados auxiliam o usuário a selecionar dados de teste que fazem um programa comporta-se de uma forma particular.
Verificadores de teste. Essas ferramentas medem a cobertura interna dos testes, frequentemente expressa em termos que estão relacionados à estrutura de controle do objeto de teste, relatam valor da cobertura ao especialista em garantia da qualidade.
Bancada de teste (Test Harnesses). Essa classe de ferramenta apoia o processamento de teste, tornando-o quase indolor, para (1) instalar um programa candidato num ambiente de teste; (2) alimenta-lo com dados de entrada; (3) com o uso de stubs o comportamento de módulos subsidiários (subordinados).
Comparadores de saída. Esta ferramenta torna possível a comparação de um conjunto de saídas de u programa com outro conjunto (previamente arquivado) para determinar diferenças entre eles. (PRESSMAN apud MILLER 1995, p. 827).
Pressman (1995) apostava que os teste automatizados seriam cada vez mais
utilizados e comuns, ele dizia que as gerações de testes automatizados
descendentes das primeiras gerações provocariam mudanças radicais na maneira
pela qual testamos softwares melhorando a confiabilidade.
“Testes automatizados são fundamentais para um desenvolvimento de
qualidade, e é obrigação de todo desenvolvedor escrevê-los. Sua existência traz
diversos benefícios para o software, como o aumento da qualidade e a diminuição
de bugs em produção.” (ANICHE, 2014, p. 16).
Test-Driven Development (TDD)
O conceito do Test-Driven Developmento ou TDD é bem simples, a ideia é
escrever o teste antes do código, é começar a implementação pelo teste. Ao
começar pelo teste a codificação tende a ficar mais simples e com maior qualidade.
O primeiro teste irá falhar, pois não há nada codificado ainda, com base na falha se
faz a implementação mais básica possível para resolver o problema, feito isso o
teste irá passar, por fim é só refatorar o código quando necessário.
O TDD ficou popular após a publicação do livro TDD: By Exemplo do Kent
Beck, em 2002, onde o assunto foi abordado e amplamente discutido. O TDD possui
um ciclo conhecido como verde-vermelho-refatora no qual a cor vermelha representa
o teste falhando, a cor verde representa o teste sendo aceito, por fim, refatoramos
para lapidarmos o código já implementado (ANICHE, 2014).
Figura 7 – Representação do Ciclo TDD
Fonte: ANICHE, 2014, p. 25
Algumas vantagens de se utilizar o método TDD no processo de
desenvolvimento de um software:
- Foco no teste e não na implementação. Ao começar pelo teste, o programador consegue pensar somente no que a classe deve fazer, e esquece por um momento da implementação. Isso o ajuda a pensar em melhores cenários de teste para a classe sob desenvolvimento. - Código nasce testado. Se o programador pratica o ciclo corretamente, isso então implica em que todo o código de produção escrito possui ao menos um teste de unidade verificando que ele funciona corretamente. - Simplicidade. Ao buscar pelo código mais simples constantemente, o desenvolvedor acaba por fugir de soluções complexas, comuns em todos os sistemas. O praticante de TDD escreve código que apenas resolve os problemas que estão representados por um teste de unidade. Quantas vezes o desenvolvedor não escreve código desnecessariamente complexo? - Melhor reflexão sobre o design da classe. No cenário tradicional, muitas vezes a falta de coesão ou o excesso de acoplamento é causadomuitas vezes pelo - Desenvolvedor que só pensa na implementação e acaba esquecendo como a classe vai funcionar perante o todo. Ao começar pelo teste, o desenvolvedor pensa sobre como sua classe deverá se comportar perante as outras classes do sistema. O teste atua como o primeiro cliente da classe que está sendo escrita. Nele, o desenvolvedor toma decisões como o nome da classe, os seusmétodos, parâmetros, tipos de retorno, e etc. No fim, todas elas são decisões de design e, quando o desenvolvedor consegue observar com atenção o código do teste, seu design de classes pode crescer muito em qualidade. (ANICHE, 2014, p.26)
O TDD melhora a qualidade do feedback, pois os feedbacks são recebidos
com uma frequência muito maior que na abordagem tradicional onde o teste ocorre
após a finalização de uma etapa do projeto (ANICHE, 2014). Na Figura xx vemos a
comparação entre a abordagem tradicional e o TDD.
Figura 8 – Comparação do time de feedbacks
Fonte: ANICHE, 2014, p. 27
Na engenharia de software não devemos usar as palavras “nunca” e
“sempre”, o mais usual é usarmos a palavra “depende”. Com o TDD não é diferente,
a ideia é usá-lo quando se há a necessidade de receber feedbacks constantes, o
difícil é definir quais são esses momentos.
Figura 9 – Pirâmide de Mike Cohn
Fonte: GOMES, 2013, p.69
A pirâmide de teste criada por Mike Cohn, Figura 9, defende diferentes tipos
de testes além de indicar proporções diferentes para cada tipo. Os teste de unidade
são menores, mais fáceis de serem implementados e mais rápidos de serem
aplicados, eles são a base da pirâmide e é o teste com maior aplicabilidade.
Os testes de integração/API, também são realizados na aplicação sem
interface de usuário, combinam diferentes componentes que trabalham em conjunto
que realizam uma determinada tarefa no sistema, eles são mais completos.
No topo da pirâmide temos os testes de ponta a ponta ou teste de aceitação,
são testes mais complexo e demandam mais esforço para serem implementados,
são mais caros, são mais lentos de serem executados, porem testam a aplicação
desde sua interface. (GOMES, 2013).
4 ANÁLISE DE CUSTO
O custo de manutenção dos softwares é um problema conhecido desde os
primórdios da programação, todo o retrabalho é visto como desperdício, e em se
tratando de construção de um software quanto mais avançado está o projeto maior é
o custo de sua manutenção.
Pressman (1995) compara o software a um “iceberg”, quando se espera que o
problema seja somente o ponto que se vê na superfície na verdade há uma grande
chance dos problemas e custos potenciais serem elevados devido ao que não
vemos sob a superfície. Pressman estimava que a manutenção do software pudesse
ultrapassar 70% de todo o esforço alocado no desenvolvimento de um software.
Historicamente o custo de manutenção de software cresceu com o passar dos
anos, para Pressman (1995) o custo aumentou significativamente entre os anos de
1970 e 1980 passando de um custo estimado em 35% para 60%. Esse era um fator
preocupante, pois se a engenharia de software não encontrasse uma forma de
diminuir o retrabalho os custos com manutenção ultrapassariam os 80% de todo o
esforço inviabilizando muitos projetos ou aumentando absurdamente seu custo.
Na década de 80, Berry Boehm publicou um livro onde era retratado todo o
custo exponencial da mudança em comparação com a fase do projeto, nesta
publicação ele mostrou que ao longo do tempo o custo de correções ou mudanças
sobe significativamente. Sua análise foi baseada nas fases de análise de requisitos
para arquitetura, design, codificação, testes e implantação. Em resumo um erro
corrigido na fase inicial do projeto, na definição dos requisitos, ele possuirá um custo
mínimo, quase insignificante. Mas se o mesmo erro é deixado para ser corrigido
após a conclusão do projeto o mesmo pode chegar a ter um custo 100 vezes maior
conforme podemos ver na figura 10.
Figura 10 - Gráfico de Boehm
Fonte: BOEHM, 1981, p.125
A figura 11 nos mostra a evolução dos custos de mudanças ao longo do
processo de construção de um software podendo na manutenção chegarmos a um
custo de manutenção 200 vezes maior que na faze de levantamento de requisitos, a
proporção pode variar de acordo com o tamanho do projeto, em geral projetos
maiores tendem a ter um custo de manutenção maior que projetos menores.
Figura 11 - Custo da Mudança do Escopo
Fonte: Site Projetos e TI 7
Mecconel (2004) diz que o ideal é encontrarmos o erro antes dele ser
implementado, essa fase se equipara ao levantamento de requisitos. Quanto maior
for o tempo em que o erro persistir no sistema, maior será a possibilidade dele
causar um dano futuro com um custo de correção mais elevado. Macconel (2004)
exemplificou a estimativa de custo com uma tabela e dados referente à mudança de
escopo de acordo com a fase similar a tabela 01.
Tabela 1 – Custo x Fase
Fonte: MACCONEL, 2004, p.7
7Disponível em: <http://projetoseti.com.br/monitoramento-e-controle-controlar-o-escopo> Acessado
em 15 jun. 2017
Fase de detecção
Fase de introdução Requisitos Arquitetura Construção Teste Conclusão
Requisitos 1 3 5-10 10 10-100
Arquitetura --- 1 10 15 25-100
Construção --- --- 1 10 10-25
Figura 12 - Evolução do custo de acordo com a fase
Fonte: MACCONNEL,2004, p.8
O sucesso de um projeto depende, dentre vários fatores, de uma
comunicação acertada, capaz de garantir que os departamentos envolvidos estejam
em consonância com todos os requisitos, parâmetros, notas, desvios e observações
consideradas.
O PMBOK (2014)fala que as fases do projeto é de acordo com a função de
sua natureza, pode variar de quatro a nove fases características.
Fase de iniciação: A fase inicial do projeto, quando uma determinada
necessidade é identificada, monitorada e transformada em um problema a ser
resolvido. O objetivo do projeto é definido, documentos confeccionados e estratégias
melhores selecionadas.
Fase de Planejamento: é a fase responsável por detalhar tudo aquilo que será
realizado pelo projeto, incluindo cronograma, interdependência entre atividades,
alocação de recursos, analise de custos. Nessa fase, os planos de escopo, custo,
qualidade, recursos humanos, comunicação, risco e aquisição são envolvidos.
Fase de Execução: é a fase que materializa tudo aquilo que foi planejado
anteriormente.
Grande parte do orçamento do esforço do projeto é consumindo nessa fase.
Fase de Monitoramento e Controle: É a fase que acontece paralelamente às
demais fases do projeto. Tem como objetivo acompanhar e controlar aquilo que está
sendo realizado pelo projeto. O objetivo do controle é comparar o status atual do
projeto com o status previsto pelo planejamento.
Fase de Encerramento: É a fase quando a execução dos trabalhos é avaliada
através de uma auditoria interna ou externa, os documentos do projeto são
encerrados e todas as falhas ocorridas são discutidas, conhecida também como fase
de aprendizado.
Principais motivos que levam a mudanças no escopo de serviço
Para verificar as dez práticas que mais influenciam os resultados levando em
consideração os custos Xavier (2013) fez uma pesquisa e obteve o seguinte
resultado:
1. O Aceite final foi formalizado.
2. Foi realizada uma reunião de partida (kick-off).
3. Os processos de aquisição dos itens críticos constaram da EAP /
Cronograma.
4. O gerente do projeto tinha conhecimento técnico acerca do escopo.
5. O nível de detalhamento das atividades do cronograma foi condizente com o
nível de controle requerido para o projeto.
6. Foi elaborado o Plano do projeto.
7. O método do nivelamento de recursos foi utilizado para o desenvolvimento do
cronograma
8. Foi utilizado um procedimento formal para solicitação, análise e aprovação ou
não das alterações do projeto.
9. O gerente do projeto propiciou a capacitação dos recursos humanos do
projeto para as atividades a eles alocadas.
10. A organização padronizou o software que devia ser utilizado para o
gerenciamento de Projetos.
5 CONCLUSÃO
Com base no referencial teórico apresentado, pudemos observar que a
maneira mais eficaz, independentemente da metodologia utilizada, ágil ou
tradicional, para se minimizar os custos de concepção de software é fazendo os
testes. A ideia de que testes possuem custo muito elevado “cai por terra” quando se
comparado ao custo do retrabalho em determinadas etapas do projeto, isso sem
levar em consideração que ao fazer uma atualização em determinada parte do
código pode-se vir a gerar erros em outra parte que estava funcionando
perfeitamente.
Com a adoção de novos métodos, novas tecnologias e até mesmo com a
mudança de cultura é possível se produzir mais, com mais qualidade e com redução
de custo. O TDD apresenta uma metodologia no qual todo artefato gerado, toda
nova classe ou atributo, já saem testadas da etapa de desenvolvimento e garante
que se caso um erro seja encontrado o mesmo será corrigido nas primeiras etapas
do desenvolvimento.
Conforme se argumenta nesta revisão bibliográfica, os autores demonstram
que a utilização dos métodos ágeis apresentam importantes ganhos na
implementação de produtos de software. No entanto, uma das premissas do texto
apresentado no manifesto conforme se verifica no capitulo 2, que a recomendação é
ser menos burocrático no processo de construção.
A parte de testes de softwares por si só já é burocrática e apresenta uma
série de técnicas e processos, e poderíamos entender esta execução de etapas
como perda dos ganhos que a metodologia ágil nos dá. Em contrapartida,
analisando a questão dos custos, identificamos que efetivamente termos uma etapa
de teste que permeia todas as etapas da construção do produto de software pode
economizar recursos financeiros consideráveis além de garantir certa qualidade ao
produto de software implementado.
Contudo, não devemos nos preocupar em testar somente devido aos custos
de retrabalho, a qualidade do software também é um ponto relevante, conforme se
apresentou neste trabalho, falhas graves em projetos de software já ocasionaram
prejuízos milionários e até mesmo custaram vidas.
O ideal é fazer o certo de primeira, mas no vivemos em uma utopia, sendo
assim devemos agregar as boas práticas mesclando o que há de melhor em cada
metodologia, implantando a cultura de teste no ambiente de desenvolvimento, dessa
forma conseguiremos alcançar o mínimo de erro e evitar problemas para quem
conta com o software operando em perfeitas condições.
Finalizando esta conclusão entendemos que como as metodologias ágeis
auxiliam bastante no ganho de produtividade da produção do software e a etapa de
testes garante a qualidade e evita retrabalho gerando custos muito altos, a sugestão
é mesclar as duas técnicas para se alcançar um objetivo maior que é a satisfação
dos clientes.
REFERÊNCIAS
ANICHE, Maurício. Test-Driven Development: Teste e Design no mundo real. São Paulo: Casa do Código, 2014.
BARTIE, Alexandre. Garantia de Qualidade de Software. 5. ed. Rio de Janeiro: Campus, 2002.
BOEHM, Barry W. Software Engineering Economics. NY: Prentice Hall, 1981.
BURNSTEIN, I. Practical Software Testing: a process-oriented approach. New York: Springer, 2003.
DEVMEDIA. Uma visão da técnica de teste de caixa branca. Disponível em <http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-branca/15610> Acessado em: 12 mar. 2017.
ENGHOLM Jr, Helio. Engenharia de Software na Pratica. São Paulo: Novatec, 2013.
FREITAS, Carlos A..40 + 16 Ferramentas e Técnicas de Gerenciamento. 6. ed.RJ: Brasport Livros e Multmidia
GOMES,André Faria. Agile, Desenvolvimento de software com entregas frequentes e foco no valor do negócio. São Paulo: Casa do Código, 2013.
KNIBERG, Henrik. Extreme Programming. Dispon[ivel em: <http://www.crisp.se/henrik.kniberg> Acessado em 17 mar. 2017.
MCCABE, T. Glossary of Terms. Disponível em <http://www.mccabe.com/iq_research_iqgloss.htm >. Acesso em: 14 abr. 2017.
MCCONNELL, Steve. Code Complete. 2. ed. Washington: Microsoft Press, 2004.
PROJETOS E TI. Monitoramento e Controle: Controlar O Escopo. Disponivel em: http://formatacaoabnt.blogspot.com.br/2011/10/referencias.html Acessado em: 15 jun. 2017.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos – Guia PMBOK®. 3. ed.Curitiba: Editora Project Management, 2004.
PRESSMAN, Roger S. Engenharia de Software. 3. ed. São Paulo: Pearson Education do Brasil, 1995.
SABBAGH, Rafael. Scrum - Gestao Agil Para Projetos De Sucesso. Sao Paulo: casa do Código, 2013.
SCHACH, Stephen R. Engenharia de Software: Os Paradigma Clássicos Orientação a Objetos. 7. ed. Porto Alegre: AMGH Editora Ltda, 2009.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Education do Brasil, 2013.
TELES, Vinícius M.. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec, 2006.
VIANA, Leonardo. M; DESCHAMPS, Alexandro. XP – Extreme Programming. Disponível em:<http://www.apicesoft.com/commom/articles/Apice> Acessado em: 16 abr. 2017.
XAVIER, Carlos Magno. Práticas de Sucesso no Gerenciamento de Projetos. Disponível em: <http://pmkb.com.br/artigo/praticas-de-sucesso-no-gerenciamento-de-projetos/> Acesso em: 21 jun. 2017.
Top Related