Arquivo da tag: testador

Automação de testes: Aproximando contextos

A área de Teste evoluiu muito desde quando eu iniciei nela, em 2007. Hoje mesmo não atuando nela, eu vejo o quanto é diferente a forma de se testar, de quando eu comecei na área.

Naquela época automação de testes era um assunto ainda muito pouco difundido e as ferramentas usadas pagas, de grandes suítes de teste como a Rational.

Hoje em 2013 o cenário muito bastante, práticas ágeis estão mais difundidas, a comunidade brasileira está mais madura e ferramentas open sources dão todo o “ferramentário” necessário para a automação.

Para chegarmos no estado de hoje, várias mudanças e revoluções ocorreram. E como toda revolução, ela promete algo muito melhor ao status quo e para se prevalecer, muitas vezes ela se apoia em dizer que tudo está errado.

A automação de testes surgiu como um “lobo mau” para muitos Testers e outros se agarram a ela, como se ela fosse o único caminho de se testar. Com o tempo perceberam que ela nada mais é do que uma evolução. Ela não veio pra expurgar testes manuais, ela veio pra trazer maior eficiência aos testes e evitar o “caos” das manutenções de software.

Um dos efeitos colaterais da automação de teste, foi a aproximação da área de Teste com a área de Desenvolvimento. Ela ocorreu fisicamente com os Testadores sentando mais próximos dos Desenvolvedores, pra facilitar a comunicação quando é preciso tirar dúvidas sobre programação.

Mas ela ocorreu mais ainda na formação do Tester, no próprio DNA do Tester, uma vez que programar não é mais uma arte usada apenas para construir, ela também é usada para “quebrar ” (testes de carga usando JMeter), pra verificar (testes de aceitação usando Jasmine) e pra dá segurança para mudar (testes unitários com RSpec).

Com isso dois contextos que de forma errada muitas vezes eram separados, hoje estão mais próximos. Afinal, Desenvolvimento e testes sempre existiram pelo mesmo propósito, entregar software de qualidade.

Com a dinâmica atual do mercado de TI, não há mais espaço pra guerrinhas setorias, nem para Desenvolvedores que só cospem código, e nem pra Testadores que só navegam por telinhas. Não é mais questão de ser generalista, é questão que saber analisar um problema é tão básico para um Desenvolvedor, como programar é para o Testador.

Por que Testador é uma profissão tão desejada?

Na era da informação em que vivemos, uma das profissões mais cobiçadas é a de Testador. Ops, ela não é? Sério?

Infelizmente a profissão de Testador não é tão bem vista fora da área de Teste de Software. Mas não é para menos neh? A começar pelo nome: quando alguém pergunta a sua profissão, você fala Analista de Teste não é? No máximo, você fala que é um Tester, mas nunca Testador.

Uma pena que as pessoas tenham uma visão errada da profissão de Testador, afinal, para muitos ela é uma função que se resumi em executar tarefas repetitivas.

Tolos, mal sabem as maravilhas e exigências dessa profissão.

Estou falando sério, você não irá encontrar nenhum bazinga nós próximos parágrafos. Irei percorrer pelas maravilhas e exigências dessa profissão que deveria ser muito mais valorizada.

O Testador é um ser bipolar por natureza, ele vive num território onde se exige que ele tenha tanto a visão de um usuário, como a de um desenvolvedor. Digamos que ele está no meio do fogo cruzado entre os desenvolvedores e os usuários do sistema.

Ao longo de sua carreira essa bipolaridade, vai se transformando em multipolaridade. Pois o profissional percebe, que há vários tipos de usuários que podem usar o sistema, e portanto ele deve se colocar no papel de cada perfil de usuário.

Logo se nota que para ser um Testador é preciso de um grande talento e vocação para a arte cênica, a diferença é que o Testador pode ser o roteirista, o diretor e o ator ao mesmo tempo.

Em algumas cenas o Testador necessita de dublês e às vezes até um exército de figurantes.

E para poder receber o Oscar, o Testador necessita de criatividade, e até Tarantino ficaria sem entender o fluxo do filme do Testador.

O Testador não só salva a mocinha no final, como captura o bandido e tudo isso no menor números de passos possíveis.

Outra característica do Testador é seu faro e capacidade de exploração. Nem Indiana Jones poderia encontrar o bug perdido, apenas o Testador. Ele consegue ir por caminhos, que até os desenvolvedores duvidam, vasculhar os cantos obscuros da galáxia e estar sempre atento ao detalhes.

O Testador nunca está num dia de fúria, pois a calma e paciência fazem parte do seu arsenal.

Essa profissão em muitos momentos exige o entendimento do ser humano, e por isso não é difícil encontrar o Testador fazendo papel de psicólogo ao explicar uma falha ao desenvolvedor ou ao contar que uma falha grave foi encontrado às vésperas do sistema entrar em produção.

Suas qualidades na exploração também são usadas na pesquisa, pois o seu trabalho exige muitas pesquisas e ele está sempre aprendendo técnicas e ferramentas novas.

Investigações fazem parte da rotina desse profissional, que necessita colher o maior número de evidências para descobrir como a falha ocorreu, muitas dessas são dignas de casos do CSI e nem Dr. House conseguiria encontrar o que está causando a doença no sistema.

