O melhor da semana 02/05 a 08/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. :)

Abraços! E tenham uma ótima semana!

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

Receita do dia: Torta de bug

Momento Edu Guedes. Hoje vamos ver como preparar uma deliciosa torta de bug. A receita foi extraída do excelente capítulo No Bugs, do livro do James Shore “The Art of Agile Development”.

Para preparar a nossa torta de bug, primeiro iremos precisar de uma linguagem de programação desafiadora. Acredito que C pode ser uma boa. E iremos também dar uma pitada de Assembly.

Também precisamos adicionar alguns bugs misturando com programação concorrente. Afinal, os nossos velhos amigos segurança e disponibilidade estão felizes de lutarem um contra o outro para ver quem prover mais bugs. Eles até ajudaram os bugs da biblioteca multithread do Java por anos!

Agora vamos precisar de um problema de domínio bem difícil. Pode ser um sistema embarcado em tempo real.

Para cobertura desta receita de desastre, iremos precisar do tipo certo de programadores. Vamos ver… experts… acho que não, desenvolvedores sênior… também não! Juniores, ou melhor estagiários é o que precisamos.

Coloque os seus ingredientes: C, sistema embarcado em tempo real, multi-tarefas e não se esqueça dos estagiários e adicione um pouco de Assembly, bata bem e cozinhe por três anos.

Bom apetite, ou melhor, bons testes! ;)

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

Risk-based testing (RBT)

A 22ª Mesa Redonda DFTestes teve como tema “Risk-based testing (RBT)”. A discussão teve 3 respostas e participantes, sendo eles:  eu, Aderson Bastos e Robson Agapito.

A seguir, coloco a discussão na íntegra. ;)

Por que usar RBT?

O Aderson Bastos conseguiu responder a pergunta em uma frase:

No risk, no test… (Martin Pol) rs

Na minha opinião, RBT é uma abordagem muito útil para as equipes de teste e que pode ajudar na eficiência dos testes. Afinal, não podemos testar tudo, mas podemos testar o que tem maior risco de falhas.

É possível usar RBT sem ter um gerenciamento de riscos?

Segundo o Aderson Bastos:

Não, pois os riscos mudam e a ingerência destes comprometerá os testes.

Eu acredito que é possível sim, pois a própria equipe de testes poderá discutir quais áreas/funcionalidades da aplicações há maior risco. E é importante lembrar que umas das pessoas mais gabaritadas para realizar uma análise de risco é uma pessoa de teste. :)

Porém, acredito que o ideal seria que a análise de riscos seja feita junto com o planejamento da sprint/ciclo/projeto e que todos ou os cabeças chaves das equipes possam participar, pois assim, a análise poderá ser feita de forma melhor e todos estarão cientes dos riscos do produto.

Como devemos direcionar os testes usando RBT?

O Aderson Bastos lembrou muito bem da ISO 9126-1:

A ISO/IEC 9126-1 é uma ótima referência neste direcionamento.

Eu vejo que a ideia por trás do RBT é você testar a área que mais dói, portanto e lá que você concentrar os seus esforços iniciais, seja ela, uma funcionalidade com um algoritmo por trás, onde ouve mais mudanças, etc.

E uma vez identificada tal área, é sempre bom lembrar de Pareto, e então tentar descobri o mais cedo possível as falhas, seja usando automação, alocando o testador mais experiente, etc.

Quando utilizamos RBT precisamos focar onde o risco é maior, por isso da necessidade de fazer uma boa análise de riscos, pois senão, você poderá estressar uma área que não era tão importante assim.

Como foram as suas experiências com RBT?

O Aderson Bastos compartilhou as suas experiências dizendo:

É muito difícil usar RBT sem os riscos identificados e gerenciados! rs

Das poucas vezes que me deparei com cenário propício, a abordagem se mostrou bastante eficaz.

O Robson Agapito relatou uma pouco da sua experiência dizendo:

Aqui utilizamos algo parecido com a análise de risco… criamos um processo que não é uma análise de risco completa, mas adaptado ao nosso processo.

Todo requisito que vem para teste classificamos de duas maneiras, o impacto e a probabilidade. Mas falar somente impacto e probabilidade parece muito vago então focamos mais para a equipe de testes o que seria cada uma destas características.

O impacto não muda muito, seria o impacto da funcionalidade do requisito para o negócio que é visualizado para o cliente.

