Quais ferramentas podem apoiar o Teste de Software?

A 24ª edição da Mesa Redonda DFTestes teve como tema “Quais ferramentas podem apoiar o Teste de Software?”. A discussão teve 14 respostas e 10 participantes, sendo eles: eu, Regiane Ribeiro, Rafael Silva, Rodrigo Almeida, Felipe Silva, Shmuel Gershon, Sarah Pimentel, Elias Nogueira, Ueslei Aquino e Humberto Barboza.

Abaixo faço um “resumo” da discussão, quem participa do grupo DFTestes pode acessar a discussão na íntegra, neste link.

Quais ferramentas podem apoiar o Teste de Software?

O Shmuel Gershon fez um comentário bem interessante:

A ferramenta mais útil em meu trabalho como testador é o quadro-branco (é, aquela lousa na parede mesmo, link).
Ferramentas são essenciais:
A menos que o testador tenha algum super poder de manipulação de bits e transistores com a forca da mente, ele vai precisar de um teclado, um mouse, um sistema operacional. Não dá pra testar sem ferramentas.
A pergunta é “quanto vamos deixar a ferramenta guiar o processo?”
E aí entram todas as ferramentas — as de geração de dados, as de controle de versão, as de gestão de testes — quanto nos deixamos a ferramenta decidir por nos?
Minha opinião é que se em algum momento você toma alguma ação por que é assim que a ferramenta faz, a ferramenta já está passando do seu limite. Ela trabalha pra você, não o inverso.

Segundo a Sarah Pimentel:

Qualquer uma que torne sua vida mais fácil, lembrando o que o Shmuel falou: A ferramenta trabalha pra você e não o inverso.

Eu concordo plenamente com o Luke Skywalker, que dizer Shmuel! 🙂

E acho que o ponto que ele  colocou, mostra bem um dos motivos pelos quais muitos profissionais ainda usam planilhas. Afinal, a planilha é totalmente customizada para a sua necessidade, você não tem que ficar preenchendo campos com blá-blá.

Quando optar pelo uso de uma ferramenta, ao invés, de um processo manual?

De acordo com a Sarah Pimentel:

– Quando o processo manual for difícil de manter/executar;
– Quando houver planejamento (tempo para aprender a ferramenta, tempo para verificar necessidades de adaptações na ferramenta e realizá-las…);
– Quando o processo de teste estiver maduro (mas ele pode amadurecer usando ferramentas também).

Para o Elias Nogueira precisamos ter o controle sobre o processo antes de buscar ferramentas:

Quando você já tem todo o controle sobre o processo e onde a aplicação dessa ferramenta não traga riscos ou grandes adaptações ao processo de teste

O Ueslei disse que:

Sabemos que em cada uma das fases do ciclo de vida, diversas são as atividades e técnicas a serem realizadas afim de gerar os produtos de cada uma das fases e, com toda certeza cada uma delas podem ser facilitadas com o uso de ferramentas. Mas, um fator que vejo de extrema importâncias é:

O profissional de teste precisa primeiro entender as técnicas de teste para então entender quais ferramentas devem ser usadas para cada técnica.

Como colocado pelo Elias Nogueira, eu reforço: O emprego de uma ferramenta errada na vez de ajudar se torna um grande risco para o projeto.

Então a melhor ferramenta é aquela que melhor atende ao processo de teste da organização e nem sempre, a ferramenta ideal para uma organização será ideal para outras. Com isso, um fator de importância é o estudo de viabilidades das ferramentas antes de sua aquisição e implantação de uma ferramenta na Organização. Esta prática pode eliminar o risco de, apenas no meio do projeto, descobrir que a ferramenta empregada não atende.

De acordo com o Humberto Barboza:

O uso de ferramentas sempre foi mesmo motivo de discussão na nossa área. Em relação a ferramentas de teste automatizado, alguns pontos devem ser questionados quando pensamos nisso. Por exemplo, uma ferramenta faz automaticamente tudo que fazemos manualmente, ou seja, ela não têm capacidade intelectual, então, o ganho de sua utilização está no tempo de execução. Porém, precisamos saber se fatores como: custo da ferramenta, prazo (Tempo de aprendizado), negócio do cliente, tipos de teste (Pra regressão é uma boa), serão adequados ao seu uso.

