The Bug Bang Theory

(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