Já a probabilidade, contamos com a probabilidade desta funcionalidade conter defeitos (o risco de se identificar o defeito. Isso é algo específico aqui, pois temos Analistas de Testes experientes com relação ao sistema, isto é, conhecem muito sobre o negócio e o sistema que estão trabalhando. Então fica mais fácil de se identificar os pontos mais críticos para se ter um defeito. Mas nada que uma reunião com os analistas e desenvolvedores não nos faça identificar tal situação.

Com estas duas características identificadas, conseguimos definir a ordem dos testes.

Então temos a probabilidade e o impacto podendo ser classificado como :

1         – Muito Baixo

2         – Baixo

3         – Médio

4         – Alto

5         – Muito Alto

E utilizamos a seguinte ordem para os testes, sempre realizar os testes primeiramente dos requisitos com maior impacto, e para desempate utilizar a probabilidade de se identificar defeito começando pelo Muito Alto e indo até o Muito Baixo nas duas situações.

Com isso conseguimos priorizar, quando necessário, os testes a serem realizados primeiro.

É uma maneira simples e bem parecida (apenas uma pequena parte) da análise de risco.

As minhas foram muito boas! Como disse no começo, era é uma abordagem muito útil e ser usada com outras técnicas, como por exemplo, Teste Exploratório, pode garantir uma boa e eficiente cobertura de teste.

E ela pode direcionar tanto a execução dos testes como as outras atividades, e desta forma, podemos encontrar as falhas de forma mais rápida.

E o interessante do Teste Baseado em Riscos, é que ele pode trazer bons resultados independente da metodologia do projeto. E a sua aplicação faz o teste ser mais inteligente, principalmente pelo fato de estarmos testando com foco e sabendo o porquê.

Saiba Mais

Uma leitura recomendada sobre o assunto, é esse post da Sarah Pimentel.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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

Rapid Software Testing: Visão Geral

Publiquei um artigo sobre Rapid Software Testing no TestExpert. Segue abaixo, o link:

http://www.testexpert.com.br/?q=node/1741

No artigo eu apresento uma visão geral sobre o Rapid Software Testing (“Teste de Software Rápido”), que é uma metodologia bem interessante de Teste de Software, com características da Escola Direcionada pelo Contexto (Context-Driven School).

Aproveitando para avisar que desde do mês passado, estou participando do TestExpert como colunista. :D

Minha meta é de elaborar dois artigos por mês lá. Logo após a publicação deles, irei avisar aqui criando um post com o link e uma breve descrição do artigo (o primeiro artigo eu não divulguei aqui, pois era um conteúdo já conhecido por vocês leitores[as]).

De início eu não pretendo repetir conteúdo do QualidadeBR para o TestExpert, e vice-versa, pois ambos são conteúdos Creative Commons, portanto de acesso livre. ;)

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

O melhor da semana 25/04 a 01/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. :)

Abraços! E tenham uma ótima semana!

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

http://www.testexpert.com.br/?q=node/1740Nova comunidade que poderá revolucionar as ações sobre a divulgação de Testes: TESTADORES

Indicadores de teste

O tema da 21ª Mesa Redonda DFTestes foi “Indicadores de Teste”, que teve apenas 3 respostas (até o momento) e 3 participantes, sendo eles: eu, Leandro Mancuso e Robson Agapito.

Mesmo com o baixo número de respostas a discussão foi interessante, no que se diz respeito, a apresentação de alguns indicadores aplicados pelos profissionais. Abaixo, faço um “resumo” (quase a discussão na íntegra rs) da mesa redonda, quem quiser conferir a discussão na íntegra é só acessar o DFTestes (é necessário se inscrever).

Indicadores utilizados na prática

O Leandro Mancuso compartilhou os seguintes indicadores:

Todo final de mês eu tenho uma query que eu fiz que contabiliza todos os bugs relatados na ferramenta de bug tracking, e desses bugs eu subtraio quantos foram encontrados no ambiente de produção, com isso sei aonde a equipe de testes esta falhando e fazemos uma análise crítica do porque nos testes tais bugs não foram detectados.

Também utilizo as seguintes:
ERD = (TDR / TDD) *100
TDR = Total de defeitos removidos
TDD = Total de defeitos no testes