Em relação a outros tipos de ferramenta, considero algumas muito importantes no processo de teste. As de Gestão de Defeitos (Mantis, Trac), Gerência de Configuração (ClearCase, VSS) são bastante eficientes pois têm aprendizado e manutenção relativamente fáceis. E confesso que depois de algum tempo as utilizando ficamos dependentes das mesmas. Hoje mesmo, quero voltar a utilizar o Trac ou a HP Quality Center porque na empresa atual meu processo está todo manual com planilhas excel.

Adotamos o scrum e gostaria bastante de utilizar estas ferramentas, mas, hoje tenho um problema em que a equipe de desenvolvimento prefere o quadro afirmando que a visualização das tarefas e defeitos através dele são fundamentais para o sucesso da metodologia. Então, penso em como não ter retrabalho neste cenário, visto que neste caso teremos que incluir na ferramenta e também no quadro.

Quando o desenvolvimento de uma ferramenta internamente pode ser a melhor escolha?

A Sarah Pimentel respondeu dizendo:

Essa é uma análise que deve levar em conta:
.. atendimento às necessidades;
.. custo;
.. usabilidade;
.. tempo.

Segundo o Elias Nogueira:

Quase que jamais!!!!
Atualmente existem diversas, mas diversas ferramentas para a apoiar o processo de teste.
Já vi muitos casos que as empresas criam ferramentas de bug tracker, que é o mais comum, mas a alocação de um profissional e o tempo que a ferramenta leva para ser desenvolvida não justifica o custo de até comprar e customizar uma ferramenta…
Mas, quem sou eu pra dizer que a empresa X está errada em desenvolver uma ferramenta para o apoio aos testes.

Na verdade, creio que o único momento que podemos nos ‘dar ao luxo’ de desenvolver uma ferramenta internamente é referente a automação nos níveis unitários, de integração e de sistema. Já peguei projetos onde eu não conseguia nenhuma ferramenta e tive que criar uma arquitetura automatizada para testar um sistema de mensageira.

Só uma aviso aos novatos: muito se fala em utilizar e implantar o Mantis e Testlink para dar “velocidade” ao processo e ter um ponto centralizado. Mas iniciem conhecendo os conceitos dessas ferramentas (gestão de defeitos e gestão de testes), faça manualmente e depois implemente, se necessário, uma ferramenta.

A ferramenta que deve se adequar ao nosso processo, e não o contrário!

O Humberto respondeu a pergunta dizendo:

Penso que somente quando o negócio é muito específico e a adaptação à ferramenta inviável. Mas, quase sempre nesses casos vale mais a pena continuar com o processo manual.

Sobre o que o Elias disse, eu acho que é de se considerar a possibilidade. Principalmente, em se tratando de sistemas não web. (mas esse já é um tema de outra mesa redonda)

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.

Anúncios

Padronização de caso de teste. Pluralizado ou integrado?

A 23ª Mesa Redonda DFTestes foi sobre “Padronização de caso de teste. Pluralizado ou integrado?”. A discussão até o presente momento, teve 23 respostas e 8 participantes sendo eles: eu, Felipe Silva, Elias Nogueira, Edwagney Luz, Renata Eliza, Shmuel Gershon, Sarah Pimentel e Lucas Nadalete.

A mesa redonda começou bem fria, estava dando pinta que nem iria dar muita discussão, mas de repente, ela estourou. E vários comentários relacionados ao assuntos foram feitos, boas analogias e explicações foram feitas, mas até o momento não conseguimos saber o que é um caso de teste pluralizado e integrado. :s

A seguir, faço um resumo dessa excelente mesa redonda, que é altamente recomendável a sua leitura na íntegra, pois vários assuntos foram discutidos durante a mesa redonda, e como sempre faço o resumo focado no tema da discussão, alguns bons comentários sobre outros assuntos ficam de fora.