Tentar sintetizar o que esse profissional faz é uma missão difícil, mas podemos dizer, que o seu trabalho resumi em obter informações. Porém, assim como Clark Kent ele é também capaz de salvar o dia. (infelizmente o Testador não voa)

Sendo o Teste de Software um processo infinito de comparar o invísivel com o ambíguo, a fim de evitar que o impensável ocorra para o anônimo[1], tal profissional realmente necessita ser um super-heroí.

Porém, diferente da maioria dos super-heroís, a sua identidade não pode ficar anônima e ele não deve salvar o mundo sozinho. Precisamos valorizar o Testador, pois ele é capaz de evitar verdadeiras tragédias.

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

[1] Tradução livre de uma das definições (a mais precisa na minha opinião) do Teste de Software, feita pelo James Bach. (“Testing is the INFINITE PROCESS of comparing the INVISIBLE to the AMBIGUOUS so as to avoid the UNTHINKABLE happening to the ANONYMOUS!).

O Testador também necessita saber programar?

A oitava Mesa Redonda DFTestes de 2010 teve como tema “O Testador também necessita saber programar?”, 29 respostas e  20 participantes, sendo eles: eu, Ismael Munchen, Milton Vopato, Felipe Silva, Ronaldo Cruz, Rodrigo Souza, Rodrigo Almeida de Oliveira, Anna Carolina Rocha, Edwagney Luz, Andrea Cruz, Shmuel Gershon, Jorge Diz, Eduardo Gomes,  André Dias, Camilo Ribeiro, Renata Eliza, Robson Agapito, Ueslei Aquino, Elias Nogueira e a Sarah Pimentel.

Abaixo, segue o “resumo” dessa excelente discussão (para conferir-la na íntegra, basta acessa esse link).

O Testador também necessita saber programar?

O Milton Vopato acredita que programação é um conhecimento que pode ser uma vantagem competitiva ao profissional da área de Teste de Software:

A rigor, não é necessário saber programar para realizar certos tipos de teste, em específico, testes funcionais, pois são validações em alto nível das regras de negócio, mas eu particularmente, acredito que qualquer profissional de TI, deve conhecer não só programação, mas o ciclo de vida de um software por completo (Requisitos, Desenvolvimento, Teste, Implantação resumidamente). Mesmo não sendo obrigatório conhecimentos de programação no teste, eu vejo como uma vantagem competitiva muito importante, para entender melhor o problema, desenvolver automações e participar de reuniões com dev. para discutir o defeito encontrado.

O Felipe Silva lembrou que para automação é fundamental você saber programar, e que um dia quem poderá ter tal papel é você, portanto é importante se aperfeiçoar:

Um dia pode ser você o escolhido para automatizar, estar preparado para pelo menos aceitar o novo desafio proposto com certeza te fará bem visto pela empresa. Ainda que não use no momento o seu conhecimento em automação no projeto, você pode criar uma automação de suporte ao seu dia dia, automação não é apenas criar o script de teste funcional de uma funcionalidade do projeto, mas sim é simplificar as suas tarefas, seja criando um pequeno aplicativo que te ajude a manter algum tipo de informação para gerar futuros relatórios, criando um macro no “office” e/ou qualquer coisa que aumente a tua produtividade. Pense à frente, seja criativo, MUDE para melhor!

Para o Ronaldo Cruz o testador não precisa conhecer programação ao nível de conseguir criar um sistema, mas o básico poderá ser muito útil, já que irá ajudar a realizar melhor as suas tarefas de Teste de Software:

Penso que quando se fala que o testador precisa saber programar, a maioria imagina que o testador necessita de conhecimentos a nível de criação de sistemas. Na verdade, o profissional não precisa chegar a tanto (só se quiser é claro), mas precisa conhecer o básico da linguagem. Isso ajuda em planejar melhor os testes, saber o que é efetivamente erro ou não e melhor explicar os bugs a equipe de desenvolvimento.

E o Ronaldo Cruz ainda finaliza o seu comentário dizendo:

Então do meu ponto de vista, o testador precisa saber programar? Sim, bem como também precisa saber analisar requisitos, mexer em banco de dados, ter conhecimentos em infra ou suporte.

Um ponto interessante levantado pelo Rodrigo Souza, foi em relação ao seu contexto:

O quanto é necessário destes conhecimentos, cada projeto, cada empresa e cada teste vai variar, e com certeza só acresce ao testador. Ter esses conhecimentos ajuda muito, claro que o profissional não vai ser o melhor programador e trabalhar com testes, mas dependendo do projeto sim teria que ser um ótimo programador, afinal quem são os tester do Eclipse e outros? se não tester com muito conhecimento em programação.

O Rodrigo Almeida compartilhou uma experiência que teve na sua empresa:

Em se tratando de automação de testes de software, aqui na empresa só obtivemos resultados satisfatórios depois que trocamos todas as pessoas que não eram programadores por programadores. As ferramentas de automaçao exigem que você saiba programar. Não tem jeito mais de voltar atrás neste cenário.

A Anna Carolina compartilhou a visão de pessoas que tem outras preferência na área de TI, até porque a área de TI não é feita só de programadores, nela há espaço para os mais variados tipos de perfis, e na área de Teste de Software há espaço tanto para quem gosta de programar quanto para quem não gosta:

Embora eu adore a área de informática, eu me considero uma pessoa muito comunicativa e não consigo passar o dia inteiro simplesmente olhando pra tela do computador programando. Logo, eu considero não possuir o perfil de programadora.
Fui em busca de outras áreas dentro da informática que me permitissem maior interação com outras pessoas, sejam elas usuários ou colegas da informática. Como a primeira opção que minha primeira chefe me passou com este perfil foi a área de testes, comecei a estudá-la e me apaixonei por ela. E cada vez menos dei importância para a programação.
Não trabalho com testes automatizados, então talvez a programação não me faça tanta falta. Mas é claro que também não estou na situação de quem não sabe nada: se você me pedir para escrever um código para resolver tal problema, eu talvez não consiga ou leve muito tempo para fazê-lo, pois gastarei muito procurando a sintaxe correta e as funções a serem usadas. Mas se eu preciso analisar um código que está dando problema, eu consigo assimilar o que foi feito pelo programador e raciocinar em cima disso para localizar a origem do erro.

A visão do Edwagney sobre o tema:

Minha visão desse tema vai um pouco mais além do conceito de saber programar para encontrar problemas mais rápido, ou abrir o código e entender. Saber programar e sobre banco de dados e etc,  significa conhecer a mente de quem está por trás de um trabalho. Conhecer a mente de um programador, conhecer a mente de quem modela banco de dados, etc. Partimos do pressuposto de que conseguimos entender que TODOS são seres humanos e erram, mas com a vantagem de conhecer quais os principais pontos em que uma falha pode ocorrer durante um trabalho de codificação, por exemplo. Nossa função é fazer um forte elo entre o que pensa o cliente e quem desenvolve o projeto e fazer com que o produto acordado entre os dois saia o mais próximo possível do estimado.

A Andrea acredita que é necessário ter conhecimentos básicos, mas que ainda não é imprescindível saber programação, para poder trabalhar na área de Teste de Software:

Ao meu ver saber programar, ou ter pelos menos conhecimentos básicos de Lógica de Programação, if..then, case, for (i=0..10) é importantíssimo para alguém que trabalhe na Área de Teste de Software porém hoje ainda não é imprescindível. Quem tem algumas noções pode se encaixar em qualquer projeto, ler qualquer Diagrama de Estado, Diagrama de Sequência, Fluxograma e ter uma noção plena de como funciona o fluxo do sistema como um todo.

O Shmuel citou as vantagens que o testador irá ter, caso conheça programação:
– O tester é capaz de entender os tipos de problemas que o aplicativo pode apresentar, pois o tester pode montar seu modelo mental de como o software funciona por dentro e testar os limites desse modelo.
– O tester é capaz de fazer testes automáticos quando necessário. Talvez até mais importante, a criação de pequenas ferramentas que facilitam a configuração rápida do sistema, ou que recolhem dados para relatórios podem fazer do tester um jogador importante com influência na equipe toda.
– Facilita a comunicação com os programadores. Bom ponto levantado pelo Milto e Felipe. Gostaria de dizer: “Programadores são seres que, bem, só entendem a linguagem de programadores, fazer o que :)”  mas como gosto muito dos programadores vou dizer diferente: É mais fácil conversar com eles quando nos colocamos no mesmo contexto que eles.

O Shmuel ainda falou sobre o que eu acredito ser o conhecimento mais importante para o testador, conhecer o domínio em que atua, utilizando um ótimo exemplo:

Cem Kaner uma vez comentou que “Eu não aceitaria um estudante de informática ou doutorado em meu laboratório se eles tem habilidades de comunicação fracas. Pela minha experiência essa característica é mais importante para o sucesso do que habilidades de programação”
A visao de Kaner, nos artigos que ele escreve sobre recrutamento de testers, é que os times devem ser heterogêneos, e nem todos devem saber programação. O conhecimento da area sobre a qual o software atua (domain knowledge) é essencial para se ter testes efetivos.

Por exemplo:
Se você estiver montando uma equipe para testar um software que faz transações na bolsa de valores, qual tipo de pessoas você recrutaria? Que soubessem programar ou que entendessem do mercado de ações? A melhor resposta, diz Cem, é “pessoas de ambos os lados”.

Pessoalmente, se eu tivesse que escolher um dos extremos, eu iria recrutar alguém com experiência no mercado de ações.  Ei, mas ele não sabe programar! Bom, o usuário final também não! 🙂

O Ismael Munchem acredita que:

Um testador com conhecimentos em programação seria mais completo. O conhecimento da linguagem não precisa ser um requisito para contratação, mas deveria ser algo a aprender em seguida.

O Jorge Diz começou o seu comentário fazendo uma analogia com o futebol:

A analogia que imaginei foi o futebol: “O Goleiro também necessita saber chutar ?”. Ai começou a cair a ficha: no futebol, o papel do goleiro está bem definido, com regras
claras sobre o que se espera dele em campo. Não acontece o mesmo com o profissional de testes: em particular, o “testador” poderia ser identificado como aquele que segue roteiros repetitivos, criados por outro profissional mais graduado (“analista de teste”). Seguindo com a analogia futebolística, a pergunta ficaria: “O Gandula também necessita saber chutar ?”

Em seguida, o Jorge expressou a sua opinião, frisando bem que a repetição de trabalho no Teste de Software é algo que deve ser evitado, e uma das soluções para isso é justamente a automação, mas a mesma não resolve tudo:

O papel de testador como subalterno seguidor de roteiros escritos está condenado. Não acredito, no médio prazo, haver espaço para que uma pessoa faça tarefas
repetitivas e alienantes de maneira produtiva, e mantendo um mínimo de motivação. Talvez uma exceção sejam as pessoas com um certo grau de autismo, como exemplificado pelo trabalho de empresas e organizações como Specialisterne na Dinamarca e Aspiritech nos EUA. Vejam, por exemplo, este artigo de Harvard: http://hbswk.hbs.edu/item/5869.html

Não descarto teste manual. Acredito, sim, em sessões exploratórias guiadas pela experiência, feitas por profissionais com perfil investigativo, utilizando recursos e conceitos de tecnologia para identificar e localizar defeitos no software de maneira similar aos policiais e peritos forenses do seriado CSI. Não imagino este perfil profissional sem um mínimo de vivência em diversas áreas de TI, incluindo desenvolvimento: infelizmente, não é o perfil procurado hoje pelas empresas quando é anunciada uma vaga de testador.

Note-se que nem falei ainda de automação: parece ser consenso do grupo que nesse caso o conhecimento de programação é indispensável. Reforço, no entanto, que automação não é tudo.

Outro papel do profissional de testes deveria ser o de promover a testabilidade dos sistemas. Para isto, é necessário conhecer bem padrões de arquitetura de software, orientação a objetos, técnicas de dublês de testes, injeção de dependência, polimorfismo, concorrência… Em minha opinião, isto vai muito além de if, for, while …

O Eduardo Gomes lembrou muito bem que a maneira como o testador faz os testes (caixa-branca e caixa-preta) irá exigir conhecimentos específicos e diferentes:

Entendo que a questão do testador ter ou não que saber programar merece uma análise conforme o contexto.

Se estamos falando de testes nos níveis mais baixos (unitário e integração), é interessante que o testador conheça bem lógica de programação, a sintaxe e a estrutura da linguagem utilizada na construção da aplicação, aspectos sobre o banco de dados utilizado e a arquitetura da solução. Além disso, pode ser necessária a construção de drivers ou stubs e o conhecimento de programação será muito útil.  Lembremos que esses testes são predominantemente caixa-branca.

Mas se falamos dos testes no nível de sistema ou mesmo dos testes de aceitação realizados pelo usuário, esse conhecimento para os testadores passa a ser menos relevante, pois o foco será a validação dos requisitos e das necessidades do usuário.  Trabalhamos muito mais com testes caixa-preta.

O Camilo Ribeiro levantou um ponto interessante, sobre os profissionais de Teste de Software, precisarem ser generalistas:

O Analista de Teste, Engenheiro de Teste, Líder de Teste, ao meu ver, são um generalistas. Não devem encontrar defeitos somente no software desenvolvido, mas em todo o sistema e em todo o processo para o desenvolvimento do sistema (sistema != software).

O que acontece quando um analista de teste resolve se tornar “o sênior” dos testers, sem ter adquirido conhecimento em OO, programação, requisitos, negócios e etc., é que ele se torna um especialista em achar “bugs”. Ele tem cinco certificações, oito cursos “mais ou menos” de teste, MBA em teste de software e etc. Ótimo currículo, para um testador.

Para a Renata Eliza todo conhecimento adquirido poderá ser útil:

Eu acredito que o Tester não necessita ser um desenvolvedor nato, mas precisa conhecer de programação sim. Acho que vale inclusive aquele conhecimento acadêmico, dos tempos da faculdade… Todo e qualquer conhecimento a mais só vai agregar qualidade ao teste.

O Robson Agapito relatou a sua experiência em desenvolver sistemas, justamente para apoiar o processo de Teste de Software, e essa é uma aplicação muito legal do conhecimento de programação, pois é difícil encontrar uma ferramenta que se adeque ao seu processo sem ter que realizar alguma customização:

Como ele foi desenvolvedor , a cada conhecimento adquirido ele foi desenvolvendo uma ferramenta especifica para a sua equipe… e desenvolvendo consultas para que pudesse colher os resultados de testes, além de gerenciar os mesmos. Claro se não fosse desenvolvedor também conseguiria isso, mas como já estava acostumado foi muito mais fácil e muito mais rápido este salto, hoje a equipe dele possui várias ferramentas de apoio que são fundamentais para o andamento e a agilidade da célula (mesmo o tempo ainda sendo um grande vilão dos testes), ganhando sempre em produtividade, deixando as coisas mais automáticas. E a gestão dos testes é bem menos trabalhosa do que na gestão anterior.

Para o Ueslei o conhecimento em programação ajudou no desenvolvimento de sua carreira:

Eu particularmente já passei pela cadeira de desenvolvedor, e isso me ajudou muito quando assumi a posição de gestor de testes em uma empresa e tive que fazer prova de conceito em ferramentas de automação e até mesmo em executar automação.

A empresa tinha resistências em investir em profissionais especializados e de acordo com a demanda de trabalho, eu trocava o boné e ora testava, ora gerenciava, ora automatizava e ainda treinava outros testers na ferramenta.

O Elias apresentou os cargos existentes na nossa área, é comentou que pessoas que conhecem e gostam de programação, costumam ser Automatizadores de Teste:

Se puxarmos para os cargos dentro da área de Teste de software, teremos os abaixo:
– Testador
– Automatizador de Teste
– Analista de Teste
– Engenheiro/Arquiteto de Teste
– Líder/Coordenador de Teste
– Gerente de Teste

Bom, como todos já sabem, já temos um cargo específico para o Testador que sabe programar; o Automatizador de Teste.

A Sarah fez o seu comentário relacionando o cargo com o conhecimento de programação necessário:

– Testador
Não precisa saber programar.
Mas ter boas noções de programação ajuda a encontrar bugs e reporta-los adequadamente.
– Automatizador de Teste
Nem precisa comentar 🙂
Precisa saber programar e BEM.
– Analista de Teste
Não precisa saber programar.
Mas saber programar ajuda muito a avaliar a aplicação e inferir sobre os testes que serão realizados, escolha das técnicas aplicadas e análise de riscos.
– Engenheiro/Arquiteto de Teste
Precisa saber programar, conhecer design patterns também. Deveria participar de reuniões de revisão de arquitetura e de código para ajudar a encontrar bugs mais cedo no projeto.
– Líder/Coordenador de Teste
Eu vejo esse papel como se uma pessoa que sabe se virar muito bem tecnicamente. Isso inclui programação também. Não quer dizer que a pessoa precise saber tudo de tudo, mas deve ser capaz de auxiliar sua equipe a encontrar respostas. Fica mais fácil quando se tem o conhecimento.
Obviamente fora o técnico também precisa ter bons skills pessoais.
– Gerente de Teste
Houve uma época que se dizia que um gerente não precisava conhecer o que estava gerenciando, apenas “gerenciamento”. Eu sempre discordei. Não imagino como alguém consegue gerenciar o que não conhece.
O gerente realmente não precisa saber programar.

Conclusão

Essa mesa redonda foi uma das mais produtivas, e para mim os seguintes pontos ficaram claros:

  • Na área de Teste de Software há espaço tanto para pessoas que sabem e gostam de programar, como para pessoas que não sabem ou não gostam de programar;
  • É de extrema importância você saber o que você quer, pois dependendo da função que você deseja exercer, conhecimentos específicos serão exigidos, ou seja, não adianta por exemplo, ter vontade em ser um Automatizador de Teste se os seus conhecimentos sobre programação são limitados;
  • Os profissionais de Teste de Software devem ser especialistas-generalistas! Como assim Fabrício? Devem ser especialistas em Teste de Software e no domínio que atua, e ainda precisam ter bons conhecimentos sobre as tecnologias utilizadas na sua empresa; (tava achando que a vida de um profissional de Teste de Software é moleza!?)
  • Programação é um conhecimento importante na nossa área, mas dependendo da sua realidade, é capaz que você nunca venha a precisar utilizá-lo, mas não é por isso que você precisa ignorá-lo;
  • Ao se especializar em programação e automação, não podemos perder o nosso mindset de profissionais da área de Teste de Software, pois somos “representantes” dos usuários finais, portanto precisamos saber falar e pensar na “língua” do usuário final, na nossa e ainda na dos programadores.

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.

Testar é tão fácil, que até a minha mãe testaria!

Na semana passada começou a primeira Mesa Redonda DFTestes, com o tema “Testar é tão fácil, que até a minha mãe testaria!”. A discussão teve o total de 19 participantes, que fizeram bonito dando as suas opiniões e compartilhando experiências,  gerando 26 respostas e tornando a discussão bem produtiva.

Os participantes foram: Robson Agapito, Simon Rodrigues, Sarah Pimentel, Ronaldo Cruz, Renata Eliza, Ricardo Franco, Felipe Silva, Ricardo Franco Custodio, Camilo Ribeiro, Maria Meire Gomes, Rita Lima, Michel Mendoza, Carolina Baldisserotto, Emerson Gomes da Silva, Ueslei Aquino da Silva, Edwagney Luz, Andrea Cruz, Rodrigo Almeida de Oliveira e eu também. 🙂

O intuito desse post é fazer uma compilação da discussão, espero que gostem.

A discussão teve como tema “Testar é tão fácil, que até a minha mãe testaria!”, e foi feita em torno das seguintes perguntas:

  • Esse é um mito ou verdade?
  • Como surgiu esse mito?
  • Por que ainda hoje, há muitas pessoas que tem essa opinião?
  • O que podemos fazer para acabar com esse mito?
  • A área de Teste de Software sofre preconceitos?

Para o Robson Agapito um dos motivos é a pouca disseminação do conhecimento sobre Teste de Software, principalmente devido a inexistência dessa matéria na maioria das faculdades do Brasil:

[…] este mito ocorre principalmente por falta de conhecimento de muitas pessoas da área de TI. Então se começarmos a divulgar mais sobre testes de software pode ajudar muito a não terem esta visão.

Uma situação que era extremamente importante para ter um reconhecimento grande durante os próximos anos seria a inserção inicial de uma matéria sobre testes de software nas universidades, e quem sabe um curso na graduação sobre testes de software.

A Renata Eliza lembrou que podemos ajudar a conscientizar os nossos colegas de trabalho, sobre o que de fato é testar:

É um trabalho árduo, mas que não é impossível.  A falta de conhecimento faz com que as pessoas de um modo geral pensem dessa maneira extremamente equivocada.  Se conseguirmos conscientizar a empresa onde estamos hoje e os colegas da área de TI (extra-empresa) que nos cercam, já vai ser um ganho incrível.

