The Bug Bang Theory

(3 votes, average: 10,00 out of 10)

 Loading ...

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:

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

(No Ratings Yet)

 Loading ...

Recentemente, em uma das listas de discussão em que participo, vi uma coisa que eu jurava que não acontecia mais. Em pleno século XXI, era do conhecimento e o que é mais agravante, em uma área de pessoas entusiastas por métricas precisas que somos nós, cientistas da computação, usando anos de experiência para julgar o famoso “salary label” :

Júnior, Pleno e Sênior

Eu acredito fortemente que o mercado não julga anos de experiência como único fator de decisão para um determinado cargo e salário. O mais engraçado é que muitas das pessoas não tem a mínima noção quanto ao que deve ser chamado um analista júnior, pleno ou sênior, e ao ser questionadas sempre se dizem Seniores com 3~4 anos de experiência.

Outra coisa que vem aparecendo com muita força nas listas de teste de software é a certificação. Muita gente acha que o simples fato de ter uma certificação vai mudar sua posição no mercado. Com esse pensamento, aquele estagiário com 6 meses de experiência como testador, se mata de estudar e consegue uma certificação. Agora ele passa a ser pleno (ou sênior). Logo passa a ser um profissional “promíscuo” na busca por mais e mais dinheiro fora de hora.

As nossas certificações estão um pouco “fracas”, mas isso é tema já muito discutido, como no post “Certificações Valem a Pena?” do Fabrício Ferrari, no post “Certificação, um Mal Necessário” do Edwagney Luz e em tantos outros posts e discussões nas nossas listas e foruns. O que quero dizer é que a certificação, ainda mais as low level, não são por si só, caracterizadoras da qualidade do profissional. O simples fato de tirar uma certificação esperando um aumento salarial, só pela certificação, é um erro tremendo e uma prova de imaturidade profissional. Além disso, “Uma certificação pode até te ajudar a conquistar uma posição nova e melhor no mercado, mas não te ajuda a mantê-la.” (lembra do Julien do post “Era uma vez um testador” ?).

Esse pensamento imaturo sobre certificação é fortalecido também pelo fenômeno das “empresas três letrinhas” (empresa que tem um selo pelo selo e não pela qualidade, e quer profissionais certificados pela certificação e não pelo conhecimento) que ainda está muito presente.

Um artigo muito interessante chamado “O profissional “Um ano júnior, dois anos pleno e trinta e dois anos sênior”!?” sobre isso, foi publicado pelo meu amigo e um dos grandes nomes da Engenharia de Software, Marco Mendes, um dos maiores profissionais com quem já trabalhei, onde ele expõe com firmeza o que as pessoas de hoje fazem para ganhar o “salário dos sonhos” antes de ser o “profissional dos sonhos”.

No artigo o Marco fala sobre um método de avaliação que eu acho muito válido, baseando-se em milhares de horas de projeto, dezenas de projetos de sucesso, vasta formação acadêmica, etc. Certamente, medidas dessa proporção não são para qualquer um, mas sou um “cara da qualidade” e a palavra quantidade raramente é absoluta para mim, por isso eu não ficaria feliz de imediato se me dissessem: “Parabéns, você ganhou 10 Milhões de Dólares Zimbabuanos!”, antes de qualquer coisa eu perguntaria: “Qual a taxa de conversão em Reais?”, logo descobriria que são ~R$6,50.

Isso é um exemplo do quanto os números são traiçoeiros e de que podem ser usados para impressionar e enganar as pessoas, mesmo que isso não seja intencional. Por esse motivo acho que é muito importante questionar esses números.

Essas 7.000 horas de projetos foram executadas em quais projetos? Quais as características desses projetos? Qual a sua importância para esse projeto? Essas dezenas de projetos foram para que clientes? Qual a complexidade desses projetos? Qual a importância desses projetos para a organização? Qual a sua contribuição para o sucesso desses projetos? Quais as suas pós-graduações, suas grades e trabalhos desenvolvidos? Etc.

Por outro lado, o Marco cita também uma característica que sou obrigado a referenciar (e aplaudir): “Arrisco-me a dizer, entretanto, que talvez o atributo mais importante seja a humildade, afinal de contas, para reconhecer as próprias limitações e aprender continuamente.”.

Uma outra coisa interessante também acontece, ao contrario do que o mercado prevê, existem pessoas fantásticas que demonstram dominação de técnicas, bons pontos de vista, observações e considerações de um expert com apenas 2 ou 3 anos de experiência. Alem disso tem mais participação efetiva no mercado do que muitos dos “vovôs do teste de software” que aparecem de um dia para o outro.

Ao mesmo tempo vejo o mercado pedindo “8~10″ anos de experiência para ser um “Coordenador” ou “Engenheiro de teste”, e me pergunto: “Será que oito anos de experiência é mais do que três anos de intensa experiência?”.

Penso isso porque existem os extremos opostos dos super profissional que em dois anos já está super capacitado, com força de vontade e “matando a pau” em todas as demandas, técnicas e ferramentas citado acima. Existem os profissionais preguiçosos que se aproveitam desse “bug” nos gerentes retrógrados e ficam acomodados, sem se atualizar durante anos. No mesmo “testa aí” em um monte de projetos CRUD e  sem metade da experiência válida de um “super testador”.

