Cobertura CInTeQ 2010 – Dia 1 (parte 2)

Continuando a cobertura do CInTeQ (Congresso Internacional em Testes e Qualidade de Software), um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB. Irei fazer o relato de como foram  as palestras que ocorreram após o almoço do primeiro dia do evento (se você que saber como foram as primeiras palestras, pode acessar esse link).

Mas antes de falar das palestras que ocorreram após o almoço, eu preciso comentar sobre a in-ter-ven-ção. Isso mesmo intervenção, eu também estava curiosa para saber o que seria essa tal de intervenção, e foi uma surpresa muito boa.

Para explicar melhor, havia um apresentador/animador/show-man (ele fazia vários desses papéis rs [infelizmente não lembro do nome dele), que fazia a introdução de cada palestra e intervia  nas paradas para o coffee-break e almoço. Esse “rapaz” foi o responsável por causa a maior bagunça (no bom sentido é claro) para mandar embora aquela conhecida sonolência que ocorre após o almoço, utilizando uma tal de Neuróbica, onde foi passado dois exercícios de complexidade extrema: contar de 1 a 3 em dupla e cantar uma “musiquinha” (Toque Patoque).

Update 25/03

O Mário lembrou do nome do apresentador (nos comentários), é o Felipe Mello, ele é Ator, Palhaço, Comunicador social, Radialista e Fundador dos Doutores Cidadãos.

Foi passado ainda dois vídeos bem interessantes, além do apresentador ter feito várias citações de frases de reflexão, como por exemplo: “O modo de ser depende das decisões e não das condições.”

Um último comentário antes de irmos para as três últimas palestras do primeiro dia, você ficou interessado(a) na palestra do Rex Black? Quer saber mais sobre o assunto? Se a sua resposta é sim, então baixe agora mesmo a primeira edição da revista Agile Record, nela há um artigo do Rex Black com o seguinte título “How Agile Methodologies Challenge Testing”, o conteúdo do artigo é o mesmo da palestra que foi dada no CInTeQ.

Mieke Gevers  – How the Performance testing results can fool you! All You Need to Know to Get Control of the Evaluation Process

A belga Mieke Gevers, especialista em teste de performance e monitoramento, iniciou a sua palestra dando uma breve visão geral sobre teste de performance/desempenho. Explicou também um pouco sobre teste de escalabilidade, usando uma analogia com o deslocamento das pessoas para uma partida de futebol.

Logo após a palestrante começou a falar sobre a coleta de dados, que podem ser divididos em três tipos:

  • Dados do projeto (ex. quando será feito o teste);
  • Dados do testes (ex. massa de dados necessária);
  • Dados do resultado (ex. quais métricas serão usadas).

Na sequência a Mieke falou sobre como coletar estes dados:

  • Há ferramentas, que pode te dar ótimos resultados;
  • Exploração;
  • Recursos do sistema (ex.: gerenciamento de tarefa).

Depois a palestrante falou sobre o que podemos avaliar:

  • Arquitetura do sistema
  • Topologia de deployment;
  • Componentes de terceiros;
  • Capacidade do firewall;
  • Balanceamento de carga;
  • Conectividade;
  • Rede;
  • Gerenciamento da sessão;
  • Todas consultas;
  • Modelos de cache.

É preciso aplicar métricas, mas é mais preciso ainda, saber interpretá-las, comparar os resultados e buscar as origens dos gargalos.

Também precisamos lembrar, que assim como os testes funcionais, é importante participar o mais cedo possível, testar performance no final não é uma boa idéia (eu diria que pode ser uma péssima idéia, uma vez que dependendo da aplicação é mais importante a performance do que a funcionalidade, lembre-se disso).

Há também alguns “agentes” que podem influenciar o teste de performance:

  • As metodologias de teste e desenvolvimento;
  • A fase de testes;
  • O ambiente de teste;
  • E é claro as pessoas.

O que podemos procurar quando fazemos testes de performance?

  • Simular usuários;
  • Tempo de respostas;
  • Bytes por segundos;
  • Conexões.

Após apresentar vários gráficos comentando sobre a importância de saber interpretar os dados a Mieke finalizou a sua apresentação falando sobre o futuro, onde levantou uma pergunta interessante e fez algumas considerações finais:

  • Será que as técnicas que usamos hoje serão suficientes?
  • A melhor forma de prever o futuro é inventar;
  • Os testes são sempre algo envolvente, sempre precisamos trabalhar com dados, eles são a chave, sempre é necessário coletar dados.

Impressões da palestra

A apresentação da Mieke foi “estranha” para mim, acho que por eu ter lido a descrição da palestra no site do CInTeQ antes e ter um pouco de experiência com teste de performance, fizeram a minha expectativa ser muito alta para essa palestra.

Na minha opinião a Mieke não conseguiu ligar muito bem os assuntos abordados na palestra, o que fez com que no final eu tivesse a impressão de ter sido bombardeado por várias informações e gráficos que não conseguiram me mostrar uma conclusão, a não ser a que já se subentende, pelo próprio título da palestra: teste de performance não é apenas sobre coletar dados, e sim principalmente, sobre como interpretar esses dados (só pensar na analogia com a bolsa de valores).

Emílio Silva de Castro – A Importância da Especialização dos Papéis em uma Fábrica de Testes

O Emílio, gerente de projetos da RSI, iniciou a sua palestra falando dos objetivos da palestra, na qual seriam comentados os desafios para estruturar uma equipe de teste e como estruturar tal equipe.

Quando Testar?

  • Testar desde do início;
  • Definir o escopo de atuação dentro do desenvolvimento do software;
  • Definir os objetivos do nosso testes.

Todos esses são fatores que podem influenciar a composição da nossa equipe

O Emílio fez uma importante consideração sobre qualidade, dizendo que ela depende da perspectiva, ou seja, quem desenvolve tem uma perspectiva X, já quem usa o software tem uma Y e o testador precisar ter uma mistura entre X e Y.

Outro fator que pode influenciar a composição da nossa equipe são os níveis de testes (unitário, integração, sistema e aceitação), que a sua fábrica se propõe a atuar. Afinal para os testes de cada nível são necessários conhecimentos diferentes, por exemplo: para testes de unidade um conhecimento técnico é fundamental, já para os testes de aceitação o mais importante é ter um bom conhecimento do negócio.

Precisamos também pensar nas técnicas de teste que irão compor a nossa estratégia:

  • Testes estáticos: análise estática e revisão;
  • Testes dinâmicos: caixa-branca, caixa-preta (funcional e não-funcional).

Depois o palestrante falou sobre os papéis que existem na RSI e quais conhecimentos são necessários:

  • Gerente de Testes: precisa de conhecimentos sobre gerenciamento de projetos, engenharia de software e conhecer de forma avançada Teste de Software;
  • Executor de Testes: precisa ter fundamentos de teste, negócio e ortografia e gramática. Esse profissional irá executar os testes elaborados pelo Engenheiro de Testes;
  • Automatizador: lógica de programação, melhores práticas de codificação, ou seja, precisa ter um perfil bem programador;
  • Engenheiro de Testes: fundamentos de teste (uma CTFL), conheça o processo de desenvolvimento, negócio (financeiro, telecomunicações, agronegócio e jurídico);
  • Revisor: tem um perfil de análise estática, precisa conhecer requisitos, análise e design (UML), codificação, ortografia e gramática;
  • Técnico: necessita conhecer o ambiente que será utilizado durante os testes: plataforma, SOs, redes, segurança, banco de dados, servidor da aplicação.

Outros pontos interessantes falados pelo Emílio foram:

  • Não adianta ter um vasto conhecimento e demorar ou fazer algo com baixa qualidade;
  • O aspecto motivacional é muito importante;
  • Quem dá o “ok” final é quem detém o poder do negócio, os profissionais de Teste de Software podem ajuda a tomada de decisão, mas nunca tomar a decisão;
  • Quando falamos em métricas precisamos saber a eficácia no encontro de defeitos e a existência de defeitos durante o ciclo de desenvolvimento (quantos bugs foram encontrados em cada fase).

Por fim o palestrante encerrou a sua apresentação falando sobre os fatores críticos de sucesso, que são:

  1. Pessoas: o maior ativo que uma empresa pode ter;
  2. Ver o teste como oportunidade de melhoria.

Impressões da palestra

A apresentação do Emílio foi a mais “leve” de todas, e por ser de nível básico, não trouxe nenhuma surpresa ou novidade ao público. Mas não por isso, a palestra foi ruim, muito pelo contrário, eu achei ela muito boa, pois o Emílio conseguiu falar sobre vários temas de Teste de Software, para apoiar o seu tema principal, que era mostrar a importância e os desafios da especialização dos papéis no contexto de fábrica de testes. Ou seja, foi uma apresentação muito bem estruturada e o conteúdo foi passado de uma forma muito clara e didática.

Patricia McQuaid – Software Disasters: What Have We Learned?

A Patricia, presidente e co-fundadora do American Software Testing Qualifications Board (ASTQB) e professora de Sistemas de Informação em uma universidade da Califórnia, falou durante a sua apresentação sobre diversos desastres que ocorreram devido a falhas no software.

Muitos das falhas ocorridas geram prejuízos na ordem de milhões de dólares e em alguns casos houve até mortes. E algumas dessas falhas eram até bem grotescas, como no caso do Mars Climate Orbiter, onde o uso de medidas inglesas, quando o software foi programado para realizar apenas cálculos no sistema métrico, provocou a destruição da nave ao entrar na atmosfera  de Marte.

Outro case bem interessante foi o do Aeroporto Internacional de Denver, onde uma falha geral no sistema automático de transporte de bagagem, causou um prejuízo de “apenas” 360 milhões de dólares e ainda outros 86 milhões foram gastos para manutenção do sistema, isso sem falar nos 6 meses de atraso na abertura do aeroporto. E o gerente do projeto ainda pensava que o sistema de bagagem não seria tão complexo (#epicfail).

A Patricia ainda fez uma análise do que levou a esses problemas, citando:

  • Pobres práticas de codificação;
  • Testes grosseiramente inadequados;
  • Análise dos dados funcionais pré-aprovadas;
  • Um único programador criou o software;
  • Falta de documentação;
  • Apresentação de erros que não eram de fácil compreensão;
  • Assumir que o  reuso do software é algo seguro;
  • Reporte de incidentes eram mal feitos.

Ou seja, muitos dos problemas ocorridos foram uma junção de vários fatores, que envolviam tanto o processo quanto as pessoas.

Patricia, eu e a Mieke (Foto tirada pelo Mário Pravato Junior)

Impressões da palestra

Eu achei que a Patricia falou sobre muitos desastres, o que fez com aquela tivesse que correr um pouco na explicação de alguns. Mas mesmo assim, ela conseguiu atingir o objetivo da palestra, que era mostra que falhas podem custar muito caro, e pior do que milhões de dólares em prejuízo e a perda de vidas por causa de falhas, como ocorreu por exemplo no THERAC 25.  Além disso a palestrante deixou uma mensagem muito importante, a de que precisamos aprender com o nosso passado, para evitar que as mesmas falhas ocorram novamente, e uma dessas lições aprendidas é de que testes são fundamentais!🙂

No término das palestras do primeiro dia, ainda houve o sorteio de um curso preparatório da CTFL, por um dos patrocinadores do CInTeQ, a Iterasys.

Aqui encerro a cobertura do primeiro dia, até a primeira parte do segundo dia!😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Impressões da palestra

a

7 comentários sobre “Cobertura CInTeQ 2010 – Dia 1 (parte 2)

  1. Pingback: Cobertura CInTeQ 2010 – Dia 1 (parte 1) « QualidadeBR

  2. Nome do “rapaz”: Felipe Mello!

    Ele é “doutor da alegria” e uma figuraça!!! To com vídeos do “Cintecc” da terça!!! Depois vou postá-los!

    Ah, cadê o crédito das fotos do fotógrafo aqui? hahahahaha

    Parabéns pela cobertura!

    abraços

    Responder
  3. @Felipe

    De nada.😉

    @Mário

    Valeu! Já vou atualizar o post colocando o nome dele e os créditos do fotógrafo hehehe

    Responder
  4. Pingback: Cobertura CInTeQ 2010 – Dia 2 (parte 1) « QualidadeBR

  5. Pingback: Cobertura CInTeQ 2010 – Dia 2 (parte 2) « QualidadeBR

  6. Pingback: O melhor do Ensinar – 20/03 à 26/03 « Blog do Ensinar

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s