(4 votes, average: 10,00 out of 10)
Loading ...No dia 25 de Março de 2010, o Centro Universitário UNA de Belo Horizonte, junto ao professor Gustavo Nunes, me cederam a oportunidade de palestrar sobre um assunto muito complexo da área de teste de software: As possíveis técnicas e suas aplicações durante o ciclo de desenvolvimento.
Em primeiro lugar eu gostaria de registrar aqui meus profundos agradecimentos aos alunos da UNA, que tiveram paciência, atenção e respeito pelos slides apresentados, agradecer ao Ricardo Antunes e a Squadra Tecnologia que me permitiram mostrar alguns dos nossos cases de Automação de Testes com ferramentas IBM Rational como Rational Functional Tester, Rational Test Manager, Rational Performance Tester e Rational Clear Quest, agradecer ao professor e amigo Gustavo Núnes pela indicação e a UNA pela recepção e oportunidade.
Agradeço também aos meus colegas : Amanda Magalhães, Elias Nogueira, Fabíola Lara, Ricardo Antunes e Vanessa Vaz que inspecionaram o material e me ajudaram a melhorar a qualidade para a apresentação.
A Palestra foi realizada no campus Raja Gabaglia da UNA e teve duração de 1 hora e trinta minutos aproximados. Foi abordada uma breve introdução sobre o como o defeito é visto em organizações maduras, como o ciclo de vida de desenvolvimento software evoluiu ao longo dos anos para conter esses defeitos, sobre como algumas iniciativas das mais diversificadas vem trabalhando no Brasil e no mundo para conter esse tipo de problema.
Foram então abordadas diversas técnicas como inspeção de artefatos baseado em checklists e base histórica, especificação de casos de teste baseados em casos de uso, valores limites, partição ou classe de equivalência, automação de testes funcionais e suas vantagens/desvantagens, importancia e abordagens de testes de aceite e a relação dos requisitos não funcionais com o teste de software, com a qualidade do produto e com a expectativa do cliente.
Segue abaixo o slide usado compartilhado via SlideShare:
Comentários sobre os Slides:
Inicialmente tivemos uma breve descrição sobre a história do termo bug e sua aplicação “confusa”, cedendo nos dias de hoje a definição Defeito, por ser mais ampla e imparcial do ponto de vista de autor. Também sobre os estudos de Boehm e Wheeler, relacionados ao custo e distribuição dos defeitos nas fases de um processo de desenvolvimento. Um pouco mais sobre esse assunto pode ser lido no post “Bug is dead“.
Ainda na introdução tivemos uma breve descrição dos ciclos de vida, a evolução deles durante as últimas quatro décadas, os efeitos que os defeitos podem causar quando se propagam de uma fase para outra e como os diferentes modelos de engenharia de software vem tratando esse tipo de problema de forma cada vez mais preventiva.
Então suergiu uma dúvida. O que tem sido feito para resolver os problemas dos defeitos?
Falamos sobre algumas iniciativas no Brasil e no mundo, dentre elas orgãos certificadores, modelos de maturidade, regulamentações, melhores práticas entre várias outras. E no meio disso tudo, as técnicas de teste de software.
Falamos sobre uma técnica, que embora não esteja diretamente vinculada ao teste de software, atua com o objetivo de reduzir o número de defeitos. As inspeções. Detalhamos um pouco sobre o uso de checklists e sobre os diferentes níveis de formalidade e de configuração das equipes em inspeções, revisões e validações.
Falamos e demonstramos com um vídeo o desenvolvimento de um conjunto de testes de unidade para validar os aspectos de uma classe Java usando o framework JUnit, sobre as entradas e os resultados que temos ao implementar essa técnica e sobre alguns mitos relacionados ao teste de unidade.
Mais detalhes sobre esse assunto pode ser visto no post “Uma Introdução a TDD com JUnit“.
Falamos um pouco sobre o modelo de um caso de teste genêrico implementado no TestLink e sobre algumas observações que tornam nossos casos de teste mais eficazes ao serem planejados e especificados. Um breve comentário sobre a ferramenta TestLink usada para gerar os casos de teste. Para saber mais sobre o TestLink podem ser consultados alguns posts com a Tag “TestLink“.
Entendemos então, que um caso de teste pode ser gerado sistematicamente a partir de um caso de uso, separando seus fluxos e alinhando suas regras e possíveis validações.
Mais detalhes sobre essa técnicas podem ser vistos no post “Um Modelo para Elaboração de Cenários e Casos de Teste”
Verificamos também, uma forma de criar casos de teste baseados em interválos matemáticos conhecido como “Análise de valores limites”.
Ainda verificamos que existe outra técnica, baseada em conjuntos e que pode ser representada por algebra relacional, no qual sempre temos pelo menos um item de cada conjunto, chamada “Partição ou Classe de Equivalência”:
Falamos sobre a aplicação dos casos de teste em dois tipos diferentes de execução e gerênciamento. O manual e o automatizado, as vantagens e desvantagens de cada um, os mitos sobre automação (recomendado slide: Automação de Testes Funcionais: Mitos e Verdades do Elias Nogueira) e alguns videos exemplos sobre automação com Rational Functional Tester e sua integração com o Rational Test Manager.
Comentamos sobre os objetivos dos testes de aceite, sua abstração com relação a detalhes de software e sua importância para demonstrar valor para o cliente. usamos alguns exemplos de modelos para essa abordagem como o uso de procedimentos passo a passo e o uso dos protótipos com instruções. Citamos também o uso de “história em quadrinhos” quando o software faz parte de um sistema maior e reforçamos que a abordagem dos testes de aceite deve ser a que traga maior conforto e confiança para o cliente.
Caso algum cliente tenha um perfil que permita chegar mais próximo do chão (usando nossa metáfora da abstração), os artefatos menos abstratos podem ser usados para complementar os testes de aceite.
Comentamos sobre as caracteristicas de qualidade da ISO9126 e mais especificamente sobre os testes não funcionais de carga, estresse e maturidade:
Então surge a primeira dúvida. . . Para testar uma aplicação ou para ter um processo que controle a qualidade dos projetos e produtos desenvolvidos na minha empresa eu tenho que usar isso tudo?
E descobrimos que não. O modelo “V” ou qualquer outro modelo adotado pela organização, pode usar e deixar de usar qualquer técnica de teste, assim como inspeções ou documentos de acordo com a sua maturidade.
E a segunda dúvida: Nossa. . . mas as técnicas de teste de software são só essas?
E descobrimos que existem muitas e muitas outras técnicas que são criadas ou descobertas todos os dias, e que aparecem de acordo com a maturidade da organização.
Tivemos um ótimo exemplo sobre o quanto, mesmo com inspeção, nossos artefatos ainda podem ter problemas ou defeitos (bugs).
Mesmo inspecionado por 5 excelentes profissionais, o meu slide ainda tinha dois erros (já corrigidos para essa versão).
Fica aqui novamente meu agradecimento aos meus colegas Amanda Magalhães, Elias Nogueira, Fabíola Lara, Ricardo Antunes e Vanessa Vaz.
E claro, meu agradecimento ao Centro Universitário UNA e ao professor Gustavo Nunes, que me cederam a oportunidade de palestrar no evento anual de Sistemas de Informação, à plateia que teve muita paciência, atenção e respeito e ao Ricardo Antunes e a Squadra Tecnologia, por permitirem exibir alguns dos nossos videos demonstrando algumas das nossas experiências com automação de testes funcionais com Rational Functional Tester e Rational Test Manager.
Além dos slides e do nosso bate papo, tivemos a exibição de alguns videos de cases de automação de testes, demonstrando a gravação dos scripts, o desenvolvimento e refinamento dos scripts, o planejamento da execução e a execução automatizada a partir de um único ponto.
Infelizmente, não pude passar os videos para a internet, mas vou explicar um pouco da arquitetura usada para a criação desse tipo de automação.
Arquitetura da integração Rational Test Manager e Rational Functional Tester:
Inicialmente existe a preparação do ambiente. Todas as máquinas que serão usadas para a execução dos testes automatizados precisão ter instalados e configurados o IBM Rational Funcional Tester, os browsers e / ou aplicações que serão usadas em todos os sctipts, ferramentas de apoios que serão usadas (office, svn, cvs, etc) e um cliente do IBM Rational Test Manager, que realiza a comunicação entre as duas ferramentas. O servidor de testes (como é chamado no exemplo visual acima) deve conter o IBM Rational Test Manager instalado e configurado para reconhecer todos os clientes espalhados pelas diversas máquinas que serão usadas para execução dos testes funcionais.
Depois que gravamos ou desenvolvemos os scripts no IBM Rational Functional Tester, deixamos o controle de versão e configuração atuar sobre todas as máquinas, carregando o mesmo script para todas elas, e através do Rational Test Mananger criamos um plano onde especificamos os usuários, os dados, as máquinas e os procedimentos de teste que serão executados e em que momentos eles devem ser executados.
Quando iniciamos a execução, os scripts são ativados de acordo com o planejamento e os “robôs” trabalham simulando um conjunto de usuários.
Nos nossos exemplos demonstramos cenários com 12 e 30 usuários, simulando acesso interno (intranet) e externo (inclusive fisicamente), simulando clientes solicitando produtos via internet e telefone e operadores verificando estoque, efetuando retiradas, verificando documentos e consultando informações.
Esse tipo de automação exige um alto conhecimento e sincronia da equipe e muita maturidade do sistema em desenvolvimento, sendo recomendado principalmente para sistemas legados que sofram modificações em regras de negócios.
Para mais informações sobre as ferramentas descritas acima acessar:
IBM Rational Test Manager: http://www-01.ibm.com/software/awdtools/test/manager/
IBM Rational Functional Tester:http://www-01.ibm.com/software/awdtools/tester/functional/index.html
IBM Rational Quality Manager: http://www-01.ibm.com/software/rational/offerings/quality/
Outras soluções IBM: http://www.ibm.com/br/pt/
Bibliografia:
•Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1.
•BOEHM, B.W., 1981, Software Engineering Economics, Prentice Hall.
•WHEELER, D.A., BRYKEZYNSKI, B., MEESON, R.N., 1996, Software Inspections: An Industry Best Practice, IEEE Computer Society.
• PRESSMAN, R.S., 2001, Software Engineering: A Practitioner´s Approach, Fifth Edition, McGraw Hill.
•[ISO9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality
•ISQTQB Glossário de termos usados no Teste de Software Versão 1.0
• Foundation Level ISTQB Syllabus, ISTQB
•PÁDUA FILHO (2003), Wilson. Engenharia de Software – Fundamentos, Métodos e Padrões. 3ª Edição. LTC Editora, 2009.
•RIOS, E., MOREIRA, T., SOUZA, A., CRISTALLI, R . Base de Conhecimento em Teste de Software 2ª Edição. Martins, 2007.
•IEEE Std 829-2008.
•Kirner, T. G., Davis, A. M. (1996) “Nonfunctional Requirements of Real-Time Systems; Advances in Computers”, vol. 42
•Cysneiros, L. M., Leite, J.C.S.P (2004) “A Framework for Integrating Non-Functional Requirements into Conceptual Models”, IEEE
transactions on software engineering, Vol. 30, No. 5.
•CBT-TST110, Principles of Test Automatization for GUI Testing. IBM.
ERRATA:
Slide 22:
“Identificação dos cenários de teste” > “Identificação dos casos de teste”
Previous 
Next ?>
Loading ...
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire
Uma verdadeira aula sobre Teste de Software!
Parabéns Camilo!
[...] Comentários sobre a palestra “Técnicas de Teste” na UNA – Camilo Ribeiro (The Bug Bang Theory); [...]
Ola,
super interessante.gostei muito. abraço
Muito bom o post Camilo! Parabéns!!
Só acredito que haja um errinho no slide 22: No item 5 ao invés de “Identificação dos cenários de Teste” não seria “Identificação dos casos de Teste”? Abraço.
Boa noite Douglas,
Bem vindo ao BugBang e obrigado pelo Elogio.
Realmente sobrou um erro. Anunciei ele na errata no final do post.
Muito obrigado pela colaboração
Abraços.
Uma coisa me chamou muita atenção nos seus slides. Você acredita que o custo para o conserto de um erro cresce exponencialmente conforme a fase onde ele foi encontrado? Você cita BOEHM, 81. É um documento com quase 30 anos. Você acredita que ele ainda é válido hoje em dia? E mais, este custo é o mesmo independente do tipo do software sendo produzido?
Bom dia Anderson,
Muito obrigado pela visita!
Eu acredito sim. Apesar de o estudo ser bem antigo (mais de cinco anos em computação é quase pré história), de 81 para cá a complexidade dos softwares e a exposição das empresas cresceu exponencialmente também, ficando “elas por elas”.
Por exemplo, em 81, software poderiam causar prejuízos para várias organizações, por falhas em processamentos de dados, por defeitos em equipamentos eletrônicos gerenciados por sistemas operacionais de software ou outros motivos.
Hoje, uma falha em produção para um Banco pode significar milhões de reais/dólares desviados, mas pior que isso, hoje, com o número de usuários na internet, uma falha dessa proporção pode colocar em risco a todo o grupo do banco. Ou por exemplo, uma falha em um sistema embarcado em um carro pode causar um recall em milhares de automóveis, o que também causaria uma perda de imagem para a fabricante (Você compraria um carro com falhas nos software?).
Mas também tem um material de uma consultoria chamada LKP Consulting Group, que se chama “The Real Cost of Software Defects” que é mais recente (2003) onde diz “De acordo com o CTO de uma organização de desenvolvimento de software, um errohttp://www.bugbang.com.br/wp-admin/edit-comments.php#comments-form que custa R $ 1 a correção dos custos da área de trabalho do programador $ 100 para corrigir uma vez que é incorporado a um programa completo, e muitos milhares de dólares se identificou depois que o software foi implantado em produção”.
É um slide simples, mas tem as referências de pesquisas sobre esse tema entre 1981 e 2003. Não acredito que tenha mudado muito até os dias de hoje pelos motivos citados acima.
Para ver o slide: http://www.lkpgroup.com/Cost%20of%20Software%20Defects.pdf
Importante ressaltar, que dizemos que o custo de um defeito “pode ser” da ordem de “1000X” por exemplo. Esses valores são estimativas.
Espero ter ajudado.
Abraços.