Bem . . . Lamento decepcioná-lo prezado leitor, mas não posso chegar a uma conclusão ou propor uma formula mágica, ainda porque não sou um profissional que perambula por esses lados da ciência, mas posso propor rever os pontos de vista sobre o “salary label“, pensando diferente sobre os números, os títulos e etc., valorizando mais a intensidade da experiência, a capacidade de resolver problemas e o talento do profissional do que a quantidade de anos ou letrinhas embaixo no nome.

Referências:

http://blog.marcomendes.com/2008/10/23/o-profissional-um-ano-junior-dois-anos-pleno-e-trinta-e-dois-anos-senior/

(No Ratings Yet)

 Loading ...

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:

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:

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

Venha trabalhar com a nossa equipe na Squadra Tecnologia

A Squadra está abrindo vagas para o seu Programa de Estágio, nas as áreas de Desenvolvimento de Software, Testes, Qualidade e Análise de Requisitos.

Para participar, os candidatos deverão seguir as seguintes instruções:

1 – Preencher o questionário seletivo no link www.squadra.com.br (Trabalhe Conosco)
2 – Após preencher o questionário, caso as características do candidato se enquadrem ao processo, ele será chamado para uma Avaliação Técnica de Lógica, Java, teste de SW e testes psicológicos.
3 – Em sequência, haverá uma entrevista comportamental e gerencial.
4 – Para finalizar, os candidatos finais farão um mini-curso de 16 horas, com caráter eliminatório.

Não serão aceitos currículos enviados diretamente ao RH. O processo será todo gerenciado pelo site, por isso é imprescindível que o candidato envie o formulário pelo link indicado nas instruções.

Em caso de dúvidas, envie um e-mail para rh4@squadra.com.br, ou entre em contato com a Fernanda Duarte ou Cynthia Fonseca, ramal 7812.

Link direto: http://www.squadra.com.br/squadra/menu/formularios/sel_estagio.html

Boa sorte

(9 votes, average: 9,33 out of 10)

 Loading ...

Testes de unidade são uma realidade cada vez mais próxima das nossas fábricas de software, porem, é uma das coisas que tanto os profissionais de teste quando os profissionais de desenvolvimento desconhecem em sua maioria. Melhor dizendo, conhecer todos conhecem, mas ver funcionando, saber fazer e principalmente acreditar no benefício, não.

É um pouco difícil achar exemplos em blogs, sites ou comunidades de desenvolvimento e/ou testes, principalmente em português, mas um ótimo exemplo da aplicação de testes de unidade usando a ferramenta Visual Studio, para a plataforma .Net, está no excelente post “VSTS – Visual Studio Team System para Testadores – Unit Test” do Gustavo Quezada. No post ele descreve muito bem um resumo sobre o momento dos testes de unidade e também como aplicá-los tecnicamente.

Vou tentar elaborar aqui uma visão baseada em TDD (Test-driven development) usando a solução mais usada para Java, o Framework de testes de unidade JUnit, Desenvolvido por Kent Beck (XP) e Erich Gamma (GoF).

Primeiramente vamos pensar em como deve ser o micro processo para a implementação de TDD em alto nível:
1 – Escrever os Testes
2 – Executar os testes e verificar as falhas
3 – Escrever o código
4 – Rodar os testes para identificar sucesso
5 – Refatorar o código para corrigir defeitos e efetuar melhorias

Agora vamos ver isso funcionando:

1 – Escrever os Testes:
É premissa para a escrita dos testes termos todos os requisitos especificados e detalhados de forma a podemos avaliar os dados de entrada e os resultados esperados. Se você é um analista de teste já deve ter notado uma semelhança. A composição básica do nosso teste de unidade é a mesma dos nossos casos de teste, porem, ao escrever testesde unidade não nos preocupamos com as pré condições, procedimentos de teste e outros detalhes. Nosso objetivo aqui é claro: Fornecer o que a classe que será escrita precisará e receber o que ela nos fornecerá.

Vamos supor que a lista de requisitos da nossa classe é a seguinte:
“O programa deve ler 3 números inteiros. Os três valores serão  interpretados como os comprimentos dos lados de um triângulo. O programa imprime uma mensagem sobre o tipo do triângulo”

Vamos pensar em algumas opções de respostas que podemos ter:
a – Se for isósceles
b – Se for equilátero
c – Se for Escaleno
d – Se a soma de dois lados for igual a do terceiro
e – Se a soma de dois lados for menor a do terceiro

Podemos listar também algumas opções de exceções:
a – Se algum lado for negativo ;
b – Se todos os comprimentos do triânngulo forem zero;
c – Se algum comprimento do triângulo for zero;

Enfim, para isso podemos criar inúmeros casos de teste, mas para esse exercício vamos escrever apenas 14 (quatorze) considerando que o usuário sempre vá entrar com valores numéricos.

