The Bug Bang Theory

(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:

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”

(No Ratings Yet)

 Loading ...

O 3º Seminário Brasileiro de Teste de Software será um dos muitos eventos programados para 2010 e o principal evento da ALATS (Associação Latino-Americana de Teste de Software).

O evento deve contar com vários autores e profissionais de destaque do nosso mercado como Emerson Rios, Ricardo Cristalli e Elias Nogueira, além de duas presenças internacionais, Ruud Teunissen e Martin Pol.

Martin Pol é coautor do livro Software Testing : A Guide to the Tmap Approach, um dos clássicos da literatura especializada de teste de software e do livro Test Process Improvement : A Practical Step-by-Step Guide to Structured Testing. Consultor com mais de 27 anos de experiência com teste de software, CEO da Polteq International Testing Services B.V, um dos desenvolvedores do método TMap, o primeiro a receber o premio “European Testing Excellence Award“ e palestrante renomado nas Américas e em vários países da Europa e Ásia e na Austrália. Esteve no Brasil pela ALATS ministrando as palestras The evolution of Testing e Test Outsourcing nesse ano pelo BRATESTE 2009

Ruud Teunissen Consultor Internacional da Polteq International Testing Services B.V com mais de 20 anos de experiência em teste de software, coautor do livro Software Testing : A Guide to the Tmap Approach, palestrante e entusiasta de teste de software e um dos desenvolvedores do método TMap.

A ALATS abre mais um BRATESTE que promete a mesma qualidade e variedade que tivemos nas duas primeiras edições, com participações de peso e tema central em Processos de Teste.

Informações sobre o evento, valores e grade podem ser encontradas no portal da ALATS.

Bons testes

(No Ratings Yet)

 Loading ...

O Simpósio Brasileiro de Qualidade de Software (SBQS)  é um evento anual da Comissão Especial de Engenharia de Software da Sociedade Brasileira de Computação (SBC) e do Comitê do Programa Brasileiro da Qualidade e Produtividade em Software (PBQP-SW) . O evento tem como objetivo reunir pesquisadores, profissionais, empresários, professores e estudantes de diversas áreas, interessados em questões relativas à qualidade de software. O Simpósio também favorece o intercâmbio de informações entre pesquisadores nacionais e estrangeiros de renome, e entre indústria e usuários, sobre o estado atual e tendências, em termos de métodos, técnicas, ferramentas de software e experiências práticas da área de Qualidade de Software.

Em 2010, o IX SBQS será realizado pela primeira vez na Região Norte, coordenado pela UFPA – Universidade Federal do Pará e pela UFAM – Universidade Federal do Amazonas. O evento ocorrerá em Belém, Estado do Pará, no Centro de Convenções da Amazônia – HANGAR. Com uma área total de 63.000 metros quadrados e 24.000 de área construída totalmente integrada ao ambiente amazônico, o Hangar é equipado com recursos de alta tecnologia e preparado para receber grandes eventos, como feiras, congressos, convenções, encontros, seminários, simpósios e exposições. A programação do SBQS’2010 conta com:

• Apresentação de palestrantes convidados
• Apresentação dos trabalhos selecionados – artigos técnicos e relatos de experiência e Concurso de Teses e Dissertações em Qualidade de Software (CTDQS)
• Um painel sobre Qualidade de Software na Indústria
• Encontro da Qualidade e Produtividade em Software (EQPS)
• Cinco workshops satélites: VII Workshop de Teses e Dissertações em Qualidade de Software (WTDQS), V Workshop Olhar Sociotécnico sobre a Engenharia de Software (WOSES), VI Workshop de Manutenção de Software Moderna (WMSWM), III Workshop de Desenvolvimento Rápido de Aplicações (WDRA) e o II Workshop de Gerenciamento de Projetos de Software (WGPS).
• Sete mini-cursos.

Mais informações: http://www.ufpa.br/sbqs2010/

(No Ratings Yet)

 Loading ...

A 2ª edição da Conferência trará um panorama atual da Qualidade de Software no Brasil, com relatos de empresas que obtiveram excelentes resultados na implantação de programas de melhorias de processos e suas perspectivas para os próximos anos.

Data:  11 e 12 de Novembro de 2009
Horário:  das 8:30 às 18:00h
Local: Universidade São Judas Tadeu (Unidade Mooca)
Rua Taquari, 546 – Auditório do Térreo
São Paulo – SP.

Venha participar das palestras e debater com especialistas da Engenharia e Qualidade de Software assuntos que podem  interessar diretamente à sua empresa.

Agenda Provisória:

11 de novembro (quarta-feira)
- Cerimônia de Abertura
- Ações e atividades do MCT, Resultados e Planos para o futuro do mercado de TI
- MPS.BR – Resultados e Perspectivas
- Programas de melhorias de processo em empresas de TIC
- Implementação integrada CMMI nível 3 e MPS.BR nível C
- Utilizando metodologias ágeis em uma empresa CMMI nível 5
- A importância do fator humano na definição e manutenção de processos

12 de novembro (quinta-feira)
- Estimativas de Software
- TMMI – Test Maturity Model Integration
- Qualidade Arquitetural em aplicações em Java
- Implementação de melhores práticas de ITIL em grupos de empresas
- CMMI v1.3 e CMMI for Services
- Compatibilidade entre metodologias ágeis e CMMI/MPS.BR
- Controle Estatístico de Processos de desenvolvimento de software

Investimento*:
- Participação nos 2 dias: R$ 180,00 por pessoa
- Participação somente em 1 dia: R$ 110,00 por pessoa

Descontos para 2 ou mais inscrições da mesma empresa
- Participação nos 2 dias: R$ 160,00 por pessoa
- Participação somente em 1 dia: R$ 90,00 por pessoa
*valores válidos somente para inscrições realizadas até 23/10/2009.

Inscrições e Informações:
comunicados@asrconsultoria.com.br
(11) 2629-0610
www.asrconsultoria.com.br