Para mim, há ainda muitas pessoas que acreditam que Teste de Software, só tem uma fase, a da execução, e que só fazem testes exploratórios de forma manual. E isso é fruto da ignorância dessas pessoas em relação ao Teste de Software.

A respeito da aparente facilidade de testar um software, tivemos diversas opiniões, complementares:

Para o Simon:

(Testar) Não é tão fácil assim, o profissional de teste de software tem uma visão diferente das demais pessoas da organização, sendo especializado em testar o software através de algumas técnicas.

Já para a Sarah Pimentel:

Se pensarmos que um caso de teste manual deve estar tão bem descrito que qualquer pessoa possa executá-lo, para o TESTADOR, na minha opinião, isso se torna verdade. Mas não é sempre assim, muitas vezes exige um certo conhecimento da parte do testador. E além disso, para chegar nesse resultado de escrever o caso de teste correto e dessa maneira, há várias outras implicações.

E a Sarah ainda concluiu que:

  • Considerando os baixos critérios de admissão das empresas, e a facilidade em chamar “qualquer coisa” de testes: Sim, testar é tão fácil que até a minha mãe testaria (e melhor que muita gente por ai).
  • Considerando um mundo ao menos próximo do ideal: Não! Testar exige conhecimento, preparo e experiência.

O Ronaldo Cruz alertou que tal afirmação é perigosa:

Dizer que “testar é tão fácil que minha mãe testaria” é algo perigoso de se dizer, porque exige um mínimo de conhecimento de negócio ou do ambiente em que se testa, caso contrário, você vai apenas mascarar a atividade, sendo que nem o básico realmente é validado, e o risco de se ter a imagem da empresa arranhada por entregar produtos mal feitos e sem qualidade pode ser irreparável.

O Ricardo Franco, fez uma boa analogia, mostrando que há pessoas que falam que testar é fácil, mas nem se quer sabem o que é testar:

Pra mim, isso aí é igual àquela estória da beterraba:
– Você gosta de beterraba?
– Não.
– Você já comeu beterraba?
– Não.
– Então porque você diz que não gosta se não sabe nem o sabor?
– Porque as pessoas dizem que é ruim.

O Felipe Silva apresentou o cenário da área de Teste de Software na IBM, para ilustrar o quanto é errôneo pensar que testar é uma simples tarefa e que qualquer um pode executar:

Só a título de curiosidade a empresa mundialmente conhecida IBM conta com um departamento chamado GTO (Global Test Organization), departamento este que hoje emprega mais de 7000 funcionários só no Brasil e movimenta a maior parte do faturamento da empresa no Brasil.

Quem pensa que teste não leva à nada ou é gerente e pensa que teste é apenas custo… acho que deveria rever seus conceitos.

Na minha opinião, a dificuldade de testar depende do sistema sob teste, só que o mesmo também baliza a dificuldade das outras atividades do desenvolvimento de software (ex. arquitetura, análise, programação, etc). E de acordo com a complexidade e tecnologias utilizadas no desenvolvimento de um sistema, o Teste de Software pode se tornar extremamente difícil.

Outro motivo citado na discussão, que ajudou a fortalecer esse mito, é a respeito da competência e preparo de alguns profissionais que atuam na área.

A Sarah, apresentou a seguinte realidade:

O que ocorre é que há muitas pessoas sem preparo no mercado. Nada contra iniciantes, eu obviamente um dia fui uma, mas há pessoas que iniciam na área de testes na seguinte sequência: Faz vestibular pra um monte de coisa, não passa, arruma uma faculdade genérica qualquer pra fazer um curso qualquer (leia-se informática) – isso quando faz uma faculdade-, não gosta de programar, não se dá bem com processo, com arquitetura, com redes, etc, resolve que vai ‘fazer testes’. Não se aprimora, não busca conhecimento, e continua por ai sendo um profissional no mercado.

Culpa também das empresas que muitas vezes preferem os mais baratos em detrimento dos que estão melhor preparados.
O Camilo Ribeiro, compartilhou a sua opinião de que há:

Profissionais que realizam testes “exploratórios” e nada mais não são testadores. Esses testes “exploratórios” são o que nos enfraquecem, fazem nosso trabalho parecer simples e como disse nosso amigo Fabrício, o teste passa a ter uma única fase, a execução “porca”.

Muita gente acha que só fazemos esses testes “meia boca”, e isso em grande parte por culpa dos que se dizem analistas de teste e na verdade acabam por mostrarem-se amadores ou pessoas sem capacidade técnica e organizacional para medir a eficiência do próprio trabalho.

O Emerson Gomes compartilhou algumas experiências vivenciadas:

Creio que também a existência de maus profissionais, tanto fora quanto dentro da área de testes pode trazer tal impressão.

[…] um profissional que está na área, mais com muito pouco conhecimento técnico…como eu também já presenciei…como um testador que não tinha quaisquer conhecimentos de SQL, sequer para executar uma consulta…. A presença dele na equipe, fazia outras pessoas utilizarem essa velha máxima de que “Até minha mãe testaria”, pois a pessoa citada tinha poucos conhecimentos técnicos, e apenas fazia testes funcionais, baseando-se nas regras de negócio, mais sem o poder de conseguir verificar casos como uma transação que leva dados a um software legado, ou se um simples cadastro está sendo feito da maneira correta na sua base de dados.