Abaixo os “casos de teste” ainda em formato texto:
1 – Triângulo Escaleno
2 – Triângulo Equilátero
3 – Triângulo Isósceles
4 – Triângulo Isósceles
5 – Triângulo Isósceles
6 – Triângulo com Lado Nulo
7 – Triângulo com Lado Negativo
8 – Triângulo cuja soma dos lados A e B é igual a C
9 – Triângulo cuja soma dos lados A e C igual a B
10 – Triângulo cuja soma dos lados C e B igual a A
11 – Triângulo cuja soma dos dois lados menor que a terceiro”}
12 – Triângulo onde todos os lados são Nulos
13 – Triângulo cuja soma dos lados A e B é menor que C
14 – Triângulo cuja soma dos lados B e C é menor que B

Abaixo vamos escrever os dados de entrada o que esperamos com eles usando a seguinte sintax
(entradaA, entradaB, entradaC, resultadoEsperado), sendo que as entradas devem ser inteiros e o resultado uma String
1 – {2, 9, 10,”Escaleno”}
2 – {20, 20, 20, “Equilátero”}
3 – {20, 20, 30, “Isósceles”}
4 – {20, 30, 20, “Isósceles”}
5 – {30, 20, 20, “Isósceles”},
6 – {0, 2, 9, “Lado Nulo”}
7 – {3, -2, 9, “Lado Negativo”}
8 – {5, 6, 11, “Soma dos dois lados igual a terceiro”}
9 – {5, 11, 6, “Soma dos dois lados igual a terceiro”}
10 – {11, 6, 5, “Soma dos dois lados igual a terceiro”}
11 – {5, 6, 12, “Soma dos dois lados menor que a terceiro”}
12 – {0, 0, 0, “Todos os lados Nulos”}
13 – {5, 12, 6, “Soma dos dois lados menor que a terceiro”}
14 – {12, 5, 6, “Soma dos dois lados menor que a terceiro”}

É muito importante entender que o teste de unidade tem menos valor se aplicado após a classe estar escrita, principalmente porque a sua principal finalidade, economizar tempo na implementação da classe deixa de ser aproveitada, ficando somente os testes “de unidade de regressão” para modificações da classe. Portanto, é fundamental escrever os casos de teste antes mesmo que a classe que será testada, para essa atividade, é muito recomendável que o analista de teste e programador trabalhem juntos, pensando em caminhos e entradas que poderão ser usados na futura implementação.

Para escrever o teste vamos precisar do Eclipse e do JUnit.
O JUnit pode ser baixado no link:  http://sourceforge.net/projects/junit/files/junit/ e incluído nas libraries do Java Build Path do projeto do eclipse.

Agora vamos entender o básico dos métodos (notation ) do JUnit:
@RunWith: Quando uma classe tem a notation @RunWith ou estende uma classe com o predecessor com @RunWith, JUnit irá chamar a classe que faz referência para executar os testes em que a classe em vez de o corredor construído em JUnit. Podemos implementar uma Suite de Testes com o parâmetro Suite.class ou uma lista de parâmetros com o parâmetro Parameterized.class (que será usada no nosso exemplo).

@Parameters: A notation de um método que cria uma coleção, array, lista ou outra estrutura de dados, de forma a garantir que não precisemos de vários métodos para executar uma sequencia ordenada de testes, através de uma sequencia de parâmetros que serão enviados, um a um, para o construtor da classe ao instânciar um objeto (teste).

@Test: A notation do método que realiza o teste. Normalmente esse método instância o objeto da classe que será testado e realiza comparações.

org.junit.Assert.*: Os métodos de comparação. realizam várias comparações como mostrado abaixo:
assertTrue : Verifica se o valor de retorno é true
assertFalse : Verifica se o valor de retorno é false
assertEquals : Compara dois valores de retorno
assertNotNull : Verifica se o valor de retorno não é null
assertNull : Verifica se o valor de retorno é null
assertSame : Confere se dois objetos referenciam o mesmo objeto
assertNotSame : Confere se dois objetos referenciam objetos diferentes
fail : usado para criar falha no teste via programação do teste

Para a lista completa dos métodos assert: http://www.junit.org/apidocs/org/junit/Assert.html
API completa do JUnit: http://www.junit.org/apidocs/

Agora vamos ver a classe de teste desenvolvida com base nos nossos dados de entrada e devidamente comentada para facilitar o entendimento:

// Importamos as classes que precisamos para usar os métodos citados

// Importante importar essa como static, pois usamos os métodos estáticos para realizar as comparações.
import static org.junit.Assert.*;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

/* Usar o RunWith informando que vamos usar uma classe parametrizada.
*  Isso fará com que ao ser instanciada como JUnit Test, a classe crie um objeto usando os parâmetros informados
*  no método Parameters para realizar cada teste, economizando dezenas de linhas de código.
*/
@RunWith(Parameterized.class)