TDR = Total de Defeitos Removidos  (Total de defeitos menos os encontrados pelo Cliente.
TDD = Total de Defeitos Detectados pelo teste (Total de defeitos menos os encontrados pelo cliente mais os retornados para o Desenvolvimento.

O Robson Agapito, que até fez um excelente artigo sobre alguns indicadores que ele utiliza, compartilhou algumas informações sobre a EDD:

EDD (Eficácia de Detecção de Defeitos)

Nesta métrica podemos demonstrar a eficácia do produto com relação aos testes realizado pela equipe de testes. Claro esta métrica pode alternar de empresa para empresa, pois existem muitas variáveis que se divergem de uma empresa para outra. Então não basta conhecer apenas o resultado final, deve-se saber avaliar o resultado com o processo de liberação pré-definido pelas empresas.

EDD = TDD / (TDD+TDC) * 100

TDD = Total de Defeitos Detectados pelo teste
TDC = Total de Defeitos encontrados pelo Cliente

Ex.:
A equipe de testes tem um sistema para realização de testes e encontrou 40 erros no produto durante este processo. Após a liberação do Sistema os clientes encontraram mais 10 erros que não foram identificados pela equipe de testes interna. Assim possuímos os valores abaixo:

TDD = 40
TDC = 10

EDD = TDD / (TDD+TDC) * 100
EDD = 40 / (40+10)*100
EDD = 80%

Então o índice de EDD é igual a 80%, isto é, a qualidade da equipe em relação à detecção de defeitos é 80% eficaz. Mas volto a afirmar que em alguns casos estas situações podem ser interpretadas de maneira errônea se somente vermos os números resultantes. Deve ser avaliado todo o processo de liberação do software e não apenas o resultado.

Não utilizamos muitos indicadores de teste aqui na empresa, acho que mais por um motivo cultural e nos projetos que atuei, por nem sempre necessitar de indicadores. Nas poucas vezes que buscamos utilizar algum indicador, além dos que são armazenados nas ferramentas (TestLink e Eventum), foram indicadores mostrando a relação entre falhas encontradas X tempo, durante o desenvolvimento de cada versão (figura abaixo). E foi o que melhor foi utilizado, pois ajudava tanto a equipe de teste quando de desenvolvimento.

Quais são as variáveis que podemos observar para obter indicadores de teste?

Quando estamos em busca de indicadores, é interessante primeiro, saber de quais variáveis podemos tirar indicadores, abaixo segue algumas das variáveis que podemos observar:

  • Defeitos/Falhas encontrados;
  • Casos de testes;
  • Testes automatizados;
  • Funcionalidades.

Quando e qual a melhor forma de divulgar esses indicadores?

Ao longo de todo projeto, mas com o cuidado de também indicar o contexto, números por si só, são só números. E como o Robson disse, os indicadores devem ser avaliados olhando o nosso contexto, pois caso contrário, interpretações errôneas poderão acontecer e como um professor que tive costuma dizer “coisas horríveis irão acontecer”.

Por que os temas relacionados a estimativas são frequentes na nossa mesa redonda?

Essa eu gostaria de saber (rs), na minha opinião, vejo que as pessoas às vezes se preocupam muito com métricas, acham que coletando métricas irão ter um processo mais maduro, estarão sendo mais profissionais, etc. Na minha visão, as métricas podem te ajudar a enxergar tendências, mas há muitas coisas mais importantes que métricas, um exemplo são as pessoas.

Não me lembro de ter visto uma discussão sobre como motivar a equipe de Teste de Software, como montar uma equipe de sucesso, como construir um bom ambiente, etc.

Só quero deixar claro que não sou contra estimativas, só acho que elas são muito supervalorizadas por algumas pessoas. Como disse na mesa redonda “Estimativa de Testes (APT)”: Medir é apenas uma das forma de controlar, adoramos números, tanto que há as mais variadas estatísticas hoje em dia. Porém, não é uma tarefa tão simples, e nem sempre a mais importante para uma determinada realidade.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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

O melhor da semana 18/04 a 24/04

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. :)

Abraços! E tenham uma ótima semana!

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

Quem é o grande vilão do Teste de Software, o bug ou o tempo?

A 20ª Mesa Redonda DFTestes teve como tema “Quem é o grande vilão do Teste de Software, o bug ou o tempo?”. A discussão teve 9 respostas e participantes, sendo eles: eu, Sarah Pimentel, Luís Barros, Shmuel Gershon, Rodrigo Almeida, Felipe Silva, Elias Nogueira, Humberto Barboza e Talita de Oliveira.

Abaixo, faço um “resumo” de como foi a discussão, sempre lembrando que quem quiser ela na íntegra é só acessar esse link (é necessário se inscrever no DFTestes).

Quem é o grande vilão do Teste de Software, o bug ou o tempo?

Segundo a Sarah Pimentel:

Tanto o tempo quanto os bugs são vilões, quem está sendo pior depende do projeto, eu acho. Existe tanto aqueles sistemas onde nenhuma pratica de prevenção de defeitos foi aplicada e chegam com bugs críticos que bloqueiam e atrasam testes, quando os projetos nos quais a definição de requisitos atrasou, a arquitetura atrasou, o desenvolvimento atrasou mais ainda e o tempo do teste ficou reduzido a 25% do que era antes e claro que sempre esperam que a equipe de testes faça milagres porque só ela não pode atrasar.
Quanto aos bugs podemos atacá-los através de processos de prevenção de defeitos e quanto ao tempo, revisando o planejamento, implementando um processo de gerenciamento de mudanças e procurando alinhar a equipe de vendas (normalmente o tempo começa a ser um problema já na venda do projeto) o que realmente é possível entregar no tempo acordado.
Apesar do desejo intimo de ter a aplicação 100% testada, sabemos que isso é dito como impossível. Para isso, há algumas técnicas que nos ajudam a selecionar/priorizar testes para que possamos aproveitar nosso tempo da melhor maneira possível.

O Luís Barros deu a sua opinião dizendo:

Na minha opinião o TEMPO hoje é o grande vilão do teste de software.

O TEMPO compromete as verificações de documentação que, antes mesmo de ter uma aprovação formal já estão na mão dos desenvolvedores, pois o prazo já está apertado;
O TEMPO faz o desenvolvedor passar por cima dos testes unitários e de integração;
O TEMPO faz o prazo do time de teste ser reduzido. Aliás, a gente sofre muito com isso, pois o que é cortado primeiro de um projeto é sempre o teste;
O TEMPO faz um projeto ser “baseado em funcionalidade” (Funcionou tá bom!), onde só o “Caminho Feliz” importa.

E finalmente…
O TEMPO causa mais bugs pois, se tudo o que foi mencionado não acontecesse, certamente teríamos um software com muito menos bugs

Uma frase que já ouvi muito de caciques: “Não entregar tem um impacto muito maior do que entregar com erros!”

O Shmuel Gershon tem uma opinião diferente do pessoal:

Vilões? Ahn?

Primeiro, por que o bug seria um vilão? Se fosse um vilão, não ficaríamos tão feliz de achar um.
Acho que os bugs, longe de ser os vilões, são nossas bat-ferramentas, essenciais para sermos bons heróis. São eles que nos permitem aprender, e que nos permitem ensinar e transmitir informação adiante.

Segundo, por que o tempo? Tempo é o melhor amigo da qualidade de software. Se não tivessémos tempo suficiente, não ia dar pra fazer nada direito!
E a falta de tempo? Outro melhor amigo da qualidade, especialmente porque este fica do lado do cliente, defendendo seu valor — já pensou se ainda não tivéssemos recebido o Windows 97? não teria como avançar a tecnologia até chegar no Win7.

Bugs e Tempo, para ser vilões, só neste link e neste link. :)