Padronização de caso de teste. Pluralizado ou integrado?

Até o momento desse post, ninguém conseguiu explicar o que seria um caso de teste pluralizado ou integrado. Tal terminologia, provavelmente deve ser bem específica, já que ninguém, tinha ouvido ela antes.

E falando em termos, o Edwagney fez um comentário bem pertinente:

Sinceramente, não vejo nenhum motivo para acrescentarmos mais conceitos como “Pluralizado ou Integrado”. Acho totalmente desnecessário!

Na minha opinião, realmente é desnecessário criar novos termos, principalmente, quando eles não são “auto explicativos”.

O Elias Nogueira fez uma interpretação que se não é a correta em relação aos termos é correta em se tratando de casos de teste:

Se eu interpretei bem o enunciado dessa mesa redonda, e seria interessante o outro desse tópico explicar, é a diferença entre o pluralizado e o integrado.
Pelo entendimento que tenho disso, creio que seria:

  • Pluralizado: Casos de teste distintos. Esses seriam como: Inserir Cliente com sucesso, Inserir Produto com sucesso, Emitir NF, Calcular impostos, etc… Logo um Caso de Teste no cenário: “cada um no seu quadrado”. Cada um executa uma ação específica para o que ele realmente é proposto
  • Integrado: Casos de Teste que “agrupam” todos os testes a fim de chegar a um objetivo comum. Seria como eu criar apenas um Caso de Teste para Emitir uma NF, sedo que tenho passos do cadastro do cliente, cadastro de produtos, calculo de impostos, etc…

Se for nessa linha de pensamento, e na minha linha purista, os Casos de Teste Pluralizados são os corretos, e não existe qualquer outra nomenclatura ou “agrupamento” de Casos de Teste. O que criamos quando temos uma linha parecida com o Integrado são Cenários de Teste.

Padronização de caso de teste. Detalhado ou resumido?

O Felipe Silva acabou sugerindo a questão “Padronização de caso de teste. Detalhado ou resumido?”, no lugar da questão tema da mesa redonda, por essa terminologia ser mais conhecida. A respeito da questão, o Felipe mesmo deu a sua opinião dizendo, subentendo que pluralizado seria um caso de teste mais resumido e o integrado um caso de teste detalhado:

Se eu entendi corretamente, pluralizado seria um caso teste escrito de forma genérica, que não contém detalhes específicos, e integrado seria aquele caso de teste com o máximo possível de step detalhados com toda informação específica, o famoso caso de testes “que até minha mãe conseguiria ler, executar e avaliar o resultado”.

Se for mesmo isso, prefiro o modelo básico (pluralizado), este é mais fácil de ser escrito e mantido, porém os detalhes que não estão escrito precisam estar na cabeça de quem executa, portanto exige que sejam executados por experts no projeto.

Já houve uma discussão sobre o tema no DFTestes.

Para mim, seguindo o entendimento do Felipe, a resposta para a pergunta depende do contexto em que se está testando. Como o Felipe disse, o genérico/pluralizado exige que o testador tenha domínio sobre as regras de negócio e a aplicação. Já o detalhado/integrado não exige um domínio sobre as regras de negócio e a aplicação por parte do testador.

Outros pontos interessantes, é em questão da manutenibilidade, estabilidade e velocidade. O caso de teste genérico/pluralizado tem maior manutenibilidade e estabilidade, pois como ele é mais a nível do que fazer e não como fazer, acaba sendo mais curto, portanto mais fácil de manter, e é menos “quebrável”, já que não entrar em detalhes de implementação (ex.: nome do campos). Já em questão de velocidade, mais uma vez o teste genérico/pluralizado leva vantagem, pelo mesmo motivo de que ele é mais fácil de manter.

Resumindo, se você é quem especifica os casos de testes e testa, ou você é um testador já experiente, então o mais indicado pode ser o caso de teste genérico/pluralizado. Agora se quem irá executar os testes não tem pleno conhecimentos das regras de negócio e da aplicação, ou ainda, os testes podem ser reutilizados num futuro (exemplo manutenções no software), o mais indicado pode ser o caso de teste detalhado/integrado.