//Declaramos uma classe normal
public class TesteExemplo {

// Declaramos os inteiros que representarão os lados do triângulo
private int a;
private int b;
private int c;

// Declaramos a string que representará o resultado esperado
private String tipo;

// Criamos o construtor que receberá os parâmetros para execução do teste
public TesteExemplo(int a, int b, int c, String trianguloEsperado) {
super();

// Cada lado do triângulo recebe um valor que vem dos parâmetros da classe
this.a = a;
this.b = b;
this.c = c;

// O resultado esperado recebe o ultimo parâmetro
this.tipo = trianguloEsperado;
}

// Método que retorna uma coleção com os parâmetros que serão usados no construtor instânciado para os testes
@Parameters
public static Collection carregaTriangulosDeTeste(){
return Arrays.asList(
new Object [][]{

// Como array em Java começa no 0, vamos incluir o teste 1 na posição 0 do array e assim por diante

//Test0
{2, 9, 10,"Escaleno"},

//Test1
{20, 20, 20, "Equilátero"},

//Test2
{20, 20, 30, "Isósceles"},

//Test3
{20, 30, 20, "Isósceles"},

//Test4
{30, 20, 20, "Isósceles"},

//Test5
{0, 2, 9, "Lado Nulo"},

//Test6
{3, -2, 9, "Lado Negatívo"},

//Test7
{5, 6, 11, "Soma dos dois lados igual a terceiro"},

//Test8
{5, 11, 6, "Soma dos dois lados igual a terceiro"},

//Test9
{11, 6, 5, "Soma dos dois lados igual a terceiro"},

//Test10
{5, 6, 12, "Soma dos dois lados menor que a terceiro"},

//Test11
{0, 0, 0, "Todos os lados Nulos"},

//Test12
{5, 12, 6, "Soma dos dois lados menor que a terceiro"},

//Test13
{12, 5, 6, "Soma dos dois lados menor que a terceiro"},
}
);

}

// Método que executa o teste a cada instanciação do objeto da classe teste
@Test
public void validaTriangulo() {
// Vamos criar um objeto do tipo Trianglulo (nossa futura classe que ainda vai existir) e passar os parâmetros do seu construtor
Triangulo escalenoValido = new Triangulo(a, b, c);

// Realizamos a comparação entre o valor que foi retornado e o valor que é esperado
assertEquals(escalenoValido.retornarTipo(), tipo);
}
}

2 – Executar os testes e verificar as falhas

Agora vamos executar a primeira vez e verificar o que o JUnit nos retorna:

É importante que todos os testes falhem, para termos certeza que estão corretos (irônico não?). Isso porque os resultados esperados não podem existir, já que nem a classe do objeto que vamos testar existe.

3 – Escrever o código

Agora vou escrever uma classe com alguns erros de lógica e outros no conteúdo da resposta:

public class Triangulo {

private int a, b, c;

public Triangulo(int a, int b, int c) {
this.a = a;
this.b = b;
this.c = c;
}

public String retornarTipo() {

// erro de lógica
if((this.a == 0) || (this.b == 0) || (this.c == 0))
return "Todos os lados Nulos";

if((this.a == 0) || (this.b == 0) || (this.c == 0))
// Erro no retorno
return "Lado Núlo";

if((this.a < 0) || (this.b < 0) || (this.c < 0))
return "Lado Negatívo";

if((this.a == this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b == this.c))
return "Equilátero";

if(
((this.a != this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b == this.c))||
((this.a == this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b != this.c))||
((this.a == this.c) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b != this.c))
)
// Erro no retorno
return "Isóceles";

if( (this.a + this.b == this.c)||
(this.b + this.c == this.a)||
(this.c + this.a == this.b)
)
return "Soma dos dois lados igual a terceiro";

if( (this.a + this.b < this.c)||
(this.b + this.c < this.a)||
(this.c + this.a < this.b)
)
return "Soma dos dois lados menor que a terceiro";

if((this.a != this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.a != this.c))
return "Escaleno";

return null;
}
}

4 – Rodar os testes para identificar sucesso

Agora vamos verificar a nova execução do testede unidade:

Na imágem acima  podemos ver que o teste nos retorna três informações muito importantes:
1 – Quantos casos de teste de unidade passaram;
2 – Quais casos de teste de unidade passaram;
3 – Qual a diferença entre o resultado esperado e o resultado recebido

Essa ultima informação em especial é que dá o “caminho das pedras” para o desenvolvedor corrigir com maior facilidade.

5 – Refatorar o código para corrigir defeitos e efetuar melhorias

Efetuamos as melhorias:

import static org.junit.Assert.*;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@RunWith(Parameterized.class)

public class TesteExemplo {

private int a;
private int b;
private int c;

private String tipo;

public TesteExemplo(int a, int b, int c, String trianguloEsperado) {
super();
this.a = a;
this.b = b;
this.c = c;
this.tipo = trianguloEsperado;
}

@Parameters
public static Collection carregaTriangulosDeTeste(){
return Arrays.asList(
new Object [][]{
//Test0
{2, 9, 10,"Escaleno"},

//Test1
{20, 20, 20, "Equilátero"},

//Test2
{20, 20, 30, "Isósceles"},

//Test3
{20, 30, 20, "Isósceles"},

//Test4
{30, 20, 20, "Isósceles"},

//Test5
{0, 2, 9, "Lado Nulo"},

//Test6
{3, -2, 9, "Lado Negatívo"},

//Test7
{5, 6, 11, "Soma dos dois lados igual a terceiro"},

//Test8
{5, 11, 6, "Soma dos dois lados igual a terceiro"},

//Test9
{11, 6, 5, "Soma dos dois lados igual a terceiro"},

//Test10
{5, 6, 12, "Soma dos dois lados menor que a terceiro"},

//Test11
{0, 0, 0, "Todos os lados Nulos"},

//Test12
{5, 12, 6, "Soma dos dois lados menor que a terceiro"},

//Test13
{12, 5, 6, "Soma dos dois lados menor que a terceiro"},
}
);

}
@Test
public void validaTriangulo() {
Triangulo escalenoValido = new Triangulo(a, b, c);
assertEquals(escalenoValido.retornarTipo(), tipo);
}
}