O verdadeiro vilão dos testes, sou eu.
(não, não por que eu fico aqui contrariando todo mundo na DFTestes!)
Mas por que eu concordo com mas decisões, em vez de trabalhar com meus gerentes para tomar a decisão certa.
E porque eu não sou capaz de explicar toda a extensão do impacto de uma mudança no cronograma.
E porque as vezes uso métricas que em vez de ajudar, estão atrapalhando a operação.

É dura, esta vida de herói e vilão ao mesmo tempo…

Minha linha de pensamento sobre o assunto é bem parecida com a do Shmuel.

Todos são culpados! Até que se prove o contrário.

Em algumas organizações é muito fácil botar a culpa em fulano ou ciclano, principalmente, quando temos caciques (como lembrou o Luís), ou pessoas que gostam do poder, de tomar decisões sozinhas, etc.

Eu particularmente, vejo que o desenvolvimento de software é algo muito complexo, para um único ser humano levar a culpa. E por isso, sou a favor de quando algo de ruim acontece (“shit happens”), todos sentarem para buscar os fatores e a causa raiz para aquele problema ter ocorrido, deste modo todos evoluem e tem a oportunidade de discutir.

Nenhum dos dois são vilões, são apenas efeitos causados por seres humanos.

Porém, “o primeiro” bug, era sim um vilão, aquela traça maldita! rsrs

Hoje acredito que nenhuma falha acontece por causa de uma trasa, elas acontecem porque pessoas desenvolveram aquele sistema. E pessoas cometem erros, lembre-se errar é humano.

E como o Shmuel disse: “É dura, esta vida de herói e vilão ao mesmo tempo…”

O Rodrigo Almeida enfatizou a importância de termos um processo alinhado com a equipe de desenvolvimento, para podermos tornar o tempo o nosso amigo:

É preciso ter estratégia.

Estratégia para achar o bug nos testes críticos.

Tem que ter processo definido e alinhado com a equipe de desenvolvimento.

Desta forma o tempo vira aliado e não inimigo!

Segundo o Felipe Silva:

-  O tempo é um fator neutro, quem faz ele parecer mau ou bom é a “áurea espiritual da entidade responsável pela estimativa e cronograma”, se está estiver acima do “limite mortal humano” então o tempo leva a culpa mesmo sendo algo constante, caso contrário o tempo leva a culpa pelo desperdício de orçamento? Esta segunda resposta é única e exclusiva da “índole da(s) entidade(s) superior(es)”. Falando claramente tempo vilão = planejamento não reflete a realidade, isso também não quer dizer que o planejador é o culpado, a não ser que ele seja capaz de prever o futuro, mas ele é no mínimo cúmplice (rs).

- O bug pode ser um vilão, principalmente para nós responsáveis pela qualidade, mas é este também “paga meu salário todo mês”, estão se eu colocasse em uma balança ele é mais meu amigo do que meu inimigo, sobre o bug só posso dizer ele é mais previsível do que o tempo, embora não seja possível testar 100% do software é possível testar a parte mais usada e deixar o bug hibernando por tempo indeterminado, contanto que este não acorde ninguém vai reclamar.

Se for para pesar Tempo x Bug eu diria que o tempo tem maior peso, pois a falta deste primeiro ajuda o segundo ser um risco maior.

O Elias lembrou bem, que muitas vezes o grande vilão é a cultura da empresa:

O principal vilão do Teste de Software é a cultura!!!
Em um software de missão crítica ou relacionados (aviões, máquinas médicas, etc…) nem o tempo nem o bug serão um “vilão”, pois a cultura cultivada dentro de uma organização que desenvolve e testa um software dessa linha está preocupado com a qualidade.

O que nós enfrentamos no nosso dia-a-dia é prazos curtos e uma quantidade grande de bugs dado também a pressão colocada sobre a área de desenvolvimento para entregar ‘qualquer coisa’ de uma forma mais rápida.

Uma empresa que preza por uma cultura de qualidade dificilmente terá como o vilão o bug ou o tempo!

O Humberto Barboza deu a sua opinião dizendo:

Respondendo a pergunta e concordando com alguns, dentro do nosso paradigma de teste de software o tempo é o grande vilão.

Infelizmente para a nossa atividade nunca dispomos dele para realizar o trabalho ótimo. E na grande maioria das vezes somos obrigados a fazer o melhor trabalho que pode ser feito, priorizando as atividades, dentro do tempo que dispomos.

