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

Anúncios

Errar é humano

Hoje, conversando com um amigo meu no trabalho, sobre como foram os testes durante a atualização do ambiente de produção, ele me disse que ele acabou errando em uma mudança e teve que derrubar e subir novamente o ambiente, que acarretou em um pequeno atraso na atualização. Isso durante os testes de performance, que são executados no ambiente de produção, logo após, os testes funcionais.

O que me chamou dessa história toda, não foi o fato dele ter cometido um erro, e sim a cara e a forma que ele me contou. Como se ele tivesse feito algo, realmente ruim, como se a falha tivesse ocorrido devido a uma falta de atenção o algo do tipo. Mas não, a falha ocorreu, devido a complexidade do teste e do sistema. Para se ter uma idéia, na nossa equipe, ele é a única pessoa que executa os testes de performance e HA (High-Availability), e tais testes exigem um alto conhecimento da aplicação e sua arquitetura, além da ferramenta utilizada, o SIPp. O que torna esse profissional, um diferencial para a equipe. E o erro cometido por ele, eu não iria cometer, pois não tenho conhecimento suficiente para fazer esses testes, logo não iria tentar fazer o teste.

Logo, percebemos algo muito importante, só erra aquela pessoa que tenta. Sei que errar parece ser algo ruim. E parcela desse pensamento, deve-se a nossa formação acadêmica, na qual quando cometíamos algum erro, logo recebíamos alguma punição ou um belo de um X vermelho.

Isso faz com que a gente, tente evitar ao máximo um erro, principalmente na equipe de Qualidade e Testes, onde “caçamos” falhas, que são originárias de um erro de alguma outra pessoa. Mas, tenha a certeza, que mesmo evitando os erros, estamos sempre correndo o risco de errar, pelo simples fato, de sermos humanos. E nós aprendemos muito mais com um erro, do que com um acerto.

O que é errado é a pessoa não reconhecer o próprio erro, e pior ainda é não tentar. Lógico, que se você ficar na sua cama deitado, você não vai cometer nenhum erro. Assim, como um carro não quebra, se ficar na garagem.

Por isso, se as pessoas te crucificarem por um erro, lembre-se de uma frase, dita por alguém bem conhecido: “perdoa-lhes, pois eles não sabem o que fazem”.

E para mim, errar é não tentar.

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