The Bug Bang Theory

Ontem, dia 19 de maio de 2010, realizei minha terceira palestra em universidades, convidado pelo Centro Universitário de Belo Horizonte (UNI-BH).

Em primeiro lugar, gostaria de agradecer a UNI-BH e toda sua administração pelo convite, aos alunos pela paciência e atenção durante toda a palestra, ao meu amigo Junior Braga pela indicação e ao professor Tarcizo José pela ajuda, orientação e apoio durante todo o evento. Agradecimentos também a Fabíola Lara, Marlon Lima e Vanessa Vaz (colegas de trabalho) pela revisão, ao Ricardo Antunes por alguns slides e as nossas “fontes inesgotáveis” de conhecimento como a UFMG e a DFTestes, de onde boa parte do material foi baseado ou estudado.

Gostaria de elogiar a UNI-BH pela iniciativa e pela organização, diversidade e pontualidade do evento, meus parabéns!
O evento contou com outros profissionais e acadêmicos do setor de computação, sistemas e engenharias, como Marcio Sete da Challenge, Leonardo Martins e Charles Fortes da Paiva Piovesan, Gibran Silva da Localiza entre vários outros talentos de Belo Horizonte e região.

O tema da minha palestra foi “Introdução a Automação de Teste de Software”, mas claro que, por envolver alunos de todos os períodos e vários cursos (inclusive fora de TI como Engenharias), a palestra não pôde ser totalmente técnica, e abordamos boa parte do planejamento, elaboração e analise de testes funcionais e não funcionais, que não fazem parte unicamente das atividades de automatização.

Abaixo o Slide:

Introdução a Automação de Teste de Software

View more presentations from Camilo Ribeiro.

Abaixo um passo a passo explicando um pouco do que foi comentado durante a palestra (slide a slide):

Inicialmente conversamos um pouco sobre o motivo central da existência de qualquer departamento de qualidade e teste de software, até mesmo dos processos de desenvolvimento. Consideramos a filosofia de que existem diversos tipos diferentes de defeitos, assim como planejamento quando o cronograma não foi realista, análise quando um requisito não é corretamente detalhado no diagrama de atividades, de software quando uma falha é identificada etc. Discutimos sobre o custo que isso pode representar a um projeto e sobre os momentos em que podemos identificar esses defeitos, considerando alguns estudos como o de Boehm sobre o custo dos defeitos e o de Wheeler sobre a distribuição dos defeitos ao longo do projeto de desenvolvimento de software. Mais conteúdo sobre esses temas pode ser encontrado nos posts “Comentários sobre a Semana de Sistemas de Informação 2010 da PUC” e no “Bug is Dead“.

Falamos então, sobre existirem diferentes “técnicas” para aumentar a qualidade de um produto de software. Que nenhuma delas é por si só a verdade absoluta, mas que um conjunto delas, aplicadas nos momentos mais adequados podem aumentar a confiabilidade de que o produto está funcionando adequadamente. Usando a analogia das joaninhas acima (Ladybug em inglês, por isso são representadas como “bugs”, sentido figurado genérico na área de computação para problemas em softwares), podemos considerar que essas diversas técnicas são diferentes inseticidas, e que cada um deles tem maior eficácia contra cada um dos “bugs” que podem existir no processo de desenvolvimento de produtos de software.

Quando o assunto é automação de teste de software, o que estamos fazendo, basicamente, é automatizar a aplicação desse inseticida, ou seja, automatizando o processo de teste de software que tem efeitos principalmente em dois tipos de defeitos: Defeitos de Software e Defeitos de Arquitetura (veremos a frente alguns pontos que justificam essa afirmação). Como o nosso foco será nesse inseticida em especial, discutimos os conceitos e sua evolução de 1979 até os dias de hoje. Com isso eliminamos do escopo de estudo, outras aplicações, como inspeções, revisão estatica de código, etc. Para saber mais sobre os diversos mecanismos que um profissional de teste de software ou qualquer outra pessoa que vise melhorar o produto pode usar, recomendo a leitura do material gratuito do ISTQB, mantido e revisado em português pelo BSTQB que pode ser baixado da seguinte página: http://www.bstqb.org.br/?q=node/12