Claro que essa discussão como já pudemos perceber nessa mesa redonda envolve muitas variáveis: a cultura da organização passada hierarquicamente abaixo de que o teste pode ser cortado se não houver tempo, a pressão sobre a equipe de desenvolvimento que entrega o produto sem a qualidade esperada porque não realizou devidamente os testes unitários e de integração, a pouca importância dada a fase de planejamento dos testes e a adoção da estratégia “Sair fazendo” sem o devido planejamento, padrões engessados (inclusive estou sofrendo pra caramba com isso no momento, porque adotamos o Scrum, mas, com os padrões de documentos existentes hoje é inviável trabalhar e estou tendo que pensar no meio do sprint, por que não houve tempo antes rsrs, em como adaptar e gerar métricas no cenário atual visto que sequer utilizamos uma ferramenta de controle de defeitos).

Liderança desinteressada que deixa exclusivamente a cargo do QA todas decisões, por hora acho que é isso.

A Talita de Oliveira respondeu a pergunta dizendo:

Bom, pelos projetos que atuei, a maioria dos problemas em fase de teste foi o tempo, mas no meu ponto de vista uma coisa leva a outra, como disse o Humberto tem a ver com a cultura da empresa. Digo que uma coisa leva a outra pelo fato da pressa, como já diz o ditado que pressa é inimiga da perfeição, dificilmente um time de testes por mais competente que seja não conseguirá entregar um projeto com a % mínima de bugs se não houver tempo. E essa falta de tempo acontece porque a fase de testes na maioria dos projetos está no final, pelo menos é assim que tenho trabalhado…em fases finais.
E quanto a equipe de testes aceitar desafio, é normal, pois ao longo da minha experiência a pressão sempre foi alta porque ouvi sempre: “Vocês são a parte final do projeto” ou “Vocês que dirão se a aplicação está ok ou não”. Então..acho que não só a equipe de testes é culpada, mas todos os envolvidos tem sim sua parcela de culpa.

Por que gostamos tanto de terceirizar a culpa?

A Sarah Pimentel lembrou que é sempre mais fácil terceirizar a culpa:

Se eu assumo que a culpa é minha ou que eu tenho qualquer responsabilidade sobre o que está acontecendo, eu sou forçada fazer algo a respeito. Se eu jogo a culpa no outro, o problema é dele e ele que se vire pra resolver, não impacta no meu dia a dia. Fiz uma vez um treinamento de relações humanas e meu professor me disse algo óbvio: não podemos mudar os outros, a não ser que eles mesmos estejam procurando uma mudança. Então se há uma situação que você quer resolver, ao invés de esperar pelo outro, procure em você o que você pode fazer para mudar a situação e naturalmente (na maioria das vezes) o outro vai ser influenciado pela sua mudança de comportamento.

Na minha opinião é da natureza do ser humano culpar o próximo. A Dorothy Graham falou um pouco sobre isso no CInTeQ 2010, contando que irmãos mais velhos, gostam de colocar a culpa nos mais novos (eu mesmo fiz isso muitas vezes rsrs).

Quando crescemos aprendemos que podemos botar a culpa não são nas pessoas, mas também no processo, metodologia, ferramenta, bug, tempo, etc. E assim fazemos, quantas vezes você já ouviu falar que vários projetos falharam por causa que usavam o modelo Cascata. Mas quem escolheu usar o modelo Cascata? As pessoas não foi!?

Segundo o Humberto Barboza:

Infelizmente quase nunca fazemos um “Mea Culpa”. Concordando com o que foi dito já na lista, boa parte da culpa é nossa que por gostar de desafios ou situações desafiadoras, aceitamos irresponsavelmente trabalhar com tempo reduzido, padrões engessados, ausência de ferramentas adequadas e até liderança inoperante, infelizmente. Tecnicamente erramos por exemplo estimando mal nosso trabalho, priorizando atividades menos relevantes e cedendo às pressões do nosso meio. Precisamos defender o nosso trabalho e demonstrar a importância de ser bem planejado, projetado e executado e qual o impacto na qualidade do produto e as consequências que pode ter.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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

O melhor da semana 11/04 a 17/04

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. :)

Abraços! E tenham uma ótima semana!

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

Como contratar um profissional para a área de Teste?

O tema da 19ª Mesa Redonda DFTestes foi “Como contratar um profissional para a área de Teste?”. A discussão teve 18 respostas e 8 participantes, sendo eles: eu, Sarah Pimentel, Robson Agapito, Felipe Silva, Shmuel Gershon, Rodrigo Almeida de Oliveira, Milton Vopato e Aderson Bastos.

Segue abaixo, um “resumo” da discussão, quem quiser acessar a discussão na íntegra, basta clicar nesses links 1 e 2 (necessário se inscrever no DFTestes).

Qual o peso que uma certificação deve ter durante a seleção?

Para a Sarah Pimentel, ela terá um peso diferente dependendo da senioridade da vaga:

Pra mim, ela por si só não pode ser eliminadora. Quando falamos aqui em outra mesa redonda sobre certificações eu comentei que se assim fosse, receberíamos o currículo de James Bach em nossa mesa e jogaríamos fora.