O Elias Nogueira acredita que um bom caso de teste precisa ser detalhado, segundo ele:

Quanto a isso, ainda sou meio “purista” e creio que um bom Caso de Teste precisa ser detalhado. Precisa sim conter os passos como condições de uso e ser muito bem estruturado.

Existem sim várias formas de criar os Casos de Teste no Test Design, sendo o mais usual a de Heumman para criar os Casos de Teste a partir dos Casos de Uso.

O que define o grau de detalhamento são os tipos de teste para qual o(s) Caso(s) de Teste estão sendo escritos.
Quando vou escrever um Caso de Teste em nível Unitário, obviamente ele será diferente do de Sistema que estamos acostumados a criar. Escrever um Caso de Teste para algum cenário de Performance também é diferente de um Caso de Teste Aceitação.
Os Casos de Teste podem ter a entrada do seu processo os seguintes fatores:

  • Requisitos de Negócio
  • Interface com o Usuário
  • Domínio de entradas

Com o detalhamento, a equipe vai saber de regras que nem o Analista de Requisitos/Sistema saberá mais depois de 1 semana… e pra onde vai o conhecimento dessas regras?
Outro ponto também é que com um Caso de Teste detalhado, qualquer um na tua equipe, ou qualquer um que entrar na equipe, poderá ter um conhecimento maior da aplicação na execução destes Casos de Teste.

Claro que, em nossa realidade isso muda constantemente. Eu trabalho hoje num “Fábrica”, e sou obrigado a escrever Casos de Teste detalhados para os Testadores, que as vezes nem conheço. Se eu não fizer isso, posso deixar aspectos importantes passar não pelo pouco detalhamento do Caso de Teste, e sim da interpretação do Testador.

Já na realidade de quem não trabalha em uma Fábrica, creio que o nível de detalhe não é alto pelo alto conhecimento da aplicação que estes profissionais já tem.

A respeito da opinião do Elias, eu não acho que seja uma questão de qual é o melhor detalhado ou genérico/resumido. Ambos tem os seus pontos positivos e negativos. O importante é que o profissional de teste saiba da existência dos dois, pois é ele quem irá decidir por optar um ou outro.

A Renata Eliza deu a sua explicação sobre o caso de teste Step by Step (o famoso passo a passo), que seria o detalhado e o cenário de teste, que seria o mais resumido:

Acredito que as distinções dos Casos de Teste teriam mais sentido se fossem do tipo:
Casos de Teste Step by Step: quando o objetivo é cercar, através de casos de teste detalhados todas as possibilidades de um determinado documento da especificação. Como por exemplo, o Caso de Uso.
Cenários de Teste: que dá uma ideia mais generalizada do que deve ser testado naquele determinado cenário. Mais voltado para profissionais experientes, que têm a visão do que realmente precisam fazer.

O Edwagney falou sobre caso de teste detalhado, fazendo importantes considerações que nos podem levar a escolher ele:

Também não acho interessante que sejam elaborados apenas casos de teste detalhados. Isso depende muito da empresa que está usando o processo e como ela deseja documentar isso. Para uma empresa que existe grande rotatividade de profissionais, talvez seja interessante um maior nível de detalhe, entretanto, outra que tem uma política de manter seu grupo e treinar novos profissionais, o detalhamento fará um efeito contrário. Ao invés de ajudar, vai atrapalhar, pois o grupo é coeso e experiente, e não necessita de um alto nível de detalhamento para que o caso seja executado com qualidade e dê o resultado que se espera. Digo isso porque já trabalhei com esses dois tipos de empresas.

Nas consultorias que faço e nas empresas que eu trabalhei com isso, quando elegemos um caso de teste passivo de automatização, onde chegamos a um nível de detalhamento que seja possível sua automatização. Para os que não é possível a automatização, o nível de detalhamento segue sempre o bom senso e a forma de trabalhar da empresa

