Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By Fabrício Ferrari de Campos

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:

Pessoas: o maior ativo que uma empresa pode ter;
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

Source: http://qualidadebr.wordpress.com/2010/03/25/cobertura-cinteq-2010-dia-1-parte-2/

Category: Teste & Qualidade de Software, CInTeQ 2010, desastres de software, especialização, fábrica de testes, papéis, teste de performance

Você também pode querer ler

Comments are off for this post.