Agora efetuamos as melhorias necessárias e re-executamos os casos de teste até que todos passem:

Esse foi um exemplo de implementação de teste de unidade ou teste de unidade inspirados em TDD, prática ágil muito eficaz na identificação de defeitos. Nem todas as implementações são tão fáceis, ou gastam pouco tempo, mas, com o tempo e alguma prática, esse tipo de atividade pode se tornar menos custosa e mais eficiente.

Peço desculpas se algum conceito apresentado acima está divergente das melhores práticas ou de algum padrão ou conceito, e me prontifico a efetuar quaisquer correções. O exemplo citado aqui é ilustrativo.

TDD, testesde unidade, automação de testes funcionais e de performance, entre outras áreas das disciplinas de Teste de Software e Arquitetura de Software ainda são muito misteriosas e discutidas, mas pouco implementadas, principalmente aqui no Brasil. Porem, é muito importante que nossos analistas de teste busquem essa capacitação técnica para melhorar a nossa posição no mercado, melhorar a qualidade do software e da mão de obra brasileira e acabar com mitos como “o desenvolvedor é um profissional mais estudioso ou mais técnico do que o teste” ou “teste é uma atividade simples de clicar e executar alguns fluxos”.

Mantenho-me disponível para quaisquer esclarecimentos

Essa atividade é baseada em um exercício em sala no curso de Especialização em Ciência da Computação com Ênfase em Engenharia de Software da Universidade Federal de Minas Gerais (UFMG) .

Bons Testes

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(8 votes, average: 9,63 out of 10)

 Loading ...

A especificação de cenários e casos de teste é uma das atividades mais abrangentes entre os analistas de teste.

Existem dezenas de técnicas de especificar casos de teste e cenários de teste, algumas baseadas em casos de uso (como essa), outras baseadas em engenharia reversa, outras em componentes visuais (tela) e assim por diante.

A pedido de um leitor do meu blog, o Heiber, da cidade de Bogotá na Colômbia, que faz um esforço para entender meus textos “mediamente” elaborados em português e um esforço possivelmente maior para conversar comigo em espanhol, vou disponibilizar um rascunho de uma das técnicas que uso para modelar cenários e casos de teste (ou casos de prueblas em espanhol).

Para isso vamos imaginar um típico caso de uso, bem simples. Digamos que ele possui algumas regras, um fluxo principal, alguns alternativos, outros de exceção e pontos de extensão. A primeira coisa a fazer, supondo que o caso de uso já tenha sido aprovado em revisões e outros procedimentos para garantir que esteja preparado para ser implementado, é ler atenciosamente o caso de uso, tentando entender bem o contexto e seus objetivos. Em seguida, criar um desenho dos fluxos que esse caso de uso possui, bem abrangente, se possível com todos os fluxos desenhados no mesmo lugar, como um mapa mundi do caso de uso. Para isso é recomendável usar um diagrama de atividades disponível em qualquer ferramenta case open source na internet, mas em qualquer situação, pode ser feito no “papel de pão mesmo”.
Nesse momento temos algo mais ou menos como a figura abaixo:

Esse “esqueleto” nos da uma idéia um pouco próxima do que precisamos para mapear os casos de teste, mas ainda é insuficiente para dizer o que temos de cobertura com as regras de negócio vinculadas ao caso de uso.

Existe uma prática muito comum que é criar um caso de teste para cada regra do caso de uso, que inclusive é a mais recomendada em casos de sistemas críticos onde temos muitas horas para especificar e testar, mas, muitas vezes temos de usar uma técnicas chamada “pair wise” para especificar nossos casos de teste. Nesse exemplo, os cenários de teste permitem que os dois modelos sejam aplicados, comum caso de teste por regra ou tendo em um único fluxo, várias regras:

*Supondo que a regra R06 foi cancelada

O diagrama acima nos mostra os vários caminhos possíveis para o mesmo caso de uso. É importante que nenhuma regra possa modificar o fluxo do caso de uso. Regras com condições como “Se . . . então . . .  senão. . .” podem ser muito prejudiciais aos casos de uso, escondendo a complexidade e induzindo a modelagens incorretas.

Agora vamos dar um nome para cada um dos cenários, baseando em seu significado no caso de uso:

Com o desenho acima podemos entender melhor cada cenário e seu fluxo. Ainda podemos ver que cenários podem ser combinados resultando em novos cenários, como por exemplo, o FA02 que pode continuar no FA03 ou pode voltar para o FP.

Por ultimo, consolidamos as duas visões e “voilà“,  temos boa parte do que precisamos para escrever bons casos de teste.

A partir do desenho acima já podemos especificar vários casos de teste, com entradas diferentes e saídas diferentes, com validações para cada uma das regras ou para múltiplas regras. A configuração daqui para frente, depende muito do nível de detalhamento que será usado, mas a rastreabilidade continua sendo a mesma:

{N Procedimentos**, Entradas e Saídas} ∈ {1 Caso de Teste}
{N Casos de Teste} ∈ {1 Cenário de Teste}
{N Cenários de Teste} ∈ {1 Caso de Uso}
*∈ = Pertence