Dependendo da senioridade procurada há mais uma maneira de encontrar a certificação. Para um cargo júnior que não pede muita experiência ou não pede experiência (ao menos deveria ser assim), uma certificação é muito importante porque dá certo conforto ao selecionador técnico de que aquele profissional poderá manter conversas com seus colegas sem dificuldade e já possui o entendimento ao menos dos conceitos básicos de teste. Outro indicador é que não é fácil passar em uma certificação de teste sem experiência na área. Pra mim esse candidato é pró-ativo (foi buscar qualificar-se para ter um diferencial), possui boa capacidade de aprendizado (com curso ou sem curso pra suportar a sua certificação, ainda assim ele não tinha o mais importante que era a experiência e conseguiu sacar as coisas), e é dedicado.

Já pra uma pessoa mais pleno/sênior, pra mim conta mais a qualidade das experiências que ele teve do que a certificação.

O Felipe Silva concorda com a forma utilizada pela Sarah:

Eu concordo com a Sarah que tem mais peso quando o cargo pretendido é para novos na área. Na minha opinião como recrutador eu consideraria uma certificação se está fosse obrigatória para o meu cliente.

concordo com a maneira que Sarah encarava as certificações no momento da seleção.

Ao entrevista um candidato que possui certificações é importante perguntar para eles questões do tipo:
  • Por que você buscou essa certificação?
  • O que você acha que foi importante para você ter obtido o certificado?
  • Quais conhecimentos adquiridos poderão ser colocados em prática no cargo que estamos te oferecendo?

O Shmuel Gershon deu a sua opinião dizendo:

Como a Sarah, acho que “ela por si só não pode ser eliminadora”. Mas com um ‘twist’, porque no meu caso prefiro candidatos sem ela. Mas imaginem se eu fosse descartar um candidato só por que ele mencionou ser certificado no currículo! Não seria justo, tem que conhecer a pessoa pessoalmente.
Claro, alguém com certificação provavelmente vai passar por um conjunto diferente de perguntas na entrevista, porque temos que entender o que ele procurou na certificação, e qual importância ele dá para o material. Se o candidato simplesmente fez a certificação por inércia (parte dos estudos na faculdade, ou o emprego passado mandou todo mundo fazer, etc) fica mais fácil, porque a certificação pode ser ignorada.
A Sarah comentou que a certificação da mais conforto aos selecionadores.
O problema começa então, com esses selecionadores, que em vez de procurar o melhor profissional para o cargo, estão procurando o próprio conforto… :). Quem foi que selecionou esses selecionadores? :)
E em relação a “conhecer a pessoa pessoalmente” — concordo de novo com a Sarah que entrevistas de empregos, mesmo se compridas e/ou numerosas, são um péssimo modo de conhecer as pessoas.
Fica sempre um risco, uma loteria — tanto para o contratante como para o contratado.
No processo da empresa do Rodrigo Almeida, as certificações tem um bom peso:
No nosso processo conta muito, pois atesta que o candidato conhece teoricamente o assunto, pelo menos. E aliado à experiência prática do candidato, conta pontos sim na fase decisória.

Quais as principais características que devem ser avaliadas no candidato?

A Sarah Pimentel respondeu dizendo:

Na entrevista, é preciso explorar o CHA do candidato. Calma, não é nada místico. :P CHA = Conhecimento, Habilidade e Atitude. Não adianta ter qualquer combinação de dois desses critérios, é preciso ter os 3 senão não funciona. Então as perguntas devem direcionar para respostas que indiquem situações vivenciadas pelo candidato em que ele demonstrou ter o conhecimento para resolver, a habilidade de resolver eficazmente e a atitude de resolver eficientemente. Ele também precisa ser crítico e saber avaliar se a mesma situação poderia ter sido resolvida de outra forma melhor.

Ele precisa ter:

- conhecimento técnico condizente com a senioridade esperada;

- habilidades pessoais (capacidade de resolver conflitos, boa comunicação escrita e verbal, boa capacidade analítica, vontade de aprender, valorizar o compartilhamento de conhecimento,…)

Segundo o Felipe Silva:

Comprometimento, boa comunicação, pró-atividade, facilidade de aprendizado, capacidade de resolução de conflitos (diversos) e ver se a pessoa tem CHA = Conhecimento, Habilidade e Atitude, como dito pela Sarah.

Na minha opinião tanto as características as pessoais e os conhecimentos específicos para o cargo oferecido. Ou seja, pode variar muito de acordo com o cargo fornecido e as necessidades do projeto.

É importante avaliar o quanto ele gosta e se interessa pela área, pois assim poderemos saber se o profissional realmente busca crescimento na área. Além é claro, que também avaliar a “sede” por conhecimento que o candidato possui, isso podemos ver até pelo currículo, vendo os cursos/certificações que ele fez, conhecimentos que possui, perguntar os últimos livros que leu, etc.

Eu vejo que uma das principais características que um profissional de TI precisar ter é buscar o aprendizado contínuo, afinal nunca sabemos tudo, e a cada dia surge novas tecnologias/ferramentas. E um profissional de TI se torna “obsoleto” muito rápido se não se manter atualizado.

O que vale mais na seleção, as características técnicas ou as pessoais?

Segundo a Sarah Pimentel:

Pergunta complicada, mas eu prefiro apostar nas características pessoais. Um problema comportamental é muito mais complexo de ser resolvido do que um déficit técnico.

O Felipe Silva disse que:

Para área de testes eu digo que as pessoais, talvez para as outras áreas também, mas para a de testes tenho certeza que pesa muito. Reforçando o que a Sarah disse, é mais fácil treinar uma pessoa para adquirir um conhecimento técnico do que mudar a pessoa.