Coloco também uma outra variável para incrementar a questão, depende também do ramo de atuação da empresa. Se ela for especialista demais e seus profissionais idem, ao detalharmos os casos demais, ninguém usa e o processo cai todo por água abaixo. Um exemplo muito bom é a área de Telecom. É uma área tão específica e tão especialista, que para uma pessoa conseguir executar um tipo de teste, tem que ter uma série de requisitos básicos, que se formos colocar todas essas informações em um caso de teste, seria gasto tanto tempo que se tornaria inviável. E quando a pessoa já está devidamente treinada, ela não usa os casos detalhados, pois eles, ao invés de ajudar, travam a produtividade. Isso em caso de teste manual.

O Edwagney ainda deu uma excelente e bem didática explicação sobre a “cadeia”  dos casos de testes:

Faço a comparação com uma peça teatral, onde o nome da peça, seria a suíte de testes; os cenários, naturalmente os cenários do teste; as cenas, os casos de teste; e os atos dos atores a sequencia de execução cada cena ou caso de teste.

A Sarah Pimentel deu a sua opinião sobre a questão dizendo:

Entre um caso com mais detalhes e outros com menos, pra mim a resposta é como a da maioria das mesas redondas que temos: depende 😛
Se temos um caso de teste detalhado demais, e temos a política de capturar telas que comprovam a execução de cada passo, começa a ser um trabalho enfadonho, especialmente os testes de regressão que executamos inúmeras vezes.
Se temos um caso de teste genérico demais, corremos o risco de o testador não entender bem o step ou não verificar todos os pontos que o autor imaginou que ele verificaria.
Pra mim, assim como um documento de requisitos, o caso de testes está bom quando especifica tudo e não deixa brechas para interpretações. Se algo precisa ser verificado, deve estar explicitamente detalhado em algum passo. Se algo não precisa de tanta atenção (pode ser o caso de alinhamento de labels, nomes de campos que mudaram para outros similares, cores, posicionamento de objetos)… Não precisa estar descrito. Não que esses itens não devam ser testados, mas tem aplicações nas quais isso é um fator importante e outras em que não. Então depende do teu objetivo.
Para casos de teste que exigem uma busca um pouco mais complexa de dados, por exemplo, bastaria eu dizer que eu preciso de “um contrato de manutenção de hardware válido para atendimento físico com SLA de 48h” ou eu colocaria na pré-condição uma query que trouxesse esses tipos de contrato para o testador? Pouparia bastante tempo se ela já estivesse lá. E essa é uma decisão, pra mim, similar a de cima. Se vamos ganhar tempo e acuracidade, opto por detalhar. Se vamos burocratizar e onerar a manutenção e a execução, opto por generalizar.
O Lucas deu a sua opinião contando um pouco da sua experiência:
Na empresa onde trabalho temos situações onde as especificações dos Casos de Teste tendem a ser mais detalhadas quando dispomos de um prazo aceitável, escopo e especificação de Caso de Uso bem definidos e o profissional responsável por automatizar ou executar manualmente os testes não possui muita experiência a respeito do ambiente e negócio; já por outro lado, também nos deparamos com situações onde os Casos de Teste tendem a ser definidos de uma forma bem mais genérica, sem muitos detalhes (step-by-step), com uma descrição mínima do Caso de Teste, das entradas e das saídas esperadas. Este segundo ocorre principalmente quando há um cronograma bem mais enxuto que o esperado e o testador é alguém que conhece muito bem as regras de negócio do produto/projeto alvo.Em outras palavras, a forma como os Casos de Teste são especificados, varia e bastante. Sou extremamente a favor de se trabalhar com Casos de Teste Padronizados, mas se analisarmos com calma nem sempre as variáveis envolvidas são favoráveis, tais como: cronograma, artefatos (especificação de caso de uso, requisitos, …), ambiente, experiência do testador (técnica e negócio), automatizado/manual, enfim; e por serem elementos variáveis, os mesmos tendem a impactar na forma como os Casos de Teste são definidos, quando realmente são definidos.