**O conceito de procedimentos de teste é um dos mais confusos. No dia a dia eu uso ele para chamar o passo a passo dos casos de teste.

O desenho acima foi feito com caráter ilustrativo e para isso foi usado o MS Power Point, mas eu recomendo a utilização de ferramentas apropriadas como o IBM – Rational Software Architect ou o Enterprise Architecture.

Desenhar os cenários e casos de teste é uma coisa que fazemos mesmo que mentalmente quando especificamos, mas é muito importante ter um esboço físico dessa atividade, para perceber falhas, minimizar riscos e compreender melhor o que será testado.

Espero que esse post possa ajudar pessoas com a mesma dúvida do nosso amigo da Colombia. O modelo acima é um dos mais usados e é muito eficiente, mas é um modelo de muitos disponíveis no maravilhoso mundo da engenharia de software.

Fico aberto a comentários, críticas e sugestões.

Bons testes

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(5 votes, average: 9,80 out of 10)

 Loading ...

A maioria dos analistas de teste e testadores não sabe onde estão o defeito que eles encontram, ou em outras palavras, não analisam nem acompanham o defeito após encontrá-lo, ou quando fazem, podem fazer de maneira incorreta, o que de certa forma é mais prejudicial do que se não fizessem.

Na verdade, é quase impossível, até mesmo para um analista de teste experiente dizer com certeza que o defeito que ele encontrou é de software, requisitos, análise, desenho, configuração etc. Os defeitos mentem, e isso é um fato que vamos ter que conviver cada vez mais, já que a cada dia a complexidade dos projetos de software aumenta e com ela a complexidade dos defeitos e da arquitetura do software em desenvolvimento.

A atividade de gerência de defeitos é uma das atividades mais importantes para o projeto e principalmente para a organização. Com uma boa gerência de defeitos, vários indicadores podem ser utilizados para conhecer e melhorar os processos e a capacitação dos profissionais.

Alguns dos indicadores* são:

•TD (Total de Defeitos)
•DD (Detecção de Defeitos)
•DDG (Detecção de Defeitos Graves)
•TDG (Total de Defeitos Graves)
•ETS (Eficiência de Teste de Software)
•ERR (Eficiência de Revisão de Requisitos)

*Em um próximo post vou falar sobre métricas e indicadores.

Apesar de ser uma ferramenta muito importante, a gerência de defeitos muitas vezes é usada de forma incorreta ou não é aproveitado o seu potencial, ficando limitada a um workflow do Bugzilla ou do Mantis.

Como os defeitos não são analisados, as pessoas não se importam com onde eles foram encontrados, nem com quando eles foram encontrados, até o dia que um determinado projeto está com problemas e alguém pede uma métrica de “bugs” por desenvolvedor, normalmente solicitado por uma pessoa que não tem experiência como analista de testes ou está iniciando na carreira de coordenador/gerente de projetos.

Esse é o grande perigo. Como citado no post Bug is Dead!, a idéia de “bug” da uma impressão muito ruim dos desenvolvedores, pois bugs são de software, e software quem faz são os desenvolvedores e programadores. O ideal para evitar esse tipo de mal entendido, é catalogar os defeitos de forma a saber de onde eles vieram e não quem causou o defeito.

Nenhum defeito pode ser atribuído somente a uma pessoa no projeto, mas sempre a um conjunto de eventos, que, de não conseguiram evitar que esse problema fosse inserido em determinado momento do processo.

Agora vou dizer uma coisa que pode te assustar prezado leitor:

A identificação da origem do defeito não é de responsabilidade do profissional que encontrou o defeito.

Muito simples, o profissional de testes ou quem encontrou o defeito, não pode saber claramente a sua origem, não pode dizer com certeza absoluta onde o defeito estava. Se estava no código, se era no ambiente, uma configuração do servidor, um problema de compatibilidade etc.

A única pessoa que tem essa informação é quem corrige o defeito. Ele é o único que sabe com 100% de certeza onde o defeito estava.

A responsabilidade de acompanhar essa informação e de garantir sua integridade sim, é de responsabilidade do gerente de defeitos, que normalmente é uma pessoa da qualidade ou teste de software. Por isso é importante acompanhar o andamento dos defeitos, preferencialmente todos os dias, de forma a manter o controle e rastreabilidade entre o defeito e sua origem.

Outra situação que acontece com frequência com novos testadores, é que assim como a nossa querida Tia Cida que sem querer escreveu “Café com defeito” quando na verdade o defeito estava no repositório de colheres da máquina de café. É um exemplo bobo e divertido, mas muito próximo do que acontece com algumas pessoas. Por vezes, os defeitos são descritos de forma pouco detalhada, com informações insuficientes para sua reprodução, com falta de atenção ou as vezes detalhado demais, dificultando sua interpretação.

Não existe uma forma de garantir que a descrição do defeito esteja perfeita, mas uma técnica que venho usando com sucesso é a substituição do passo a passo pelos procedimentos (passo a passo) do caso de teste que detectou o defeito.

