O Taverna Taller é um podcast criado para explorar um tema quente por mês. Cada programa contará com a presença de um integrante do time da Taller ou de algum convidado especial.
Coloque um fone de ouvido, dê o play e aproveite o passeio. Mas cuidado, nem tudo é o que parece Muahaha!
Veja a lista com todos os programas | Taverna Taller no iTunes
* * *
(Confira a seguir a versão transcrita e adaptada do podcast)
ø – A busca por respostas
Nosso viajante agora conhece o caminho da taverna e também já é conhecido por lá. Basta um cumprimento ao guardião e adentrar o salão em busca de uma curiosa figura mítica muito popular na Taverna Taller. Os boatos o informam para procurar no salão de jantar e nosso viajante é atraído pelo aroma fresco da ceia recém servida. Soa uma cantiga suave ao piano.
[Viajante]
Ei! Walmyr Filho, certo? Me disseram para falar com você. Mas antes de conversarmos, você poderia se apresentar? Preciso ter certeza de que você não é um impostor!
[Walmyr]
Eu gosto de usar um conceito que estudei no livro – Personal Branding – que ele chama de hifenização. Para descrever a mim mesmo, eu diria que sou um desenvolvedor-testador-blogueiro-tradutor-palestrante-freelancer. Trabalho na Taller como desenvolvedor puxando histórias de valor junto ao time, mas também como um tipo de coach em práticas de agile testing. Procuro disseminar a cultura agile testing no time. Alguns projetos paralelos eu iniciei no repositório do GitHub da Taller que é um framework para testes de aplicações de interface Drupal (Drupal Protractor Framework). E além desse framework, tenho um blog focado em teste de qualidade de software, o Talking About Testing, tenho também uma série de vídeos para ensinar técnicas de teste automatizado para interfaces de usuário com Protractor que eu chamei de Aprendendo Protractor.
I – O profissional de QA, o Tester e o Coach de Testes
[Viajante]
Me diga em poucas palavras, de forma direta, o que faz um profissional de QA e o que significa QA? Aqui no Brasil, podemos chamar esse profissional de Tester? Existe diferença entre os dois?
[Walmyr]
Existem dois termos: QA pode ser Quality Assurance – Garantia da Qualidade – ou pode ser Quality Analyst – Analista de Qualidade – são coisas bem diferentes. Pela perspectiva de Garantia da Qualidade, esse é um profissional mais envolvido em processos que venham a garantir a qualidade, não só do software, mas de tudo que está sendo desenvolvido. É mais comum esse papel de Quality Assurance em empresas que tem algum tipo de certificação (CMMI), já o Analista de Qualidade é um desenvolvedor focado em qualidade que olha o software sob diversas perspectivas, desde questões relacionadas à experiência do usuário, usabilidade, até questões muito mais técnicas, tipo como o software vai se comportar quando muitas pessoas acessarem ao mesmo tempo, com testes de integração e de interface gráfica, entre outros.
[Viajante]
O papel de Coach de Testes é relativamente novo? Qual a diferença entre um Tester comum e o Coach de Testes?
[Walmyr]
Diria que é um papel bastante novo aqui no Brasil, mas para mim é um papel que surgiu principalmente por querer ir além de testar e também participar do processo e do ciclo de desenvolvimento como um todo. Para isso preciso repassar meu conhecimento para quem trabalha comigo e ao mesmo tempo adquirir conhecimento deles para eu poder assumir outros papéis. Diria que essa é a diferença:
Deixar de pensar em papéis separados e pensar em pessoas que trabalham em um time.
[Viajante]
Que tipo de linguagem de programação, ferramentas ou até conceitos de desenvolvimento são necessários para um bom profissional de QA?
II – Linguagens e ferramentas
[Walmyr]
Acho que é algo muito pessoal, acredito que depende do contexto do time em que a pessoa trabalha. Se a pessoa trabalha numa empresa que desenvolve em Java e ela vai querer desenvolver em outra linguagem, não faz muito sentido. Eu desenvolvo usando Javascript que gosto muito e acho que é uma linguagem fácil de aprender, mas prefiro não influenciar. Com relação ao aprendizado, por ser uma questão mais profissional, acredito que em algumas coisas importantes para saber hoje em dia: versionamento de código com Git, aprender a trabalhar com linha de comando, hoje em dia se desenvolve muito com sistemas baseados em Unix, se faz muita coisa na linha de comando sem entrar na interface gráfica, expressões regulares é um assunto bastante importante quando se trabalha com atividades de teste com BDD (Behavior Driven Development), seletores CSS para poder conseguir identificar elementos na tela para criar testes automatizados e outras coisas mais genéricas como práticas de programação extrema, TDD, como fazer para configurar uma ferramenta de integração contínua para rodar meus testes. E uma coisa que eu gosto bastante de recomendar é o Código Limpo, desenvolver código de qualidade e que comunique o que ele faz para outras pessoas que vão ler esse código e dar manutenção.
[Viajante]
Eu li que nos seus textos no Blog da Taller você cita bastante o Protractor, essa é uma ferramenta fácil de aprender? Como você encaixaria o Protractor para quem está começando e querendo se envolver mais nessa área?
[Walmyr]
Protractor é um framework para testes automatizados de aplicações web focado em Angular, porém, nós aqui na Taller utilizamos para testar aplicações Drupal e pode ser utilizado para testar qualquer tipo de aplicação web. Eu considero uma ferramenta fácil de aprender e principalmente para quem já tem conhecimento de Javascript, que é a linguagem utilizada por esse framework e também é interessante para desenvolvedores que estão começando a desenvolver testes não só nas camadas mais baixas como também na camada de interface do usuário. Hoje em dia se desenvolve teste a nível de unidade com Jasmine que é a biblioteca que o Protractor utiliza e a sintaxe é basicamente a mesma. Então para o desenvolvedor que já desenvolve testes a nível de unidade por exemplo, e que quer aprender a fazer testes de interface, ele não vai sentir diferença nenhuma quando estiver escrevendo os testes.
III – Os testers e a coluna de QA estão em extinção?
[Viajante]
Recentemente vi no seu blog um post que gerou bastante polêmica que questionava se os dias dos profissionais de QA estavam contados. Gostaria de saber se o Testers vão entrar em extinção?
[Walmyr]
Ih isso vai dar briga! Minha visão é de que o profissional menos técnico que se limita apenas aos testes manuais será menos valorizado, mas isso depende muito de contexto e não dá para generalizar. Eu diria que em startups, por exemplo, esse papel especialista de QA ou Tester não é mais necessário e também na verdade eu já conheci pessoas que trabalham em empresas de desenvolvimento que não tem profissionais especialistas em qualidade de software mas que desenvolvem com alta qualidade e ganham dinheiro com isso, então na minha opinião, em contexto de grandes organizações em que há muita burocracia e que segue um modelo muito tradicional, ainda vai existir por um bom tempo. Em empresas que estão começando, com mentalidade ágil, esse profissional será cada vez menos necessário.
[Viajante]
Então eles serão forçados a evoluir, a aprender coisas novas e a entender o que os outros colegas de profissão estão fazendo, não é mesmo?
[Walmyr]
Isso é importante. Não é pensar “o que eu vou fazer agora para não perder meu emprego?”. Estamos sempre nos reinventando. Eu acredito nisso hoje, mas fui especialista por mais de 10 anos em testes de software e a questão de eu me reinventar para conseguir trabalhar em um time que não precisa mais de uma pessoa específica. Então, estou desenvolvendo habilidades de back-end, front-end, operações. É só uma questão de se dispor em se reinventar ou então ficará para trás. Já vi pessoas falando assim: “Até existem empresas que vão continuar contratando pessoas só para fazer testes manuais, mas essas não são as empresas mais legais de se trabalhar” então depende do que tu almeja para ti mesmo.
[Viajante]
Existe uma tendência entre os times ágeis de se trabalhar com uma coluna de QA nos boards kanban. Na sua opinião, essa coluna ajuda ou atrapalha a performance de times ágeis?
[Walmyr]
A minha opinião é que depende muito do nível de maturidade do time. Nós aqui na Taller já utilizamos essa coluna e amadurecemos para não precisar mais. A minha visão é que a longo prazo essa coluna atrapalha principalmente pela questão da separação de responsabilidade entre quem vai desenvolver e quem vai testar. Algumas pessoas vão dizer que isso não faz sentido porque se a mesma pessoa que desenvolver for testar, ela estará viciada no código que ela fez. Para isso existem outras técnicas de desenvolvimento guiado por testes onde é possível desenvolver o teste primeiro (sem vício do código, afinal ele ainda não existe), a programação em par ajuda muito pois uma pessoa ao seu lado programando junto tem uma perspectiva diferente da sua ao olhar para a aplicação.
Em suma, para times maduros, a coluna de QA mais atrapalha que ajuda. Em times não tão maduros, a coluna ajuda mas precisamos entender que a coluna não precisa existir para sempre.
[Viajante]
Você acha que é possível acabar com a coluna? Quais são os riscos inerentes nessa decisão?
[Walmyr]
Aqui na Taller experimentamos e consolidamos a não-necessidade da coluna de QA ao longo do ciclo de desenvolvimento de software e hoje temos dados que comprovam que nossas demandas de falha diminuiram depois dessa mudança, portanto eu diria que sim, é possível fazer essa mudança para trazer valor aos envolvidos. Gostaria de separar vantagens e riscos de utilizar essa abordagem:
VANTAGENS
Maiores responsabilidades sobre as entregas do time como um todo e menos de um time específico que vai fazer os testes, menos gargalos (aqui na Taller tínhamos menos pessoas trabalhando com testes e mais com desenvolvimento, então fazer a atividade de testes era um gargalo), mais trabalho pareado, o que é bom para revisão de código. Acredito que a longo prazo a produtividade aumenta quando eliminamos essa coluna. É uma fase a menos no desenvolvimento.
RISCOS
Se o time não é maduro o suficiente e não entende que a responsabilidade de desenvolver software é de todo o time, pode continuar acontecendo do desenvolvedor fazer seu trabalho meia-boca e passar para a frente e se não existir outro time que irá testar a funcionalidade, quem vai encontrar o bug é o cliente em produção, o que pode gerar transtorno para diversas partes.
VII – Onde buscar informações sobre testes de software
[Viajante]
Recomende fóruns, blogs, eventos, sites, encontros para nossos ouvintes buscarem conhecimento.
[Walmyr]
Eu recomendo blogs focados em questões culturais tanto quanto focados em questões técnicas sobre qualidade de software. Talking about Testing, o Blog da Taller, portais como Qualidade de Software com uma coleção de blogueiros e pessoas que escrevem sobre o assunto e o blog da ThoughtWorks. Gosto muito de pensar que a informação está acessível no próprio Google ou no Stack Overflow (ferramenta para desenvolvedores procurarem resoluções de problemas), o GitHub para o caso de quando for desenvolver saber se algo parecido já foi criado e pesquisar o que já foi feito antes de sair resolvendo os problemas.
Outra recomendação é o Code Academy, uma plataforma de aprendizagem autônoma onde não há professores. Já conheci crianças que aprenderam a desenvolver por ali, então é uma plataforma muito rica. Tem também o Udemy e redes sociais como o Twitter.
Também é preciso se relacionar com pessoas que falam sobre o que tu quer aprender. Gosto de recomendar também bibliografias, eu estou lendo Clean Code e está mudando a forma como penso em desenvolver código. Clean Coder também que fala sobre o profissional que desenvolve código e sobre a ética por trás disso. Existe muita coisa na internet mas é importante olhar para as referências e ver quem já falou sobre o assunto.
[Viajante]
Até mais Walmyr, agredeço o nosso encontro.
Nosso viajante está satisfeito com a conversa e sentindo-se inebriado com o perfume da caçarola de aspargos, levanta-se e vai até a cozinha para servir-se de um prato do manjar.