Sobre o que podemos fazer para acabar com esse mito, houveram boas sugestões, como a do Ronaldo Cruz:

O que podemos fazer para mudar essa mentalidade é justamente fazer os envolvidos terem conhecimento das nossa atividades, como ela funciona, a importância da mesma, cases de projetos com e sem qualidade, o valor agregado. No meu caso, o pessoal começou a dar valor e exigir o meu trabalho dentro da equipe depois que eles conheceram as minhas atividades, o quão complexo elas são e o quanto os produtos entregues começaram a ter um menor grau de reclamação e defeitos encontrados pelo cliente

A Renata Eliza sugeriu 7 atitudes que os profissionais da área de Teste de Software precisam ter:

  1. O 1º passo é ter uma afeição pela área área;
  2. Pensar que: você não precisa provar nada pra ninguém (sem essa de achar que eles vão pensar que você era um péssimo desenvolvedor, ou que não achou nada de mais interessante na área…);
  3. Aprender. A busca do conhecimento é fundamental;
  4. Empreender no dia a dia de trabalho;
  5. Aplicar técnicas.. Cada uma em seu tempo. E mostrar os resultados alcançados com cada uma delas;
  6. Dar nome ao que está sendo feito.  Por exemplo: por que falar que vai repetir todos os testes? Diga: Vou realizar um teste de regressão. Pode parecer idiota, mas é uma maneira simples de mostrar que não nos limitamos a fazer testes exploratórios, e que existe técnica no que estamos fazendo;
  7. Não se desvalorizar.

Já para o Camilo Ribeiro, o testador não pode ser limitar apenas as suas tarefas, e disse:

A forma que temos de reverter isso começa em nós mesmos. Como disse Tolstoi (se não me engano) “Todos querem mudar o mundo, mas ninguém quer mudar a si mesmo”.

Ao mudamos nosso ambiente de trabalho aplicando técnicas, definindo um processo, criando indicadores, gerenciando nossas atividades e demonstrando o valor dos processos de teste dentro da organização que nós trabalhamos nós mudamos nossa imagem e conseqüentemente a imagem da nossa profissão.

Outra coisa fundamental na minha opinião é ser técnico. Saber programar, orientação a objetos, SQL, design patterns, conhecer ferramentas, usar frameworks, elaborar e revisar requisitos, escrever processos, gerencia de configuração e etc não nos torna menos testadores, muito pelo contrário, conhecer de tudo é saber identificar defeitos em tudo.

O Ueslei Silva fez um relato de uma experiência que passou, na qual a realização de treinamentos gerou bons resultados:

Após alguns treinamentos internos para os profissionais do setor de testes e algumas explanações internas sobre o que realmente é teste de software, depois de muita luta, finalmente entenderem que não é tão fácil como parece, principalmente quando o que temos para testar é um legado sem documentação…rs

Passos para um novo horizonte para realização dos testes começaram a se dar na empresa, mesmo que com algumas resistências, pois o custo é alto e profissionais precisam ser qualificados, cultura precisa ser mudada, etc…

O Edwagney contou uma interessante maneira de explicar e convencer as pessoas sobre a importância do Teste de Software, na qual precisamos:

Começar a mudar a percepção dos desenvolvedores, arquitetos e PRINCIPALMENTE dos clientes.

Certa vez estava dando um treinamento para uma das empresas em que trabalhei, sobre a recém-criada área de teste. Os treinandos eram compostos por desenvolvedores e arquitetos. A primeira pergunta que fiz a eles foi uma que vocês já devem conhecer: Se o software que vocês projetam e desenvolvem fosse para o controle de uma aeronave, vocês voariam nessa aeronave? (dá pra imaginar a resposta, não é verdade?) 🙂

Isso também deve ser levado ao cliente… Tente perguntar ao seu cliente se ele confiaria em voar em um avião que não foi passado por uma bateria de testes antes? Será que ele entraria lá dentro?

Coloque pra ele o valor que foi gasto para se construir e quanto será o gasto de cada defeito, senão for testado corretamente? Tente apresentar a ele o risco que a empresa dele corre, caso um defeito ocorra e este paralise o negócio dele?

A respeito se existem preconceitos de outras áreas para a área de Teste de Software, a Andrea Cruz apresentou uma maneira bem madura de se lidar com eles:

Preconceitos existem. A melhor forma é primeiro aceitar. Não adianta reclamar. É preciso admitir que existe um preconceito oriundo de uma grande falta de conhecimento nesta área e que por ignorância alguns discriminam. Algumas pessoas do  desenvolvimento se sente ameaçadas. Só você pode conscientizar as pessoas, esclarecê-las. Lutar pela qualidade é lutar por um padrão que só traz benefícios. É ser amigo do desenvolvedor e do cliente.

Para o Rodrigo Cruz, o preconceito é fruto da falta de informação:

Sofremos preconceito daqueles que não conhecem o nosso trabalho e nem se preocupam de perguntar o que fazemos, porque a partir do momento que isso ocorrer, com certeza eles vão deixar de pensar dessa forma.