As pessoais, e a razão, como já foi falada, é muito simples: é mais fácil a pessoa aprender algum conhecimento, do que mudar algum comportamento.
Sempre que possível, tente avaliar o que o candidato é, e não o que ele tem. Afinal, é melhor um profissional mediano, motivado e interessado, do que um expert que só reclama (essa frase é tradução de alguma que ouvi, mas não me lembro a fonte rs).
Para o Shmuel Gershon:
Pessoais.
A maior parte das características técnicas são fáceis de ser ensinadas.
Para o resto das características técnicas, uma pessoas com excelente características pessoais em geral da um jeito de resolver a lacuna.
O Milton Vopato comentou sobre a colocação feita pelo Shmuel, dizendo:
“Ao contratar um testador, temos que ver como ele complementa o time existente.” - Shmuel

Acho fundamental a colocação acima.

Outra coisa importante é analisar não somente a parte técnica e de idiomas. Hoje em dia, é muito importante fazer perguntas para avaliar a índole da pessoa a ser contratada.
O entrevistador também deve levar em consideração se a empresa vai treinar a pessoa para certa tarefa e se sim, é mais importante uma pessoa motivada e proativa do que uma pessoa que já fazia a tarefa de outra forma e tem resistência a mudança.

Quais conhecimentos são essências de acordo com o cargo fornecido?

A Sarah Pimentel disse:

Isso eu acho que varia de acordo com o contexto de cada contratação, mas falando do que eu considero o mínimo:

Testador: Conhecimentos básicos de sistemas computacionais, noções de engenharia de sw e de processo de teste.

Analista de teste: Conhecimentos maduros em engenharia de sw, processo de teste, boas noções de garantia da qualidade e habilidade de aplicação de algumas técnicas de analise de teste

Automatizador: Conhecimentos maduros em engenharia de sw, processo de teste, arquitetura de sistemas, técnicas de analise de teste e programação, boas noções de garantia da qualidade

Gerente de teste: Conhecimentos maduros em engenharia de sw, processo de teste, garantia da qualidade e gerenciamento de projetos.

Já o Felipe Silva elencou as seguintes características:

Testador: Perfil investigativo, excelente poder de observação e concentração, raciocínio lógico e conhecimentos em informática.

Analista de teste: Conhecimentos em criação e execução de casos de testes ou similares e aplicação de algumas técnicas de analise de teste.

Automatizador: Excelente raciocínio lógico e programação, interpretação de casos de testes, facilidade em encontrar soluções para novos problemas.

Os conhecimentos/características que acho essenciais para cada posição:

  • Testador: conhecer bem o processo e as atividades de Teste de Software, boa escrita, ter atenção e buscar o perfeccionismo em suas atividades, está sempre disposto a novos desafios e ser pró-ativo na busca do conhecimento.
  • Analista de Teste: dominar Teste de Software, utilizar os conhecimentos adquiridos e estar sempre buscando melhorar a área. Além de buscar a manter a melhor relação com desenvolvedores, DBAs, administradores de rede, etc.
  • Automatizador de Teste: dominar Teste de Software, estar antenado com as tecnologias e ferramentas que surgem e que podem auxiliar o seu dia-a-dia. Saber bem uma linguagem de programação, design patterns, refatoração, testes unitários e integrados, ferramentas de integração contínua, repositórios (ex.: svn, git, etc). E também dominar as ferramentas que utiliza no trabalho.
  • Arquiteto de Teste: expert em Teste de Software e ter uma boa visão do desenvolvimento de software como um todo. E interessante ele ter uma mistura dos conhecimentos de um Analista de Teste com um Automatizador de Teste.
  • Gerente de Teste: expert em Teste de Software, uma boa bagagem profissional, gerência de projetos, excelente relacionamento interpessoal, ter o “poder” de inspirar as pessoas e boa capacidade de negociação.
O Shmuel Gershon deu a sua resposta dizendo:
Parafraseando a pergunta, os conhecimentos essenciais são de acordo com o cargo fornecido.
Às vezes precisa saber idiomas. Às vezes não precisa saber usar computador.

Como foram as suas experiências na contratação de profissionais para a área de Teste de Software?

A Sarah Pimentel compartilhou uma pouca das suas experiências, dizendo:

Em uma empresa anterior eu fazia seleção técnica. Isso compreendia a elaboração de provas (inglês e técnica) e entrevistas que em parte eram realizadas em inglês também. O candidato fazia as provas, eu corrigia e depois tinha 30 minutos para entrevista-lo tecnicamente e tirar minhas dúvidas em relação ao currículo e ao teste do candidato. Isso quando por demanda muito alta a entrevista comportamental com a psicóloga não entrava nesses 30 minutos também. Passar mais tempo que isso era inviável, pois impactaria nas minhas atividades técnicas para o cliente. Eu era líder de equipe dentro da minha empresa, analista de testes para o cliente e fazia seleção de pessoal. É complicado. O que eu costumava pensar era “dado o nível de senioridade desse candidato, eu gostaria de tê-lo na minha equipe? Enquanto líder técnica, qual o trabalho que eu vou ter com esse profissional para adaptá-lo à realidade do nosso cliente?” Esse questionamento me ajudou várias vezes a tomar decisões de contratação ou não e me deixar mais tranqüila quanto às decisões que tomei.