Como exemplo, quando o testador tem pleno conhecimento do contexto de negócio, e o script de teste tende a ser automatizado, os Casos de Teste aqui na empresa são especificados genericamente, e o detalhamento (step-by-step) do teste fica por conta do script. Apesar de não ser a melhor prática, principalmente do ponto de vista de manutenibilidade, isso nos possibilita trabalhar a especificação dos Casos de Teste, automatização dos scripts, execução dos testes e gestão de defeitos, dentro do prazo esperado para as entregas/implantações.

Cuidado com o que você chama de caso de teste

O Elias fez um comentário bem pertinente sobre o que chamamos de caso de teste:

Uma outra coisa que não posso deixar de comentar: os que até hoje tratam em alguns lugares o Caso de Teste como sendo um passo. Aquelas planilhas em Excel gigantes, onde um profissional fala que tem 5.000 Casos de Teste, que na verdade são passos.
Isso pra mim é a pior coisa que um profissional pode fazer, além das empresas que vendem a atividade de criação de Casos de Teste por quantidade.

Sobre o assunto, o Lucas fez o seguinte comentário:

A respeito das famosas planilhas Excel, é extremamente importante não confundir um “caso de teste” por mais genérico que seja, com uma linha em uma planilha eletrônica que na realidade representa um simples “passo”. Já me deparei com situações onde a própria equipe de desenvolvimento gera uma planilha dessas com os testes executados por eles mesmos, e ao realizarem a entrega repassam o artefato como quem diz: “aqui estão as entregas e estes são os testes executados, só refazer”, ou seja, totalmente sem fundamento. Diante de uma simples “verificação” é possível evidenciar vários fluxos (alternativos ou de exceção) que não foram contemplados, bem como validações efetuadas incorretamente.

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.

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.

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. 😛 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.

Teste de Software: Desafios do Início

Há muitas dificuldades para quem está começando na área de Teste de Software, mas sempre precisamos encarar as dificuldades, como desafios que estão lá para serem superados.

Um pouco de história…

Lembro que quando comecei a atuar na área de Teste de Software, aliás, foi meu primeiro emprego na área de TI, mal sabia o que era Teste de Software. E o interessante que ninguém na empresa sabia muito bem o que era Teste de Software, pois eu e mais dois estagiários entramos na área, justamente para iniciá-la.

Após, quase três anos na área, percebi que a situação ocorrida comigo, não era tão incomum como eu pensava na época. Muitos profissionais entram ou mudam para a área de Teste de Software, justamente para iniciá-la, e alguns até formam uma “euquipe”.

Bem, já podemos levantar alguns desafios que podemos enfrentar:

  • Falta da cultura de testes na empresa;
  • Sobrecarga de papéis.

Formação acadêmica

Não faz tanto tempo assim que me formei, foi em dezembro de 2008, e hoje fazendo um levantamento do que eu aprendi na faculdade e que aplico no meu dia-a-dia, vejo que o papel da faculdade foi muito mais em pró de formar uma base de conhecimentos, do que me prover conhecimentos que poderiam ser diretamente aplicados no dia-a-dia.

Sei que formação acadêmica é um assunto polêmico na área de TI, mas no meu caso,  a faculdade foi fundamental para a minha formação profissional, principalmente, por não ter me dado o peixe, e sim ter me ensinado a pescar. E aproveitando para fazer uma metáfora: o mar da área de TI é abundante de informações, portanto, considero fundamental saber pescar (falarei mais sobre isso num post futuro). 😉

Agora voltando a temática do post, afinal tenho uma “extensa” lista de conhecimentos de Teste de Software que aprendi na faculdade:

  • O que é teste de Caixa-Preta e Caixa-Branca.

E aqui levanto mais um desafio:

  • Se sobressair mesmo com uma formação acadêmica fraca em Teste de Software.

Fontes de conhecimento sobre Teste de Software

Perto de quando comecei na área, hoje está MUITO mais fácil obter conhecimento sobre Teste de Software na Internet. Para ter uma ideia, hoje contei 78 feeds de blogs/sites sobre Teste de Software, que assino via Google Reader. Lembro que quando iniciei na área, as minhas duas fontes principais fontes eram: os artigos do Cristiano Caetano e  os do Alexandre Bartie (essa série sobre “Processo de Teste de Software” eu li várias vezes rs).