Dessa maneira, a pessoa que corrigiu o defeito executa um teste de regressão e não um teste de confirmação. O mesmo acontece quando o testador recebe o defeito para verificar/validar, ao invés de executar um teste de confirmação, limitado as condições únicas daquele defeito, ele executa um teste de regressão, garantindo que aquela funcionalidade continua funcionando mesmo após a correção daquele defeito.

Caso o teste tenha sido detectado por um teste exploratório, o testador pode criar um Caso de Teste numa suíte especial, para aquele defeito (considerando o resultado esperado), e somente em seguida deve cadastrar o defeito na ferramenta de gestão de defeitos. Essa é uma pratica do XP que também da muito certo.
*O detalhamento dessa e outras práticas pode ser lido no post “Práticas XP ajudando na efetividade do teste de software“.

Bons Testes

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(3 votes, average: 10,00 out of 10)

 Loading ...

Hoje eu resolvi escrever uma historinha que pode nos ajudar a refletir sobre a nossa carreira, nossa empresa, nossos objetivos e principalmente sobre nossos próximos passos.

A história é totalmente fictícia, não faz referência a nenhum profissional, certificação ou empresa em particular, mas aproveitei um pouco do que ando vendo nos fóruns e lendo em alguns livros sobre carreira e liderança para criar uma história que pode ser a história de muita gente aí fora.

Espero que gostem

Hoje é o primeiro dia da Sophie Kowalsky, nova testadora na BugSoft Corporation. Ela foi selecionada entre os mais de 150 candidatos a vaga de estágio no departamento de qualidade da BugSoft. Nessa seleção, a BugSof se preocupa não no conhecimento que o profissional já tem, mas sim nas características pessoais dos candidatos. Ser criterioso, detalhista, crítico e comunicativo é mais importante do que dominar linguagens, ferramentas ou ter certificações.

Hoje ela está começando a sua carreira de estagiaria como testadora, mas nunca viu nada sobre teste na vida, afinal de contas, na faculdade que ela estuda não existe nenhuma matéria exclusiva de teste de sioftware.
Ela está entusiasmada com as novidades, aos poucos começa a pegar o ritmo sobre como fazer testes exploratórios, em algumas semanas já consegue executar testes de casos de teste e reportar ótimos defeitos.

A BugSoft é uma empresa responsável e visionária, seis meses depois contratou a Sophie mesmo sem ter terminado a graduação, agora ela é uma testadora e já conhece muito sobre a malícia de encontrar defeitos.
Um ano e meio depois, a Sophie terminou a sua graduação, agora com dois anos de experiência já começa a ajudar Julien, analista de teste certificado, com a especificação de alguns casos de teste menos complexos e já está estudando para ser uma profissional certificada.

A BugSoft é uma empresa responável e visionária, acredita em pessoas como Sophie e resolveu ajudá-la na conquista da sua primeira certificação com os custos, materiais e algumas horas de estudo durante o expediente. O resultado não podia ser diferente, a Sophie passou com 90% de aproveitamento na prova da certificação, e agora é uma profissional certificada. A empresa reconheceu o valor da certificação, mas informou que existe mais um tempo de aprendizado até que ela possa se tornar uma analista de teste de software.

Com a certificação, a Sophie que acompanha diversas listas de discussão sofre por várias vezes a tentação de mudar da BugSoft para uma outra empresa que esteja pagando um alto salário para um profissional certificado, mas ela resiste pois confia na posição dos seus líderes que tem uma carreira pronta para ela na organização, seu amigo Julien, analista de teste, resolveu abandonar a BugSoft para ir para a CertifiedSoft.

Seis meses depois, Sophie é promovida a Analista de Teste. Ela fica muito contente, tem um aumento considerável e está novamente recarregada e motivada. Ficou aliviada em não tentar ir para a nova oportunidade, pois Julien, acabou descepsionado. Ele confessou que apesar do salário, os projetos não eram tão interessantes, os líderes não tinham as habilidades necessária e o clima de competição enfraquecia o companheirismo, já que as certificações valiam ouro e ele executava na maioria do tempo atividades de testador, quando na verdade gostaria de trabalhar como analista de teste.

Passado um ano, o envolvimento da Sophie cresceu muito em alguns projetos, e no principal seguimento da BugSoft, o que fez com que os líderes da empresa começassem a vê-la de uma forma diferente. Sua líder direta, Christelle, ressaltou a capacidade de organização e a facilidade ao lidar com pessoas de Sophie e em um acordo com os diretores da empresa, mesmo sem o conhecimento da Sophie, começou a direcioná-la para uma carreira de liderança.
Em conversas informais sobre livros, sobre, MBAs e etc., começou a influenciar Sophie de uma maneira a orientá-la a um crescimento dentro da empresa.

Sophie decidiu se matricular em uma pós graduação de Gerência de Projetos e a BugSoft colabora com 50% das despesas com educação da Sophie. Depois de um ano ela já está na metade da pós graduação e a empresa está crescendo em um ritmo muito estável, consequentemente, com projetos maiores. A empresa decide então promover Sophie para Coordenadora de Teste.

Agora ela coordena os novos testadores e analistas de teste, os orienta quanto as mesmas dúvidas que ela teve nos últimos quase quatro anos e organiza os projetos em que participa para otimizar os recursos de teste. Toma decisões importantes, mas sempre consultando sua líder, Christelle.
Claro que Sophie almeja um dia ser líder de teste, mas ela é demasiadamente leal a Christelle, que retribui com a mesma lealdade e atenção, e durante todos esses anos a ajudou em sua carreira.  As duas comemoram vitórias umas das outras como se fossem suas próprias.