O Felipe Silva fez um relato bem interessante sobre as suas experiências:

Falando de experiência em contratações gostaria de destacar que o melhor processo seletivo que já fiz (como recrutado) é o da empresa em que trabalho atualmente, o requisitos são mínimos, para um analista de testes por exemplo são: Criação e execução de casos de testes e inglês avançado (cliente americano).
Este foi o processo mais inteligente pelo qual já passei, lógico que a empresa não economiza entrevistas, eles fazem isso para que cheguem até eles o máximo de CVs que atendam aos requisitos mínimos obrigatórios, isso lhes assegura que não iram perder a chance de recrutar boas pessoas só porque não tem uma certificação e etc, -  James Bach não seria descartado nesta seleção – o processo seletivo de cada pessoa demora de 3 meses até mais de uma ano.
Isso porque são feitas várias entrevistas por telefone e presenciais durante o período, algumas até com participação do cliente e quando a pessoa não é aprovada em uma das fases finais ao invés da pessoas ser “descartada” eles iniciam o processo seletivo da pessoa em outro projeto e não desistem até que a pessoa seja contratada (isso porque nas fases iniciais é analisado o psicológico da pessoa).
O processo de seleção passa por várias pessoas: Especialista em línguas, RH, Gerente de pessoas, gerente de projeto, líder de teste, um futuro colega de trabalho e as vezes cliente, entre outros.
Eles dizem mais ou menos isto que a Sarah disse, não importa muito o que a pessoa tem, mas sim o que a pessoa é.
Os conhecimentos e habilidades requeridos para trabalhar na maioria dos projetos de lá só podem ser adquiridos lá dentro, desejável que a pessoa tenha experiência na área (maior peso) e se possível experiência no exterior, os detalhes serão descobertos através de entrevistas (O CV praticamente não é usado para nada, apenas para arquivar, pois eles não “acreditam” em CVs, eles acreditam nas entrevistas).

Posso destacar também o processo seletivo de outras duas empresas que passei que também gostei, que são Embraer e InMetrics, em ambas eu realizei uma prova online, na Embraer chamaram todos os classificados em uma sala para prova escrita e psicotécnico, depois entraram na sala a psicóloga e os 3 lideres que estavam precisando de pessoas, cada um iria escolher um, passaram várias dinâmicas individuais e em grupo e perguntas. Na InMetrics eu fiz as melhores provas de raciocino lógico e conhecimentos técnico que já fiz, excelentes exercícios, e passei por várias entrevistas também, no caso da InMetrics a vaga era para automatizador.

Conclusão: De acordo com a vaga (testador, analista de testes, automatizar, arquiteto, gerente, etc) é recomendável ou não uma prova técnica, e para todos os casos entrevistas valem x vezes mais do que um currículo, deve-se tomar cuidado para não pedir o que não precisa (requisitos obrigatórios), pedir o que se pode pagar (talvez contrate alguém, mas essa pessoa ficará pouco tempo na empresa) e não correr o risco de excluir da lista pessoas com ótimo potencial (já vi menores programando melhor do que outros com y certificados), certificados são apenas papel, se a certificação é importante então que seja avaliado novamente os conhecimentos da pessoa, não confie na prova aplicada pela instituição certificadora, mesmo porque é fácil esquecer aquilo que não se pratica no dia a dia.

Ainda não tive experiências. Mas algo que percebi das seleções (todas para estágio/testador na área) que o pessoal já fez aqui na empresa:

  • Não é fácil encontrar pessoas com perfil para a área de Teste de Software;
  • Como temos uma “política” de formação profissional, damos mais importância as características pessoais do que as técnicas, até porque, o conhecimento para exercer a função, geralmente, só pode ser obtido dentro da empresa;
  • Difícil encontrar profissionais com pelo menos uma base sobre Teste de Software.

O Shmuel compartilhou de forma bem geral as suas experiências:

Fica comprido para escrever aqui.
Mas já contratei desde Engenheiros de Software a pós-graduados em filosofia. “Tive” melhores testadores que eram engenheiros de programação, estudantes de eletrônica, e até um com formação em arqueologia.

O Rodrigo Almeida disse que um bom processo facilita o sucesso na seleção dos candidatos:

Por enquanto todas boas. O processo que temos nos auxilia muito a contratar a pessoa certa

O Aderson Bastos destacou a importância de saber o porquê que estamos contratando:

Quem contrata deve, no mínimo, saber o porquê da contratação… Há momentos onde se faz necessário contratar alguém para “dar um gás” em um projeto (ou seja, temporário!), neste caso o skill do candidato deverá ser direcionado pela necessidade do projeto. Em outros momentos, contratamos porque estamos crescendo e queremos aumentar o time, aí sim devemos exigir mais dos candidatos, mas sempre de acordo com o planejamento estratégico da empresa (se não pretendo investir em offshore, de nada adiantará um candidato com fluência em Inglês ou qualquer outro idioma…).

Não devemos, jamais, descartar de uma entrevista a parte ética, o caráter e a integração do candidato à equipe, pois basta uma maçã podre para perdermos todo o cesto!!!

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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