Uma crítica sobre automação de testes

Topic created · 10 Posts · 265 Visualizações
  • Galera,

    Venho acompanhando a vida dos testers no seu dia-a-dia e tenho notado uma crescente demanda por testadores que saibam programar (e muito bem), a fim de ser criar scripts de automação. É sabido que o Agile está aí para as equipes se integrarem, o programador ajudar o testador a automatizar… Mas infelizmente esta teoria vai na contramão do que as vagas para testers estão exigindo: testadores que sejam exímios programadores.

    Por conta disso escrevi um artigo refletindo sobre esta situação atual:

    https://medium.com/@irineu.sousa/não-existem-qas-balas-de-prata-uma-crítica-sobre-automação-de-testes-7dd2d1986adc

    Boa leitura!

  • Oi, Irineu! Beleza? Não sei se entendi muito bem a intenção dessa crítica. Tu comentou que os frameworks ágeis são realidade hoje de muitos projetos e eles ajudam muito na aproximação de devs e QAs e isso é bem verdade. Mas o que eu não consegui entender foi “Mas infelizmente essa teoria vai na contramão do que as vagas para testes estão exigindo”. Há um exigência sim nas vagas e vejo isso como um ponto muito positivo, visto que o QA faz parte do time de desenvolvimento. Hoje o perfil do QA vai muito além de testar coisas: Ele participa de discussões de soluções, faz a comunicação com o negócio, garante a qualidade do time, não só de código mas sim de processos. E acredito ainda que no futuro seremos todos desenvolvedores que se preocupam com qualidade e que cada tarefa numa Sprint seja tocada como apenas tarefa (:
    Obs: Obviamente acredito que cada um tenha sua especialidade: Infra, QA, Back-end, Front-end.

  • Olá Lucas,

    Pois bem, ultimamente venho acompanhando as vagas de QA e tenho notado que elas estão tornando cada vez mais mandatório a necessidade de automação + um conjunto de frameworks e linguagens de programação como pré-requisito. Selenium, Calabash, Cypress, Cucumber, (…) seja com Java, C#, Python, Js ou Ruby. A idéia do programador ajudar o testador com a automação está ficando apenas na idéia, pois a necessidade do testador se tornar um programador já é praticamente um pré-requisito no momento da seleção.

    O foco de garantir a qualidade e validar o funcional junto ao pessoal de negócio, que ao meu ver é o principal papel para o QA, vem sendo ofuscado por uma necessidade desenfreada de aprender linguagens, frameworks, automação e etc… O perfil do QA não deveria ser 100% técnico, mas analítico. Por conta disso, é muito comum encontrar testers que não possuem aptidão para programar porém são excelentes QA`s, com uma visão, comunicação, integração e resolução fantástica, mas o mercado cada vez mais vem exigindo a programação para o perfil de profissional que é analítico.

    Uma boa analogia é o developer full-stack que saiba de photoshop, programação à banco de dados. Vai existir um ‘pato’ (que anda, nada e voa mas não faz nada direito) aqui ou ali, assim como alguns gênios também, porém tornará muito difícil a ingressão de novos profissionais na área, assim como passou a ocorrer até mesmo com os próprios desenvolvedores. Falando de gerente de projetos, é importante que eles tenham um conhecimento mesmo que superficial em programação, o mesmo deveria valer para o QA, e não torna-lo um programador. Pelo menos esta é a minha visão 😅

  • Discordo totalmente.

    Se um vc espera que um QA seja mais analitico do que técnico em um contexto agil, pode mandar seu product owner embora que ele não ta fazendo o trampo dele.

    A analogia de saber fullstack e photoshop não se aplica para QA que precisa saber programar. Mesmo pq um dos papeis de um tester é entender como o software funciona e prever / identificar pontos de falha. Muitas vezes esses pontos de falha são bem chatos de fazer o setup manualmente, logo automatizando processos, você tem uma resposta mais rapida e concreta em um específico cenário.

    Se um QA não quer ser técnico ou aprender a programar, ele precisa mudar para área que ele tem mais afinco. Não há vergonha em deixar de ser tester e virar P.O. / analista de negócio.

  • Meus 50 cents.

    Da mesma forma que as tecnologias e metodologias evoluem, nós também precisamos evoluir.

    Eu não vejo cenário para um QA manual que prefere usar TestRail ou qualquer gerenciador de testes dentro de um time onde todos estão focados em feedback rápido por exemplo.
    Na minha opnião QA’s vão acabar se tornando mais técnicos o que é normal, convivência no dia a dia com desenvolvedores fazem a gente aprender cada vez mais.
    Fora o fato de que podemos ser análiticos e críticos mesmo sendo bons técnicamente (e.g ajudar o time a criar uma estratégia de testes, pareando com desenvolvedores durante a escrita dos testes, fazendo ponte de négocio com o time, fora outras atividades).
    Da mesma forma que existem diversas ferramentas por ai de record and play, gerenciamento de testes, também existem solucões para cada tipo de problema ou seja um framework específico ou até mesmo linguagem, não adianta querer resolver todos os problemas do mundo apenas com Ruby e capybara por exemplo.

    Voltando ao assunto de metodologias, feedback rápido é essencial nesse caso, lembrando que testes automatizados não se anulam eles se completam, tendo isso em vista teste manual sempre vai existir, mas em diferente contexto, executando testes exploratórios que sejam eficientes. Ao contrário de exaustivas sessões de testes regressivos totalmente manuais.

    Como o galani falou sempre temos a escolha de mudar para uma área mais voltada a negócio.

  • Concordo com vocês, galera! E as respostas complementaram muito do que eu acredito que seja o futuro (e até mesmo o presente) da nossa área. Fico felizão em saber que outras pessoas tão com essa mesma linha de pensamento! Abraço!

  • Excelente ponto @wellavelino !

    A idéia dos QA’s se tornarem cada vez mais técnicos eu defendo totalmente, assim como gestores, P.O, UX e etc. Claro…com a devida dosagem para cada cenário.

    Para ficar mais claro a idéia que quero transmitir, vamos olhar o perfil do DevOps:

    • Não se programa um sistema de CI, usa-se um Jenkins, Travis, etc…
    • Não se programa um sistema de CrashReport, usa-se um Crashlytics, instabug, etc…
    • Não se programa um sistema de Monitoramento, usa-se um New Relic, Kibana, etc…
    • Não se programa um sistema de gestão de incidentes, usa-se um Jira, Mantis, etc…
      (…)

    Claro que o DevOps deve possuir com conhecimento de linux, rede, servidores e até mesmo um nível de programação relevante para garantir que o build do projeto funcione o CI. Mas ele não precisa no futuro se tornar um programador e deixar de ser DevOps, pois não é uma profissão que irá morrer, mas uma que praticamente acabou de nascer, com um viés específico.

    Falando agora do QA, ele precisa ter uma visão analítica para identificar os problemas e reportar ao P.O para que ele defina a priorize o backlog para o time de desenvolvimento. É importante que ele seja técnico para utilizar um JMeter, Postman, QC, Jira? Quanto a isto é inquestionável.

    A idéia é priorizar o trabalho em equipe de diferentes expertises e não centralizar num super-profissinal. Um exemplo muito prático é: quantos QA’s não sofrem com gestão de massa de dados?

    Um QA não pode abrir um banco de dados nos servidores de homologação, montar um batch no CI para rodar uma rotina de drop e subir um dump de um cenário específico de teste, fazer o reload na aplicação, rodar a automação que ele mesmo programou, gerar os relatórios das execuções, analizar as causas das falhas e erros e reportar ao P.O. Neste exemplo ele assumiu responsabilidades de outros papéis do time que vão contra a idéia do manifesto ágil.

    O QA deve trabalhar com o Dev;
    O QA deve trabalhar com o DevOps;
    O QA deve trabalhar com o DBA;

    Trabalhar em time e não substituí-los. O mercado vem exigindo um cara que cobre escanteio, corra até a pequena área, cabeceie e faça gol.

    Referente à automação, eu vejo como principal objetivo atender à regressão. Sem dúvida poupa um tempo inimaginável. Mas para sua concepção o sistema precisa estar próximo do 100% para se automatizar. Querendo ou não durante a concepção da automação é realizado diversos testes manuais no sistema para a criação de cada rotina de automação. A automação no mundo de QA ao invés de se tornar um meio, está se tornando um fim. Considerando que ela seja o ápice da implementação de um projeto de qualidade de um sistema (assim como um projeto que vai para produção), eu questiono o meio (programação heavy mode) que é utilizado para a automação. É bom trazer à mente nessa hora o toolkit que o DevOps tem e o QA não.

    Já temos programadores. Se a visão analítica (cenários de teste, pontos de falhas, visão crítica e de negócio…) do QA é dispensável e o objetivo de um QA é se tornar um programador no futuro, então não precisamos de QA’s, que se contrate mais programadores.

  • Eu entendi o que @irineuantunes quis falar… testers estão sendo “empurrados” a serem programadores… eu acho isso bom pois serão mais skills pra nós e para o mercado pois não sei se já notaram mas estão surgindo novas vagas de funções os quais os testers executam. Exemplo: Analista de Qualidade… Analista de Homologação… essa galera é mais analítica e o analista de testes além de ter se tornado um analista de qualidade/homologação… está se tornando um desenvolvedor…

  • Essa conversa sobre papel de QA ou não, sobre ele ser técnico ou não so anda indo contra o que a metodologia ágil nos sugere em “modus operantis”, e quando digo isso, me refiro a profissionais multidisciplinares.
    Isso não e somente com a nossa área, em outras também. Estamos mais preocupados em entender o nosso papel do que trabalhar com todos, de forma multidisciplinar dentro de uma equipe.
    Como deram um exemplo de devOps acima, ele não vai deixar de ser devOps, mas programar vai aproximar ele mais do time e talvez ate ajudar em questões que o time não esta conseguindo… Por ter adquirido conhecimento ao invés de se preocupar com os “limites” do seu cargo. E se depois ele precisar saber mais de negocio, acreditem, eles vão melhorar seus skills e vãoo aprender… .

    P.O não precisa programar, mas ja vi casos que era uma pessoa técnica e ajudava em refinamento técnico de certas tarefas…Ou seja a gente fica abrindo conversas sobre perfis e “limites” sendo que a gente podia estar conversando em como melhorar a forma de como pensamos e vemos as coisas na área.

    Eu sou um que gosto de trabalhar, mas ao longo dos anos prefiro mais falar sobre praticas, ferramentas que ajudam monitorar e patterns do que falar de…sei la…usar zalenium e 300 containers que abre, por exemplo. Eu acho que nos temos muito material para quem quer dar um “pontapé inicial” em qualquer tipo de automação de testes. Mas ninguém quer falar sobre como testa. E eu não culpo, tem gente que nem sabe como esta fazendo o seu trabalho…Mas esta fazendo… 🙂

    Automação e um dos pontos que ajuda no trabalho. Saber ou não programar vai do perfil que deseja seguir. Senão quer ser mais técnico, vai entender mais do produto e captar isso.

    Agora a minha motivação, ao fazer essa mega texto de facebook hehehehe, e incentivar mais conversas sobre técnicas e maneiras de melhorar as skills, em qualquer âmbito, do que ficar se apegando a cargos e “limites” impostos nos cargos…

  • Se um Devops na minha minha equipe dizer que não usa jenkins job builder ou outro sistema para versionar as configurações via código… eu mando embora na mesma hora.