Falamos bastante sobre os “três fundamentos” ou pilares do teste de software que representam o nosso “GPS”. Conceitos importantes de aliar para entender melhor o escopo da automação em cada nível, as ferramentas e técnicas usadas para cada tipo de teste e os conhecimentos exigidos para cada técnica. Ressaltamos um pouco o conceito definido de caixa branca, preta e cinza, lembrando que a caixa branca ou transparente (também chamada de caixa de vidro por alguns autores, inclusive Glenford Myers, divulgador do conceito) está diretamente relacionada a estrutura do produto, seu código fonte, sua arquitetura e seus recursos em geral, enquanto o teste de caixa preta está relacionado aos seus requisitos, as necessidades que o produto visa solucionar e os testes de caixa cinza são intermédios entre as duas principais técnicas. Um exemplo interessante de teste de caixa cinza pode ser testar com acesso ao banco de dados, mas isso varia de autor para autor.

Como muito bem descrito na palestra “Automação de Testes, Mitos e Verdades” do Elias Nogueira, especialmente no slide 7 (Falsas Expectativas), muitas pessoas acreditam, por diferentes motivos, que automatizar o teste de software vai resolver todos os problemas. Infelizmente, automatização de testes não é a cura do câncer dos nossos projetos de software, primeiramente porque antes de automatizar testes, temos que ter bons testes especificados. Em um artigo da IBM chamado “Traceability from Use Cases to Test Cases” que foi citado em um treinamento/conferência há dois anos atrás, foi apresentada uma estrutura como a descrita abaixo que eu aproveitei por ser muito didática. Nela é apresentado um modelo ainda simples, pois não considera a rastreabilidade entre diferentes necessidades, funcionais e não funcionais, ou seja, testar é uma atividade extremamente analítica, complexa e desafiadora!

Detalhamos também os níveis de teste, explicando o modelo em V que há muitos anos vem sendo usado, e, apesar de não ser o melhor modelo para aplicação de teste de software hoje, continua sendo muito didático e ainda bastante próximo da realidade dos nossos processos de desenvolvimento de software. Chegamos a conclusão também, que momentos diferentes tem objetivos diferentes, consequentemente, planejamento e elaboração próprios, assim como robôs ou modelos de automação diferentes, que serão propostos e explicados mais adiante.

Automatizando Teste de Unidade:

Falamos sobre o conceito de teste de unidade e sobre os diversos itens que podem ser a nossa unidade. Para facilitar o entendimento, definimos a nossa unidade como uma classe, nossa linguagem de programação como Java e nosso framework de desenvolvimento de testes de unidade como o JUnit. Então falamos sobre a relação de cada classe, com seus diversos caminhos ou galhos (ver The Art of Software Tesging, 1979 de Glenform Myers para mais detalhes) que podem ser validados de diversas formas por testes desenvolvidos em qualquer momento, depois da classe, durante a criação da classe ou antes da criação da classe. Comentamos sobre esse último caso em especial, sobre a existência de uma regra chamada “Code the Unit Test First” do XP, que também foi comentado por mim no post “Uma introdução a TDD com JUnit“.

Automatizando Teste de Integração:

Comentamos sobre o escopo de validar a integração entre as unidades (normalmente já testadas). Basicamente, podemos imaginar que com dados validos entrando e sempre retornando valores ou resultados válidos, o que pode ser avaliado com o conjunto de testes de unidade, mas, ainda assim, podem existir defeitos entre esses valores que não foram identificados anteriormente. Nesse ponto é que o teste de integração atua, conferindo a conformidade com os requisitos e tentando identificar problemas na integração entre as unidades do sistema. Testando a comunicação (troca de informação) entre os vários contratos das unidades. Vimos também os três principais modelos descritos no terceiro slide, e recomendei o uso do modelo Bottom up para aplicação de testes de integração de funcionalidade e do modelo top down em testes de integração de desempenho/carga.

Automatizando Teste de Sistema:

Comentamos sobre os testes de sistema serem os primeiros a ser desenhados e usados nas organizações quando começam a ter mais maturidade, obviamente, assim também acontece com a automatização dos testes. Também falamos que é aqui que o Analista de Teste e o Testador atuam com mais frequencia e intensidade, elaborando casos de teste em nível de caso de uso e validando a maior parte dos requisitos do software. Relembramos os comentários feitos no slide “Testar é  muito mais que automatizar” sobre a forma de desenvolver casos de teste baseados em casos de uso e cenários de teste. Para entender um pouco mais sobre o assunto, leia “Um modelo para elaboração de cenários e casos de teste“.