Para quem ficou interessado no assunto, recomendo fortemente a leitura de toda a discussão, pois esse foi apenas um resumo, para ter idéia eu nem citei sobre a discussão levantada pelo Robson, sobre se seria interessante os analistas de negócios/requisitos/sistemas verificarem os casos de testes criados pela equipe de teste.

Participem das mesas redondas, entrando no DFTestes! 😉

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

P.S.: Desculpa pelo resumo ter ficado muito grande, mas acredito que é melhor informação a mais do que o contrário. 😉

Carreira – Teste de Software

A área de Testes é uma das que mais tem crescido, nos últimos anos, para se ter idéia em média há umas 50 a 70 vagas da área de Testes no Apinfo, site dedicado a vagas de TI, tendo como base o estado de São Paulo.

Esse resultado dá-se, devido a importância da execução dos testes, durante o ciclo de desenvolvimento. Principalmente, com o “boom” das práticas de outsourcing e de offshoring, que exigiu das empresas uma maior garantia da qualidade de seus produtos.

Recentemente saiu uma lista dos empregos de TI à prova de recessão, feita pela empresa de recrutamento online JobFox, na qual se encontra na 12º posição os profissionais especialistas em testes e controle de qualidade.

A carreira nesta área geralmente respeita a seguinte hierarquia:

  • Tester (Testador) – é a posição de entrada na área. O Tester é responsável pela execução dos testes, que em muitas vezes incluem as seguintes atividades: testar configurações de hardware e software, executar scripts simples de teste, reproduzir e reportar bugs. Alguns trabalhos podem se tornar chatos e repetitivos, mas com certeza o aprendizado obtido será muito recompensador e dará condições de galgar novas posições. É nesta fase que o profissional poderá ir para o “lado negro da força” (Desenvolvimento), caso seja notada habilidade e vocação para a programação. No Desenvolvimento o Tester será responsável por realizar os testes de Caixa Branca, principalmente os de nível unitário. E poderá preencher um gap existente na área de programação, que é a habilidade e conhecimento em testes, podendo assim ser tornar um excelente e requisitado programador.
  • Analista de Teste – é o profissional responsável pela modelagem e elaboração dos casos de teste e pelos scripts de teste. Em algumas vezes, ele também é o responsável pela execução de testes mais específicos, por exemplo testes de desempenho, estresse e homologação, nos quais exige um maior conhecimento e maior responsabilidade. Este profissional tem bons conhecimentos em Análise de Sistemas, UML, modelos, normas, processos, banco de dados, ferramentas de teste e principalmente tem pleno conhecimento do software que está sendo testado.
  • Analista de Automação de Teste – é o cargo mais recente da área de Testes. O Analista de Automação de Teste é um profissional que tem como objetivo principal, buscar a automatização de testes, sempre que ela for possível e viável. Utilizando para isso ferramentas, como por exemplo: JMeter, Marathon, Selenium, SoapUI, WebLOAD, entre outras. O profissional deverá estar atento ao aparecimento de novas ferramentas, ter bons conhecimentos de programação e buscar novas soluções para a melhoria dos testes. Ele necessita conhecer bem o processo de Teste e a realidade da empresa para que possa automatizar os testes de acordo com a necessidade da empresa, afinal a automatização de testes não é uma tarefa tão simples e se feita de forma equivocada poderá trazer prejuízos ao invés de benefícios.
  • Arquiteto de Teste – é o responsável pela montagem da infra-estrutura de teste, monta o ambiente de teste, escolhe as ferramentas de teste e capacita a equipe para executar seu trabalho nesse ambiente de teste. É uma função que exige um bom conhecimento em redes, sistemas operacionais (Linux, Windows Server, etc), servidores Web, banco de dados e principalmente conhecimento da infra-estrutura do ambiente de produção, na qual o software que vai ser testado será futuramente instalado, para que o ambiente de teste seja o mais próximo do de produção.
  • Líder de Teste –  é o profissional responsável pela condução dos testes e pela equipe de Testes. Geralmente é um profissional com alto grau de conhecimento em ciclos de vida de testes, automação de testes, ambientes de testes e documentação de testes. Ele ajuda o Gerente de Teste a elaborar os três relatórios básicos para o acompanhamento do projeto: Relatório de Status, Relatório de Progresso e Relatório de Desempenho.
  • Gerente de Teste – o Gerente de Teste tem como função primordial a iniciação do projeto de teste a ser realizado no produto a ser testado. Suas qualificações e competências se assemelham a um gerente de projetos típico: elaborar o plano do projeto de teste, aquisição de novos recursos, orçamento, riscos, prazos, elaboração de relatórios, limitações do escopo do projeto de teste e outras atividades gerenciais como constante comunicação com sua equipe, controle e monitoração das atividades, geração de métricas para alimentar indicadores, etc.
Hierarquia da área de Testes

Hierarquia - área de Testes

Os cargos e as tarefas dos cargos podem variar de empresa para empresa, principalmente devido ao porte da empresa. E é muito comum o acúmulo de papéis, por exemplo: o Analista de Teste também ser responsável pelas ferramentas de automação de teste e da montagem do ambiente de teste.
A área de Testes está a pleno vapor e os seus profissionais cada vez mais valorizados, exemplo disso é o surgimento de vários cursos, certificações e até MBA na área. Que mostram que o mercado está à caça de profissionais qualificados.

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

Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de software. São Paulo, Martins Fontes, 2007.