Especializações interessantes para os profissionais da área de teste de software

32ª Mesa Redonda foi sobre “Especializações interessantes para os profissionais da área de teste de software” e teve apenas 2 respostas e 3 participantes, sendo eles: eu, Elias Nogueira e Lidiane Santos.

Como a discussão foi curta, abaixo segue praticamente a íntegra das contribuições feitas pelo Elias e pela Lidiane e também alguns comentários meus.

O Elias abordou vários pontos relevantes, entre eles o insight de que uma especialização na área de Teste de Software, não precisa ser necessariamente na área. Pode parecer estranho, mas é verdade:

Acredito que a especialização em si na Área de Teste não é apenas sobre a área (ex: uma pós em Gestão de Qualidade ou Teste de Software), e sim mais sobre o negócio onde trabalhamos (SOA, Sistemas Distribuidos, Mobile, etc…)

Claro que esse meu pensamento é um pouco puxado para o lado técnico. 😛

Sempre acreditei que o profissional em teste é um dos mais completos, por causa da variedade de conhecimentos que ele precisa ter para desempenhar sua função (óbvio que dependendo do papel/nível do mesmo). Logo, penso que a carreira de um profissional de teste é cheia de conhecimento “fora-teste” (análise de requisitos, programação, etc..)

Hoje, dentro da área acadêmica (Especialização, Pós, MBA) eu vejo quase que 100% formações de líderes, analistas de qualidade ou correlatos. É muito difícil encontrar algum curso acadêmico mais técnico em teste, ou que pelo menos ensine técnicas de teste, algumas ferramentas, etc…

Vejo que o profissional, se deseja algo mais técnico, tem que recorrer a uma destas áreas acadêmicas fora de teste ou recorrer a um mestrado para desenvolver algo diferente. É um ponto que as universidades estão amadurecendo, mas muito lentamente (se pensarmos o número de matérias de programação x número de matérias sobre qualidade e teste de software)

Eu fiz uma Pós em Teste de Software (onde vi toda a área de validação) na Unieuro, e recomendo. Apesar de eu já ter o conhecimento do que eu tive na pós, eu a procurei alguns motivos: ter outras visões do mesmo assunto e ter uma certa comprovação acadêmica. Hoje já recorro a cursos dentro da minha área de especialização que mais me interessam.

A minha dica é que na hora da escolha de uma especialização na área, em termos acadêmicos, que o profissional saiba qual linha ele quer/vai seguir, pois para a linha técnica não existe muita coisa.

Aproveito pra listar aqui algumas instituções acadêmicas ao redor do Brasil que possuem cursos voltados para a área de Teste e Qualidade de Software (sugestão de ficar como um thread separada depois)

– Unieuro (Brasília/DF) – MBA em Teste de Software (Pós Graduação) [não existe mais]

– Feevale (Novo Hamburgo/RS) – Teste e Garantia da Qualidade de Software (Pós Graduação)

– Unisinos (São Leopoldo/RS) – Qualidade de Processos de Software (Tecnológico)

– FIAP (São Paulo/SP) – MBA em Gestão da Qualidade em Software com ênfase em CMMi e MPS.BR (Pós Graduação) [não existe mais]

– SENAC (São Paulo/SP) – Gestão da Qualidade de Software (Pós Graduação)

 

 

 

UNICAMP – Especialização em Engenharia de Software

A Lidiane contou um pouco da sua experiência e lembrou que participar de eventos é uma forma de buscar se especializar e também de compreender melhor a área e a sua amplitude:

Realmente esse tema é muito importante e legal. Vejo muitas pessoas que estão na área de teste que não sabem que os profissionais dessa área podem ter uma carreira.

Em relação a especializações, existem muitos cursos legais de ferramentas, automação de testes, implementador MPT.BR, TMM. Vejo que há bastante cursos online e/ou semi-presencias, mas não são muito divulgados

Pós-Graduação, eu vejo que é muito interessante na area de Engenharia de Software, Qualidade de Software, é muito importante analisar a grade, pois tem algumas pós que não abordam muito o tema Teste SW.

Na Poli tem alguns cursos bem legais de especialização e extensão vejam no site www.pecepoli.com.br , temos a Iterasys com os cursos preparatórios para certificações, mesmo que vc não faça a prova, o curso acaba sendo muito legal e você consegue praticar algumas coisas no dia-a-dia.

Eu atualmente tento frequentar os eventos de teste como o Brateste, Conferencias – inclusive fui no TDC 2010 realizado em Agosto, WorkShops, estou sempre antenada nas novidades e visitando blogs relacioandos a Qualidade e Teste SW.

Por fim, termino agora em novembro o MBA em Teste de Software pela Unieuro, o curso é bom tirando algumas falhas da instuição em relação ao atendimento ADM e Financeiro… *rs

Eu achei super válidas as contribuições do Elias e da Lidiane, e retratam bem as formas que podemos nos especializar na área de Teste de Software.

Na minha opinião, a especialização hoje é encarada pelos profissionais, basicamente de duas formas:

  • O profissional gosta da área e quer se aprofundar melhor nela, ou está buscando cobrir lacunas da graduação e conhecer outras áreas (ex.: ao fazer uma pós em Engenharia de Software);
  • A outra forma, são os profissionais que estão buscando status e aumento. Afinal, é bunitinho falar que é pós-graduado e para algumas empresas, o título mostra que o profissional é mais qualificado que outro que não possui uma pós. Essa abordagem é perigosa, porque você pode acabar fazendo um curso que não gosta ou que o seu perfil não encaixea Além do que, essa visão de que ser pós-graduado é igual ser melhor do que os que não são, é uma visão alienada.

Eu particularmente, prefiro uma pós-graduação fora da área de Teste de Software, para quem está na área de Teste de Software. Caso o seu perfil seja mais gerencial, busque uma pós de gestão ou um MBA, agora caso o seu perfil seja mais técnico, busque então uma pós em Engenharia de Software.

Escolha bem o curso e não vá na “hype”, afinal uma pós-graduação, geralmente exige um investimento financeiro grande. Faça a sua escolha com bastante parcimônia. 😉

E lembrem-se: nem sempre se especializar, significa se matrícular num curso de pós-graduação, hoje em dia há outras opções.

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

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