Importante comentar sobre os slides abaixo. As figuras são unicamente ilustrativas e de certa forma até cômicas, mas não quero que você leitor, tenha uma interpretação de que programadores produzem “lixo” nem que sem uma ferramenta de automação o código fica com qualidade inferior. O que quero demonstrar é que quando temos ferramentas de apoio ao nosso processo, podemos melhorar a qualidade de vida e de trabalho de todos os envolvidos no processo de desenvolvimento de software. Nos slides abaixo, quero passar a mensagem que, uma vez que exista um processo definido e aplicado, esse processo por si só, ajuda a melhorar a qualidade do software, mas muitas vezes ele se torna repetitivo, cansativo e pouco desafiador, abaixando a motivação dos envolvidos. Esse cenário é agravado em empresas do seguimento de produtos, pois os colaboradores normalmente podem ficar anos com os mesmos sistemas. Com ferramentas de apoio como as de automatização de testes funcionais, podemos tornar essas atividades mais desafiadoras, eficazes e gerenciáveis, permitindo mais tempo para os desenvolvedores e testadores evoluírem outros aspectos da organização.

Comentamos também sobre a estrutura de teste de sistema usada na maioria das ferramentas de automação de testes, onde desenvolvemos ou gravamos e refinamos vários scripts, e em seguida planejamos uma execução ordenada desses scripts, inclusive selecionando dados específicos de um repositório qualquer.

Automatizando Teste de Aceite:

Entendemos o conceito de teste de aceite, e verificamos que esses testes, normalmente, são do cliente. E o objetivo deles não é nem encontrar defeitos, nem garantir que o software não tenha defeitos, mas sim avaliar o software e ter certeza que esse atende aos requisitos esperados, por isso, esses são testes muito pessoais. Chegamos então a conclusão, que muitas vezes não é interessante ter esses testes automatizados, pois na maioria quase que absoluta dos casos, perderia o valor agregado para o cliente.

Porem, vimos também que existem requisitos não funcionais, que são inviáveis de testar sem a ajuda de ferramentas sofisticadas, assim como os testes de carga e outros relacionados ao desempenho do sistema. Apresentei um exemplo de sumário de informações que podemos coletar nesses testes, para tentar identificar o principal problema no sistema, arquitetura ou ambiente da aplicação, assim como foi demonstrado que um sistema na internet pode ser afetado por inúmeras variáveis, como quantidade de acessos, recursos disponíveis e algoritmos aplicados.

Exemplifiquei com a apresentação de um vídeo contendo a execução de um caso real de automação e expliquei a plataforma utilizada, que também foi explicada no post Comentários sobre a palestra “Técnicas de Teste” na UNA, e pelo mesmo motivo não posso publicá-los na internet .

Comentei brevemente sobre a arquitetura dos testes automatizados na plataforma de reuso Praxis, que estudo atualmente na UFMG. Todo o trabalho desenvolvido pode ser baixado através da minha página do Departamento de Ciência da Computação da UFMG http://homepages.dcc.ufmg.br/~camilo ou também através do sítio do professor e criador do praxis, o Prof. Dr. Wilson de Pádua http://homepages.dcc.ufmg.br/~wilson.

Os testes no praxis são realizados de uma forma extremamente automática, e com uma arquitetura tão bem definida, que depois de criar todo o arcabolço do teste, a criação dos casos de teste passa a ser feita através de linhas simples, com vírgulas separando os dados que serão utilizados. Ou seja, os testes podem mudar que você não precisa mudar uma linha de código fonte, apenas os valores de entrada e saída. É claro que um conjunto de conhecimentos e muita prática são necessários para criar e manter os testes antes desse nível de automatização, mas vale ressaltar, que o praxis é um modelo de desenvolvimento de software para fins acadêmicos, logo não são muito reproduzíveis em fábricas e projetos de software. Apesar do praxis ser muito criticado (principalmente por ignorância e pré julgamento), eu acredito que seja o melhor modelo de engenharia de software para se ensinar e aprender (minha opinião). Para saber mais sobre o praxis pode adquirir o livro “Engenharia de Software: fundamentos, métodos e padrões – terceira edição” do Wilson de Pádua.

Assim encerramos, com agradecimentos já citados no início dessa publicação, mas, agradecer a quem nos apóia e nos escuta nunca é demais, por isso agradeço novamente a UNI-BH e aos meus colegas revisores