Ao mesmo tempo, Julien já é líder de testes. Claro que ele teve que enganar um pouco daqui, enganar um pouco dali, puxar o tapete de algumas pessoas, inclusive do seu líder que de tanta pressão acabou pedindo demissão. Julien hoje suporta uma pressão maior ainda do que seu antigo líder. A CertifiedSoft despenca em faturamento pelo terceiro ano consecutivo, além dos altos salários que paga para os profissionais certificados que não param de sair para outras oportunidades, ela enfrenta uma crise, pois sua principal certificação não foi aprovada na reavaliação RightProcess, o que custou o título de qualidade que foi conquistado por anos e anos de consultorias e horas gastas, naquela época em que a CertifiedSoft contava mais com pessoas motivadas sem certificação.

Mais dois anos se passaram e a BugSoft cresceu e conquistou um novo mercado em outro país. Uma mudança no organograma foi feita e agora a Christelle foi promovida para Gerente de Teste do mercado atual, enquanto o seu superior foi promovido como diretor do novo pólo. Obviamente Christelle se lembrou imediatamente que Sophie havia terminado a sua pos graduação e agora já estava com mais de 12 pessoas no seu comando. Sophie tinha conseguido elevar a produtividade dos colaboradores sem modificar o clima harmonioso da fábrica de testes e agora estava prestes a começar o seu MBA em Planejamento Estratégico de Pessoas, MBA em que Christelle tinha concluído a um ano atrás. Com o cenário atual, Sophie foi promovida para Líder de teste, não só no departamento em que Christelle liderava, mas também em outras duas filiais.

Cinco anos mais tarde, após um longo período de complicações, a CertifiedSoft não resistiu e perdeu muitos de seus clientes para a BugSoft, que reformulou seus objetivos estratégicos e conquistou o nível máximo de excelência nos últimos cinco anos durante as auditorias do RightProcess. A CertifiedSoft teve que realizar cortes e Julien foi demitido.

Julien era uma pessoa que se esforçava pela empresa, mas como a CertifiedSoft tinha uma alta taxa de rotatividade, muitas pessoas conheceram Julien, que por ter sido lapidado por uma empresa com uma cultura voltada a comparações e competições, acabou tornando muitas dessas pessoas “inimigas”, o que dificultou seu retorno para o mercado como líder de teste.

Hoje, cinco anos depois, a BugSoft é uma das maiores empresas do seguimento de software no continente e possui várias filiais e diretorias. A diretoria de Planejamento Estratégico de Qualidade é liderada Pela Dr.ª Kowalsky, que insiste em ser chamada de Sophie. Ela ajuda a organização a tomar decisões importantes, a encontrar talentos e a conquistar novos mercados.  Nessa mesma empresa, está entrando um novo analista de teste chamado Julien. Na verdade, ele já trabalhou aqui a alguns anos, mas isso quando a BugSoft ainda era uma “empresinha” na pequena cidade SmallCity.

A história acima é totalmente hipotética, mas reflete a influência que a empresa tem sobre os colaboradores e o como a pressa por altos salários pode atrapalhar uma carreira promissora. Os personagens também são fictícios e os nomes vieram de um filme francês chamado “Jeux d’enfants” que na verdade é uma história romântica.

Quando pensamos em carreira, não devemos pensar em salários, certificações e títulos, mas sim em experiências, network e conquistas. Essas conquistas podem ser nossas, da nossa empresa, dos nossos lideres, dos nossos colegas de trabalho, dos nossos colegas de blog e mercado ou do nosso seguimento. Quando uma pessoa tem sucesso, todo mundo é afetado de uma forma positiva.

Conhecer o mercado, dominar o ego, trabalhar em equipe, esperar e aproveitar oportunidades, não são habilidades fáceis de aprimorar e na maioria das vezes são mais decisivas na nossa carreira do que certificações, pós graduações ou títulos conquistados.

Uma vez um dos meus lideres me disse: “O segredo para o sucesso é ser lembrado sempre que tocarem em assuntos da sua área de atuação“.

Bons testes

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(No Ratings Yet)

 Loading ...

Imagine um grupo de onze viciados em PlayStation lutando pela oportunidade de passar o dia todo com jogos que ainda não foram lançados, consoles para o futuro, periféricos novos e tudo dos videogames da Sony, e ainda ganhar 5000 dólares para viver como testador da Sony.

A Sony lança no próximo dia 18 a inovadora série “The Tester“, com oito episódios, onde onze testadores em potencial vão disputar provas de mentais, físicas e claro, jogar muito PS3 para ganhar esse trabalho. Depois de realizar as provas, os candidatos serão eliminados um a um por uma bancada composta por três juízes.

Pelo preview o seriado parece muito divertido, com provas de resistência e competições em jogos. Funciona mais ou menos como um “britains got talent” para viciados em videogame e será exibido na PlayStation®Network.

Vale muito a pena assistir o vídeo. Para assitir e ler mais sobre o desafio acesse a url abaixo:
http://www.thetester.com/

Bons testes