Já em matéria de artigos/dissertações/teses acadêmicos, hoje já conseguimos encontrar bons materiais sobre Teste de Software, mas ainda não são tantos assim, e esses você realmente tem que pesquisar nas bibliotecas digitais das universidades ou entrar em contato com  os autores.

Agora falando em livros, ainda estamos MUITO longe da qualidade e quantidade dos livros escritos lá fora. E não tem como, essa é a primeira comparação que fazemos ao pensar em livros para a área de TI. Mas para quem está começando há boas literaturas, como por exemplo, o Base de Conhecimento em Teste de Software.

Outra fonte de conhecimento muito boa para quem está começando são cursos, tanto de formação, como os específicos para certificações, conseguem dá uma boa base sobre Teste de Software para o profissional. Porém, muitos deles tem um custo bem elevado, se formos considerar que quem irá pagar será o próprio profissional que exerce um cargo de estágio ou junior.

Aqui levanto outro desafio, que está associado ao anterior:

  • Obter conhecimento sobre Teste de Software.

Visão das outras áreas em relação ao Teste de Software

No início, principalmente, quando a área é recente, uma grande mudança ocorre quando todos tem uma visão sensata e reconhecem a importância dos testes. Já quando, a área já é matura e nós que somos os completos novatos, precisamos de um certo tempo para realmente ligar todos os conhecimentos adquiridos e entender a real importância dos testes, e isso é algo que cada um tem que perceber sozinho, não adianta eu falar para você, pois você que precisa descobrir o quanto o seu trabalho é importante.

É muito difícil encontrar uma empresa que tenha a cultura de testes enraizada, hoje não tanto, devido ao boom das metodologias ágeis. Mas mesmo assim, muitos de nós precisamos estar sempre justificando as necessidades de testes para a funcionalidade X, porque precisamos de mais uma semana, explicar que teste de software não é desperdício é investimento, etc.

E aqui levanto um último desafio (há muitos outros!):

  • Entender e deixar claro a importância do Teste de Software.

Bem, o post foi mais para levantar alguns dos desafios que costumamos enfrentar no início da carreira na área de Teste de Software, em próximos irei falar mais sobre cada um dos cinco desafios levantados aqui. Até mais! 😀

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

Fonte Imagens:

Multi-task (autor ryantron) – http://bit.ly/a2Mwz6

Cartoon Tester – Andy Glover  – http://bit.ly/aK7hpB

Software Testing for Dummies – http://bit.ly/bpgFQ0

Challenge (autor HawkeyePilot) – http://bit.ly/aNL1AB

Wallpaper – In God we trust, everything else we test

Essa é uma das frases célebres da nossa área. Ela traduz bem o espírito que o testador deve ter. E falando em tradução, essa frase em português ficaria: Em Deus nós confiamos, todo o resto nós testamos.

Fiz um wallpaper com essa frase e estou compartilhando com vocês. 😉 (afinal, a nossa área carece de wallpapers rsrs)

Abaixo há vários links com diferentes resoluções do wallpaper e com a frase tanto em inglês, quanto em português. Espero que gostem. 🙂

Wallpaper em inglês (resolução 1024X768)
Wallpaper em português (resolução 1024X768)
Wallpaper em inglês (resolução 1200X800)
Wallpaper em português (resolução 1200X800)
Wallpaper em inglês (resolução 1366X768)
Wallpaper em português (resolução 1366X768)

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

Analista de Teste

O Camilo Ribeiro, autor do excelente The Bug Bang Theory e como o Elias Nogueira definiu bem “uma das poucas pessoas que conheço na área de Teste que conhece muito bem o lado da qualidade e o lado técnico, tornando-se assim um profissional completo”, está elaborando um artigo sobre os papéis relacionados a qualidade em uma fábrica de software.

