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:

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”

O novo theme instalado Inanis é compatível com o despadronizado Internet Explorer, tem um melhor aproveitamento do espaço para texto e possui recursos mais simples para navegação.

Como a maioria dos analistas de teste sabem, quando testamos um sistema que ficará disponível para o publico, a preocupação com o browser deve ser levada em consideração. O antigo tema que eu estava usando apresentava muitos problemas de incompatibilidade com as versões 6 e 7 do navegador Internet Explorer. Tentei resolver de diversas maneiras, mas tive que recorrer a um novo theme.

Esse novo theme possui alguns recursos que facilitam a navegação:

•About this Post:
Sempre que entramos em um post, o blog apresenta um resumo a direita, informando nome do post, data de criação, Autor, Número de comentários, categorias e opções de respoder ao post, ler os comentários e seguir o RSS.

•Rodapé do Post:

Existem as informações sobre criação, autor, tags e categorias a que o . Também tem as ações de enviar por e-mail e ver o link. Ainda no rodapé, podemos ir para o próximo ou para o anterior com um click. Mais abaixo vem o campo para comentários e com ele um icone do RSS para esse post.

•Menu de tarefas
O menu no canto inferior esquerdo, semelhante ao menu iniciar do Windows 7, carrega quatro opções para melhorar e facilitar a vida dos usuários do blog.

->Guia de categorias, com todas as categorias em um menu;
->Nuvem de tags, semelhante a principal, mas aqui somente as tags aparecem;
->RSS do Blog, para assinar o nosso Feed;
->RSS dos comentários do blog, para saber o que os nossos visitantes comentam;
->Menu dos últimos 50 posts;
->Pesquisa rápida;

Além disso, existe um recurso para o mudar de tema, onde podemos mudar o fundo do blog para ficar mais a vontade.

•Mais espaço para o conteúdo
O espaço reservado ao texto do post também aumentou muito, cerca de 30%, o que permite maior facilidade para ler e publicar imagens maiores . Se usar a opção de tela cheia (normalmente ativada pelo F11) o blog fica ainda mais confortavel

Também foram adicionados novos widgets que vão ajudar os leitores a interagir comigo enquanto lêem algum dos artigos.

->O chat onde os leitores podem tirar dúvidas sobre algum post;
->A pesquisa de opinião onde os leitores podem me ajudar a definir o que pesquisar;

Além disso, o novo visual do blog é mais moderno, futurista e sofisticado, mais rápido e mais intuitivo. Funciona da mesma forma em todos os principais browsers do mercado, em todos os que apareceram no meu analytics e combina mais com o nome do blog.

Aceito sugestões e críticas sobre o novo layout e possíveis mudanças.

Bons testes