Verificação, validação e teste de software ágil

769 visualizações

Publicada em

Este trabalho apresenta uma breve introdução ao tema Verificação, Validação e Teste de Software Ágil e traz um estudo de caso onde pode-se verificar que a utilização de técnicas de teste de software, tais como o TDD, podem diminuir drasticamente a ocorrência de erros no software.

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
769
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
30
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Verificação, validação e teste de software ágil

  1. 1. Verificação, Validação e Teste de Software Ágil Gilberto Gampert1 1 Instituto de Ciências Exatas e Geociências – Universidade de Passo Fundo (UPF) Campus Universitário – Bairro São José – Passo Fundo – RS – Brasil gampert@upf.br Abstract. This paper presents a brief introduction to the topic Verification, Validation and Agile Software Testing and brings a case study where can be seen that the use of software testing techniques, such as TDD, can dramatically decrease the occurrence of software errors. Resumo. Este trabalho apresenta uma breve introdução ao tema Verificação, Validação e Teste de Software Ágil e traz um estudo de caso onde pode-se verificar que a utilização de técnicas de teste de software, tais como o TDD, podem diminuir drasticamente a ocorrência de erros no software. 1. Introdução Conforme [Pressman 2011], a estratégia de teste de software descreve: os passos que devem ser executados como parte do teste, quando estes passos devem ser planejados e executados e quanto trabalho, tempo e recursos serão necessários. Desta forma, uma estratégia de teste é composta por: planejamento dos testes, casos de testes, coleta e avaliação dos dados obtidos. A estratégia é normalmente desenvolvida pelos especialistas em testes. Ela é importante pelo fato de que os testes muitas vezes requerem mais trabalho do que as outras etapas da engenharia de software. Se for feito sem atenção, perde-se tempo e erros passam desapercebidos. Os testes iniciam por um pequeno componente ou grupo de componentes, que são testados para verificar erros nos dados e na lógica. Após esta etapa, os componentes são integrados e neste ponto testes são executados para descobrir erros ao atender os requisitos do cliente. Conforme os erros são descobertos, devem ser diagnosticados e corrigidos (depuração). Um modelo de teste de software deve ter as seguintes características básicas:  Proceder revisões técnicas eficazes;  Iniciar no nível de componente e evoluir para a integração do sistema;  Ter uma técnica de teste definida. Diferentes técnicas de teste são apropriadas a diferentes abordagens da engenharia de software;  O teste é executado pelo desenvolvedor e (em grandes projetos) por uma equipe de testes;  A depuração é uma atividade distinta do teste, porém deve estar associada com a estratégia de testes.
  2. 2. 2. Verificação e Validação O teste de software faz parte de um tópico mais amplo, conhecido como verificação e validação (V & V). A verificação diz respeito ao conjunto de tarefas que asseguram que o software implementa uma funcionalidade específica. Já a validação por sua vez, diz respeito ao conjunto de tarefas que asseguram que o software foi criado e atende aos requisitos do cliente. Uma outra visão é abordada por [Pressman 2011]: Verificação: “ Estamos criando o produto corretamente? ” Validação: “ Estamos criando o produto certo? ” A verificação e a validação abrangem diversas atividades de SQA (software quality assurance, garantia da qualidade de software):  Revisões técnicas;  Auditorias de qualidade e configuração;  Monitoramento de desempenho;  Simulação;  Estudo de viabilidade;  Revisão de documentação;  Revisão de base de dados;  Análise de algoritmo;  Teste de desenvolvimento;  Teste de usabilidade;  Teste de qualificação;  Teste de aceitação;  Teste de instalação. Ou seja, embora o teste tenha um papel muito importante em V&V, muitas outras atividades são necessárias. Isto significa que o teste sozinho não garante a existência de qualidade, e sim atesta a sua ausência. 3. Estratégia de Teste de Software O desenvolvedor é responsável pelo teste dos componentes do programa, certificando-se que cada um executa a função ou comportamento para qual foi projetado. Em alguns casos, ele também faz o teste de integração, o que implica na construção e teste do software completo. Somente após esta etapa é que a equipe de testes faz a sua parte. A equipe de teste, ou ITG (independent test group, grupo independente de teste), tem por função resolver o problema de deixar o criador testar aquilo que ele mesmo criou. O desenvolvedor e o ITG trabalham juntos durante todo o projeto para garantir que testes completos sejam realizados. O ITG se envolve durante a análise e o projeto e continua envolvido durante o projeto inteiro.
  3. 3. Uma estratégia de teste de software pode ser vista na Figura 1, onde o teste de unidade inicia no centro da espiral e trata de cada componente do software conforme for implementado. O teste segue o sentido do exterior da espiral, abordando o projeto e a arquitetura do software (teste de integração). Seguindo no mesmo sentido, há o teste de validação, onde os requisitos são validados em relação ao software criado. Por fim, o teste do sistema, onde o software é testado como um todo. Figura 1. Estratégia de teste 3.1. Teste de unidade O teste de unidade coloca os esforços na menor unidade do software, o componente ou módulo de software. Utilizando a especificação do componente como guia, este teste enfoca a lógica interna de processamento e as estruturas de dados, buscando descobrir erros dentro dos limites do componente. Ele pode ser executado em paralelo para diversos tipos de componentes. O teste de unidade é ilustrado na Figura 2. Figura 2. Teste de unidade Os seguintes aspectos são testados:  A interface do módulo, para assegurar a comunicação com os demais componentes;  A estrutura de dados locais, para garantir a integridade dos dados;
  4. 4.  Os caminhos independentes da estrutura de controle, para garantir que todas as instruções tenham sido executadas pelo menos uma vez;  As condições de limite, para garantir que o componente opere adequadamente nas fronteiras de processamento;  E por fim, são testados os caminhos de manipulação de erro. Casos de testes deverão ser projetados para descobrir erros de computação, comparações ou fluxo de controle incorretos. 3.2. Teste de integração O teste de integração é uma técnica utilizada para conduzir testes para descobrir erros associados com as interfaces. Normalmente é aplicada uma estratégia de integração incremental, pois os erros são mais fáceis de isolar e corrigir. Uma estratégia oposta, integrando todos os módulos ao mesmo tempo, poderá levar ao caos, pois muitos erros são encontrados simultaneamente e o seu isolamento é dificultado. Existem várias abordagens de teste de integração. Nos parágrafos a seguir abordaremos as principais. Integração descendente: ou top-down, os módulos são integrados de cima para baixo na hierarquia de controle, começando com o programa principal e incorporando os módulos subordinados a seguir. Na Figura 3 podemos ver os dois tipos de integração existentes: integração primeiro-em-profundidade e primeiro-em-largura. No caso da integração primeiro-em-profundidade, os componentes M1, M2 e M5 seriam integrados primeiro, depois M8 e por fim M6. E depois continuaria para os outros ramos. No caso da integração primeiro-em-largura, primeiro M1, depois M2, M3 e M4, e assim sucessivamente. Figura 3. Integração descendente O módulo principal se torna o controlador e os módulos diretamente subordinados são substituídos por pseudocontroladores. Um a um estes pseudocontroladores vão sendo substituídos pelos componentes reais, os testes são executados neste componente e assim o processo se repete até atingir todos os componentes.
  5. 5. Integração ascendente: ou bottom-up, começa os testes com módulos atômicos, ou seja, nos níveis mais baixos na estrutura do programa. Neste caso, somente um pseudocontrolador é necessário. Os componentes são agrupados em agregados (Figura 4) que executam uma subfunção específica do software, então um pseudocontrolador coordena as entradas e saídas do caso de teste. O agregado é testado, e então o pseudocontrolador é removido, os agregados são combinados e move-se para cima na estrutura do programa. Figura 4. Integração ascendente Teste de regressão: Sempre que um novo módulo é adicionado no processo de integração o software muda. Novos fluxos de dados são estabelecidos, novas entradas e saídas e nova lógica de controle pode ser adicionada. O teste de regressão nada mais é do que executar novamente um conjunto de testes que foram executados anteriormente para garantir que as alterações não tenham inserido efeitos indesejados ou erros adicionais. Pode ser executado através de ferramentas que automatizam a captura/execução e permitem comparação subsequente. 3.3. Teste de validação O teste de validação tem seu início quando o teste de integração chega ao fim, e os componentes já estão devidamente testados. Neste ponto o software está completamente integrado e os possíveis erros de interface corrigidos. Este teste concentra-se em ações e saídas visíveis ao usuário. Existem várias definições de validação, pode-se dizer que a validação teve sucesso quando o software funciona de acordo com o esperado pelo cliente. Esta expectativa, normalmente está descrita na especificação de requisitos de software. A validação do software é obtida através de um conjunto de testes que demonstram a conformidade com os requisitos. Um plano de teste descreve as classes de teste e um procedimento de deste define os testes específicos necessários para garantir que todos os requisitos funcionais sejam satisfeitos, que todos os requisitos de desempenho sejam atendidos, que a documentação correta e outros requisitos sejam cumpridos (compatibilidade, recuperação de erro, manutenibilidade, etc.). Outro
  6. 6. elemento importante é a revisão da configuração de software. Sua finalidade é garantir que seus elementos tenham sido catalogados e tenham os detalhes necessários para apoiar as atividades de suporte. É praticamente impossível prever como cada cliente realmente usará um programa, e, se o software for desenvolvido para muitos clientes, é impraticável executar testes formais de aceitação para cada cliente. Neste caso utiliza-se um processo de teste chamado teste alfa e beta, com o objetivo de descobrir erros que somente o usuário final é capaz de encontrar. Teste alfa: é conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. O teste acontece com os desenvolvedores acompanhando e registrando os erros e problemas de uso. É um ambiente controlado. Teste beta: é conduzido nas instalações dos usuários finais. Normalmente o desenvolvedor não está presente e o ambiente não é controlado. O cliente registra os erros e problemas encontrados e relata para o desenvolvedor. 3.4. Teste de sistema Ao término do desenvolvimento, o software é agregado a outros elementos do sistema, por exemplo, hardware, pessoas e informações. Desta forma, é necessária a execução de uma série de testes de integração de sistema e validação. Estes testes não fazem parte do processo de software. Teste de sistema é uma série de testes cuja finalidade é exercitar todo o sistema e verificar de este se integra adequadamente e executa as funções a ele alocadas. A seguir veremos os tipos de teste de sistema. Teste de recuperação: é um teste que força o sistema a falhar de várias formas e verifica se a recuperação é executada adequadamente. A recuperação pode ser automática, e neste caso é avaliada a capacidade de recuperação de dados, ou, requerer a interação humana, e o tempo médio de reparo será avaliado. Teste de segurança: verifica se os mecanismos de segurança implementados no software irão protege-lo de acesso indevido. Teste por esforço: verifica até onde pode-se forçar o sistema até que ele falhe, ou seja, busca-se quebrar o programa. Ele estressa o sistema de maneira que este demande recurso em quantidade, frequência e volume anormais. Teste de desempenho: é projetado para testar o desempenho em tempo de execução. Apesar de poder ser feito em todas as etapas de teste, o verdadeiro teste de desempenho somente poderá ser avaliado depois da integração total de todos os elementos. Normalmente uma ferramenta é utilizada para automatizar este tipo de teste e coletar os resultados obtidos. Teste de disponibilização: ou teste de configuração, tem por objetivo validar o software em cada ambiente no qual ele dever operar. Examina os procedimentos de instalação e documentação para fornecer o software aos usuários finais.
  7. 7. 4. Teste de Software Ágil O teste de software ágil é caracterizado por ocorrer em todas as etapas do ciclo de vida de desenvolvimento de software e ser desempenhado por todos os membros do time. Ele ocorre em ciclos contínuos e através de mecanismos automatizados. Todo o time é responsável pelos testes, e cada membro contribui executando testes sob a sua perspectiva. Assim, os testes são executados de forma colaborativa e complementar. Os desenvolvedores atuam na perspectiva do código, enquanto que os clientes avaliam a perspectiva da funcionalidade. Há também o papel do testador, que complementa os testes dos dois anteriores e colabora com abordagens mais especializadas. Em teste ágil, a automação tem grande enfoque, pois viabiliza curtos ciclos de entrega e faz parte de um ciclo de integração contínua, fornecendo resultados de forma contínua. A automação libera o time para executar tarefas mais criativas ao invés de executar testes entediantes, repetitivos e manuais. A Figura 5 mostra que o foco principal do teste ágil são os testes unitários e de integração. O uso desta abordagem diminui o custo e a manutenção, pois os erros são encontrados mais cedo e aumenta a velocidade de entrega, pois não há o retorno para correção. Figura 5. Pirâmide do teste ágil 4.1. Test-Driven Development (TDD) Este trabalho não se destina a descrever o método TDD, pois existe suficiente material para o aprendizado e não faz parte do escopo. Esta técnica busca automatizar a busca por resultados especificados antes da construção do software. Cada teste é uma especificação que mapeia um resultado esperado para uma parte específica do software. Isso ocorre dentro de um ambiente onde os testes já produzidos podem ser facilmente executados (automação). Na Figura 6 pode- se verificar o funcionamento do processo de teste do TDD.
  8. 8. Figura 6. TDD O autor [Crispin 2006], nos descreve suas experiências com TDD: "Eu posso afirmar por experiência pessoal que TDD produz código que tem ordens de magnitude menos erros de unidade, muito menos erros funcionais, e uma probabilidade de atendimento das expectativas do cliente exponencialmente mais alta, quando comparado com técnicas de programação convencionais.". 5. Estudo de Caso Os autores do estudo de caso abordado neste artigo [Silva et. al, 2010] escolheram o projeto OOOD (OpenOffice.org Daemon). Este projeto foi desenvolvido inicialmente pela Nexedi, uma empresa Francesa associada ao NSI (Núcleo de Pesquisa em Sistema de Informação). O objetivo do OOOD é extrair/inserir metadados em um documento e converter e exportar documentos para o OpenOffice.org. Ele foi escolhido por utilizar TDD desde o início de seu desenvolvimento. Inicialmente o time não tinha experiência no uso do TDD, então durante o processo aconteceu o aprendizado. Um outro projeto desenvolvido pelo NSI, a Biblioteca Digital (BD), foi selecionado como grupo de controle e portanto não apresentou o uso do TDD. O objetivo do BD é manter dados sobre obras literárias, gráficas e vídeos. 5.1. Metodologia O objetivo da metodologia proposta é demonstrar estabilidade durante o processo de desenvolvimento e a diminuição gradativa dos erros causados pelo aumento da complexidade e mudança de requisitos. Quer-se demonstrar a diminuição dos erros e aumento das melhorias, durante o desenvolvimento, proporcionados pelo monitoramento contínuo obtido através de testes automatizados. Estima-se que quanto maior a cobertura dos testes oferecidos pelo TDD, mais seguro o desenvolvedor estará para trabalhar no incremento, melhoria e correções necessários. Os autores optaram por utilizar o controle de versões como recurso de monitoramento no desenvolvimento do software, para acompanhar a taxa de mudanças submetidas pelo time. Cada incremento, alteração ou correção, passa primeiro por este sistema e depois é incorporado ao software. A partir das mudanças submetidas ao controle de versões, foi feita uma verificação nas descrições para detectar palavras que sugeriam o tipo da modificação. Buscou-se identificar três situações: novas funcionalidades, melhoria do código e correção de erros.
  9. 9. A expectativa é de que as adições de novas funcionalidades indiquem a estabilidade do código e as operações de melhoria do código possam indicar evolução na qualidade do mesmo. Já as operações de correções, indicam que a execução atingiu um caminho não coberto pelos testes, denotando instabilidade no produto. Após recuperar as informações do controle de versões, atribuiu-se um valor positivo (1), para as novas funcionalidades denotando estabilidade. Para as situações de melhoria de código, atribuiu-se um valor neutro (0), indicando a estabilidade. Para as situações de erro atribuiu-se (-2), demonstrando instabilidade. Foi escolhido o valor (-2) para intensificar o efeito visual dos erros nos gráficos. 5.2. Resultados Na Figura 7, pode-se observar que o desenvolvimento do projeto OOOD foi dividido em 3 fases:  Fase A: criação da arquitetura da solução, os primeiros testes ainda não haviam encontrado erros;  Fase B: os erros começam a aparecer, o que significou aprendizado para o time. Foram encontrados 18 erros, representando 45% do total de erros;  Fase C: houve uma certa estabilidade, com poucas declividades (erros). Figura 7. Evolução do projeto OOOD É fácil concluir que a dispersão dos erros encontrados na terceira etapa (22) foi menos densa do que os erros ocorridos na segunda etapa. Atribui-se esta distância entre os erros ao TDD, pois com o uso desta técnica e o aperfeiçoamento do time, existe a tendência de que ocorram cada vez menos erros. Além da quantidade de erros ter diminuído, pode-se observar que as operações de refatoração (melhoria de código) foram constantes (Figura 8). Isto somente poderia acontecer em um ambiente estável, onde o time se sentisse confiante.
  10. 10. Figura 8. Avaliação das atividades do projeto OOOD No projeto BD, onde não foi usada a técnica de TDD, podemos observar um comportamento distinto. Como podemos ver na Figura 9, este projeto esteve constantemente sujeito a propagação de erros, tornando o desenvolvimento menos estável e diminuindo as chances de melhoria. Figura 9. Evolução do projeto BD Na Figura 10 é possível verificar um número menor de melhorias e maior de erros: Acompanhe a evolução das fases:  Fase A: início do desenvolvimento, houveram incrementos de funcionalidades, porém com muitos erros e correções (vários declives);  Fase B: ocorreu grande evolução e esteve um pouco mais estável, mas também ocorreu grande número de erros;  Fase C: foi caracterizada por melhorias de código e correção de erros.
  11. 11. Figura 10. Avaliação das atividades do Projeto BD 6. Considerações Finais O objetivo deste artigo foi fazer uma introdução ao assunto Verificação, Validação e Teste de Software Ágil e apresentar um estudo de caso, tendo em vista a importância do software e a necessidade de melhor gerenciar a sua produção. O estudo de caso selecionado, a partir dos projetos escolhidos pelos autores e dos dados que foram coletados, concluiu que a aplicação do TDD e de testes automatizados refletem positivamente na qualidade de software, permitindo identificar os erros rapidamente e trazendo controle ao processo de desenvolvimento. Observou-se inicialmente que houve pouca estabilidade, e depois com o aprendizado e a evolução do uso chegou-se a um momento de maior estabilidade no desenvolvimento. Deixamos como contribuição a constatação de que a técnica utilizada para identificar novas funcionalidades, melhoria de código e correção de erros precisa ser aprimorada e ancorada em informações mais consistentes do que aquelas obtidas do sistema de controle de versões. Referencias Crispin, K. (2006). Driving Software Quality: How Test-Driven Development Impacts Software Quality. IEEE Software. IEEE. P.70-71. 2006. Pressman, R. S. (2011). Engenharia de Software: Uma Abordagem Profissional. Mc Graw Hill. 7ª ed. 2011. Silva, F. L. C., Monnerat, G. M., Carvalho, R. A. (2010). “Automação na Produção de Software”, http://www.abepro.org.br/biblioteca/enegep2010_TN_STO_113_745_16894.pdf, Junho.

×