E dentre as etapas da elaboração do artigo, ele está colhendo depoimentos de profissionais atuantes e representativos em cada papel. E eu fui honrado com o convite do Camilo para falar sobre o papel de Analista de Teste. 😀

A seguir, compartilho com vocês o artigo que enviei para o Camilo, que fala sobre o papel de Analista de Teste e conta um pouco do dia-a-dia desse profissional, que é fundamental para uma área de Teste de Software.

O que é?

É um profissional da área de Teste de Software, cujo principal objetivo é realizar a análise do sistema, do ponto de vista dos testes, a fim de modelar e elaborar os casos de testes.

Essa breve descrição do objetivo do Analista de Teste pode dá a falsa impressão de que esse papel é simples, porém veremos ao longo do artigo que exercer essa função não é tão simples assim e que são necessários diversos conhecimentos para pode exercê-la.

O que ele faz?

De acordo com o RUP[1] Rational Unified Process (ou Processo Unificado da Rational) o Analista de Teste é responsável por:

  • Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste
  • Definir os testes apropriados necessários e quaisquer Dados de Teste associados
  • Coletar e gerenciar os Dados de Teste
  • Avaliar o resultado de cada ciclo de teste

Continuando com a referência do RUP, encontramos as habilidades que são necessárias para exercer esse papel:

  • Boa habilidade analítica;
  • Uma mente desafiadora e curiosa;
  • Atenção aos detalhes e tenacidade;
  • Entendimento de falhas de software comuns;
  • Conhecimento do domínio (muito desejável);
  • Conhecimento do sistema ou aplicativo em teste (muito desejável);
  • Experiência em vários esforços de teste (desejável).

É difícil destacar uma das habilidades citadas, pois todas são destaques e importantes para se tornar um bom Analista de Teste.

Além das habilidades e conhecimentos apresentados outros conhecimentos técnicos são importantes:

  • Conhecer as técnicas de modelagem de testes: baseada em especificação, estrutura e experiência;
  • Conhecimento sobre todo o processo de Teste de Software;
  • UML;
  • Modelos;
  • Normas (com destaque para IEEE 829);
  • Banco de dados;
  • Ferramentas de teste.

Como chego lá?

Assim como para atuar em outros papéis na área de Teste de Software, o comum é atuar primeiro como testador, que é uma excelente oportunidade de conhecer a área, o sistema, o processo e adquirir os conhecimentos necessários para se tornar um Analista de Teste.

Podemos perceber pelas habilidades citadas no RUP, que exercendo a função de Testador, acaba se tornando um processo natural a evolução para Analista de Teste, uma vez que todas as habilidades citadas costumam ser adquiridas, durante a experiência como Testador.

Além da experiência, uma outra forma que pode ser combinada à experiência como Testador é a obtenção de certificações de Teste de Software, pois durante os estudos é possível adquirir muitos conhecimentos que não são vistos no trabalho, e assim poderemos ampliar a nossa visão sobre a área de Teste de Software e ter um leque de conhecimentos que poderão ser colocados em prática no nosso trabalho.

Na prática

O dia-a-dia de um Analista de Teste pode variar muito de acordo com a empresa na qual ele trabalha. Por exemplo, em empresas com uma área de Teste de Software grande e bem definida, a sua atuação costuma está dentro das atividades exercidas pelo seu papel, já em empresas com uma área de Teste de Software pequena ou recente, é comum a atribuição de atividades de outros papéis para o Analista de Teste, como: preparação do ambiente de teste, automatização de testes, etc.

O Analista de Teste é um profissional que precisa está sempre em contato com outras áreas, é natural sentar ao lado do desenvolvedor para entender melhor certa funcionalidade, conversar com o Arquiteto sobre a testabilidade da arquitetura, se reunir com o gerente do projeto/gerente de teste para priorizar os testes. Por isso é necessário o profissional manter uma postura ética, amistosa e de compromisso com os demais profissionais, pois eles precisam te enxergar como alguém que está lá para ajudá-los e não, como alguém que irá apenas criticar o trabalho deles.

[1] Rational Unified Process

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