Novamente, muito obrigado pela presença e paciência ao assistir a palestrar e visitar a minha página. Sinto muito não ter reservado alguns minutos a mais para eventuais dúvidas, mas gostaria de ressaltar que estou sempre disponível para quaisquer dúvidas aqui no blog ou por e-mail camilo [at] camiloribeiro [dot] com

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 Standards Board, “IEEE Standard for Software Unit Testing: An American National Standard, ANSI/IEEE Std 1008-1987″ in IEEE Standards: Software Engineering, Volume Two
•IEEE Std 829-2008.
•IEEE Std 610
• Hetzel, Bill, The Complete Guide to Software Testing, 1993, Ed.2
•CBT-TST110, Computer Based Training TST110 Principals of Software Testing for Testers;
•IEEE729-1983
•NOGUEIRA, Elias. Automação de Teste – Mitos e Verdades, 4° Encontro Mensal ALATS, http://www.slideshare.net/elias.nogueira, 2009
• IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries; IEEE; New York, NY.; 1990
•MERCI2010, Praxis 3.0 – Wilson de Pádua. http://homepages.dcc.ufmg.br/~wilson/praxis/ 2010
•ZIELCZYNSKI, Peter, Traceability from Use Cases to Test Cases,  http://www.ibm.com/developerworks/rational/library/04/r-3217/ IBM Rational Technical library, 2006

Test Driven Development; Estimativas de Testes de Software; e Testes de Unidade com o Visual Studio 2005 são os temas dos minicursos da V Semana de Sistemas de Informação, que acontecerá nos dias 15, 16 e 17 de abril, na quinta e na sexta, das 19h às 22h30 e no sábado das 9h30 às 13h. O tema da Semana deste ano é Testes de Software.

Essa foi a chamada da V Semana de Sistemas de Informação, um dos eventos mais importantes da área na PUC Minas (Pontifícia Universidade Católica de Minas Gerais), evento organizado pelo Professor, Pesquisador e Mestre em Ciência da Computação Marcelo Werneck, que contou com a presença de grandes profissionais de várias empresas e universidades de Minas Gerais.

Eu fui convidado para o dia de abertura do evento com o tema “Carreira”, onde falei sobre os papéis de hoje e de amanhã em teste e qualidade de software, abordando a pesquisa que venho realizando para um artigo que tem previsão de publicação aqui no BugBang.com.br ainda no mês de abril.

A grade do evento foi bem completa. No primeiro dia foram apresentadas as palestras de abertura do evento com o prof. Marcelo Werneck apresentando a palestra “Perspectivas de Teste de Software”, expondo para os alunos sobre a área de teste de software, conceitos, mitos, história, técnicas, princípios entre outras informações. Em seguida, palestra “Teste de Software: Papéis e oportunidades” com Camilo Ribeiro, apresentando os principais papéis de hoje e de amanhã, o perfil do profissional de testes, formas de atualização, oportunidades para o futuro e sobre os mitos que cercam o nosso mercado de teste de software. Ainda no primeiro dia foram apresentados os mini cursos de “Programação Java dirigida por testes (Eclipse – JUnit – EclEmma)” com o instrutor Márcio Adriano.

Nos demais dias foram apresentadas palestras e mini cursos como “Ferramentas Borland para Teste de Software” com o Lucas Conde, arquiteto de testes da Borland, “Testes de Software com o Visual Studio 2010″ com Kleber, aluno do Mestrado em Informática da Pontifícia Universidade Católica de Minas Gerais, “Automação de Testes de Software” do Juliano Santos, Sócio / Diretor da Base2 Tecnologia, “Teste de Software” com o Gilberto Barbosa Mota da Itambé e professor do Curso de Sistemas de Informação da PUC MINAS, entre outras apresentações de convidados de peso da área em Minas Gerais.

Abaixo o slide apresentado na minha palestra:

Papéis em Teste e Qualidade de SoftwareView more presentations from Camilo Ribeiro.

O slide está bem simples, para ser complementado futuramente com o post sobre os onze principais papéis relacionados a teste de software, por isso, peço que aguardem a publicação do post (ainda em abril) para eventuais críticas e comentários.

Fotos:

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:

Técnicas de Teste

View more presentations from Camilo Ribeiro.

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”