The Developers Conference: O Mundo Precisa de QAs Técnicos!

Esse ano tive a oportunidade de apresentar algumas notas e pensamentos no #TDC2012 (The Developers Conferente) que sem dúvidas é um dos maiores eventos para profissionais de software no Brasil. Em primeiro lugar gostaria de agradecer ao Elias Nogueira, Jorge Diz e Leonardo Oliveira que avaliaram minha apresentação, me convidaram para o evento e me deram todo o suporte que eu precisava, parabenizar a Yara, Vinicius Senger e toda a equipe Global Code pelo evento muito bem organizado e pontual, agradecer aos meus amigos ThoughtWorkers que ajudaram na revisão, especialmente Mozair, Babi, Ghisi e Mathias, e claro, agradecer a ThoughtWorks por mais uma vez me enviar a um evento de cinco dias em outro estado com tudo pago :) Provavelmente eu não poderia aceitar o convite do TDC sem esse apoio.

The Developers Conference 2012

No evento eu pude me reencontrar com amigos do teste como Elias, Sarah, Leo Oliveira, Galani e José Correia e pude conhecer outros que não conhecia pessoalmente como o Diz, Cristiano Caetano, Wandi, Eduardo Souza, Alan Correa e Eder Ignatowicz além de conversar com dezenas de outros profissionais de teste de software e ouvir alguns bons feedbacks sobre o blog, sobre o evento e sobre as talks.

Outro ponto muito positivo foi o “Testing Hour” promovido pela Iterasys na Sexta-feira em um bar ao lado da Universidade em que o evento aconteceu, o que promoveu um network legal e uma discussão mais relax sobre diversos temas vistos nas palestras.

O evento contou com números expressivos no número de trilhas, de inscrições e de palestrantes. Uma das coisas que me surpreendeu foi que as trilhas mais cheias e com maiores filas de espera foram as trilhas de Testes e Testes University, o que demonstra um enorme interesse da comunidade de testes, que por incrível que pareça se mostrou muito mais presente do que comunidades conhecidas por lotar eventos e marcarem presença como Agile, Ruby e Java. Parabéns para nós :D

O Mundo Precisa de QAs Técnicos

Essa notícia foi muito boa e bate exatamente com alguns dos problemas que vamos ver abaixo, o que é muito bom, pois esta é uma das provas que estamos mudando esses problemas aos poucos.

Além as trilhas Testes e Testes University eu também biquei as trilhas de Ruby, Dados Abertos e Agile que mantiveram a mesma qualidade das palestras e o alto nível dos palestrantes.

A minha apresentação no TDC teve o título “O Mundo Precisa de QAs Técnicos”. Claro que a apresentação é muito mais baseada no meu ponto de vista e no ponto de vista de muitos profissionais que eu admiro, por tanto muitas pessoas podem e vão discordar de muitos tópicos abaixo, mas acredito que em alguns pontos essas mesmas pessoas vão concordar.

O fato é que o termo tester, QA entre outros relacionados aos profissionais e a área de Qualidade/Teste de software vem sofrendo transformações ao longo dos anos e algumas falácias e estereótipos aparecem junto com a sua popularização. De uma certa forma, como todos os papéis/cargos em informática e computação testes também é uma área nebulosa, e acaba por não ter definições e é sobre esses problemas que falamos nessa talk.

Feedbacks algumas vezes podem machucar :(

Como eu comentei anteriormente, essa talk é um feedback baseado principalmente no meu ponto de vista e em considerações e opiniões de pessoas que eu admiro, não só na área de teste de software, mas de desenvolvimento, negócios, gerência e outras relacionadas ao processo de desenvolvimento de software.

Algumas vezes um feedback pode ser chato por um tempo, mas é importante saber aceitar um feedback para evoluir e melhorar. Esse feedback é um pouco pesado mas se mostrou muito real na mesa redonda que tivemos logo após essa apresentação, onde desenvolvedores e outros profissionais de desenvolvimento puderam nos questionar sobre diversos aspectos, estereótipos e preconceitos discutidos aqui.

É importante ter em mente que eu também sou um Tester e sei o como é ruim aceitar alguns desses problemas e saber que eu também devo melhorar em alguns deles. Outros aspectos como citarei a frente são fatores que influenciaram na minha transformação para QA Técnico.

Eu sinto muito se em algum momento da apresentação ou desse texto você se sinta ofendido, menosprezado, diminuído ou chateado. A intenção não é subjugar nenhum profissional, postura, entidade, certificação ou qualquer outra coisa, mas sim concientizar que temos que mudar algumas das nossas atitudes e talvez repensar alguns dos nossos valores. Fique a vontade para comentar e postar seu ponto de vista ou crítica nesse post, prometo dar atenção especial para ele.

O que muitas pessoas pensam quando falamos em QAs Técnicos?

Programador que testa

Quando falamos de testers técnicos alguns estereótipos vem a mente. O mais comum, acredito eu, é o desenvolvedor que testa ou o testador que não entende nada de testes manuais/exploratórios, mas basicamente coda dia e noite para testar. Nenhum dos dois é um QA técnico, por dois motivos. Primeiro porque para ser um QA você deve pensar como um QA e isso é algo que os developers não fazem a maior parte do tempo. Segundo porque ser técnico não é saber automatizar tudo, mas sim saber decidir qual a melhor abordagem de testes deve ser tomada para cada situação e saber usar de diferentes recursos para melhorar o seu trabalho de QA.

Um desenvolvedor que testa um bom desenvolvedor e esses fazem tanta falta quanto os QAs Técnicos.

TDD e BDD?

Apesar de já terem se passado longos anos que o TDD e o BDD foram criados, referenciados e incluídos na vida de desenvolvedores, testers e demais membros de projetos de desenvolvimento de software, essas sopas de letrinhas tem se tornado cada vez mais comuns e não é raro escutar em entrevistas e listas de discussões que um QA deve saber desenvolver esse tipo de testes.

Muito se discute sobre isso e cada ponto de vista tem o seu valor, na minha opinião isso não está errado e um tester deve sim saber como essas abordagens de desenvolvimento funcionam e quando elas devem ser usadas, mas definitivamente aplicar/conhecer/codar TDD e BDD não tornam um QA em um QA técnico.

Certificados e Cursos

Novamente, ser técnico não é saber codar, mas fazer da tecnologia um aliado para aumentar a eficiência e acurácia das atividades de teste.

Um terceiro item muito comentado são os cursos/pós graduações, certificações ou treinamentos que prometei torná-lo um QA técnico. Todo investimento é bem vindo e efetivamente um bom curso ou certificação pode ajudar muito no processo de transformação em QA técnico, o que aconteceu comigo por exemplo, mas é muito importante saber que nenhum curso ou certificação vai por si só tornar um QA em Técnico ou garantir para uma empresa que ele é esse QA tão diferenciado.

“No Pain, no Gain”, temos que trabalhar, estudar e entender os valores que esses materiais nos oferecem e tirar proveito deles ao máximo, mas temos que saber que muitas vezes temos que buscar conhecimento em lugares muito menos concretos do que referências bibliográficas e treinamentos de empresas “especializadas” em teste de software.

Alguns exemplos do que está no Dia a Dia de um QA Técnico

Integração Continua Fonte: http://fabiopereira.me/blog/

Continuous Integration

Integração continua é um termo desconhecido para muitos QA (talvez a maioria) e também para boa parte dos desenvolvedores, mas é algo que eu não consigo pensar em não ter em um projeto, por mais simples e curto que ele seja.

A integração contínua foi tema da palestra “Integração Contínua com Testes Automatizados” do João Enomoto e do Julien Renaut na trilha de testes e em várias palestras de ALM e Open ALM.

Resumindo essas TVs são usadas para monitorar a saúde do projeto o tempo todo, e sempre ficam disponíveis para que todos os envolvidos no projeto possam entender como o projeto está atualmente. Para cada vez que o repositório for alterado, uma sequência de testes automatizados são disparados, gerando um feedback muito rápido para todo o time. Esses testes não são somente testes de unidade, mas testes funcionais, testes de performance, de segurança, de ambiente, serviços externos e quaisquer outros testes automatizáveis que a equipe considerar importantes.

Github

Social Coding

O github.com é uma rede social para pessoas que acompanham ferramentas open-source, frameworks de desenvolvimento/testes e serviços. Não é uma rede exclusiva para desenvolvedores, mas muito pelo contrário, o número de QAs/Testers envolvidos em projetos open source e commitando projetos pessoais e dicas de automação e testes técnicos no gitbug é cada vez maior.

Ter uma conta no github e compartilhar conteúdo não só ajuda a entender mais de código e teste automatizado, como fortalece o network com empresas mais engajadas com open-source (todas essas no top coderwall http://coderwall.com/leaderboard), como também ajuda a entender melhor gestão de configuração, automação de tarefas e ambiente (o que ajuda muito um QA) e a manter-se atualizado sobre novas soluções cada vez mais simples para automação de testes funcionais.

Carro de um possível QA Técnico

Security Testing

Nenhum QA deve ser um super hacker que poderia ficar rico desviando dezenas de milhares de dólares de oito bancos diferentes sem ser percebido, nem precisa saber como invadir o Google ou a NASA, mas sem dúvidas todo QA Técnico experiente deve saber o básico sobre testes de segurança, conteúdo muito bem abordado pela palestra “Testes de Requisitos não funcionais” do Wanderlei Souza.

Saber como SQL Injections e Ataques XSS funcionam e como avaliar se aplicação está vulnerável a esse tipo de ataque é algo perfeitamente possível para um QA com dois anos de experiência com aplicações web. Saber como um zip bomb funciona, como validar DoS usando Billion Laughs Attack e como mudar valores em requisições http também são tarefas que um QA pode conhecer, além de claro saber ler, interpretar e simplificar logs e registros de aplicações e ambientes.

Conhecer esses conceitos e técnicas amplia muito o universo de teste e podem ajudar inclusive a pensar em cenários mais específicos de testes funcionáis.

Performance Testing Fonte: http://www.rttsweb.com/services/implementation/ performance/packages/

Performance Testing

Tema também abordado na palestra “Teste de Performance no contexto de uma aplicação de Nota Fiscal Eletrônica” do Alan Correa.

Hoje todos os projetos web e mobile precisam de performance. Nenhuma startup gostaria de ver sua ideia genial ir por agua abaixo por falta de planejamento da equipe de desenvolvimento e ao mesmo tempo grandes bancos, jornais e empresas precisam de páginas cada vez mais rápidas e estáveis. Existem poucos profissionais no mercado que realmente dominam performance/testes de performance e cada vez mais projetos precisando desses profissionais.

O Jmeter é uma solução open source que atende perfeitamente a projetos que precisam de testes de performance e existem dezenas de referências e tutoriais de uso para ele. Ao aprender um pouco mais sobre Jmeter e testes de performance o QA acaba aprendendo também bastante sobre segurança, requisições HTTP e como uma app cliente servidor funciona, o que também aumenta os horizontes de teste e ajuda a pensar em novos cenários mais sofisticados para testes funcionais.

Eye Tracking - Fonte: http://johnnyholland.org/2009/10/ux-an-art-in-search-of-a-methodology/

Usability Testing

Testes de usabilidade e acessibilidade também tem sido uma preocupação crescente em empresas privadas e no setor publico. Portadores de necessidades especiais cada vez mais tem o acesso facilitado na internet e muitas empresas precisam que essas pessoas estejam habilitadas a navegar confortavelmente em suas aplicações. Outro fator motivacional é que o seu trabalho com esse tipo de teste está ajudando essas pessoas que tanto precisam de facilidades no acesso a informação e a sensação de lançar um produto 100% compatível com essas necessidades especiais deve ser muito gratificante :)

Ao mesmo tempo outros mercados como o de marketing estão procurando profissionais habilitados com essas skills e isso pode ser um leque de oportunidades mesmo fora da área de desenvolvimento de software.

Esses foram alguns exemplos, mas muitos outros igualmente importantes não foram citados. Como comentei, nenhum QA deve ser “o senhor dos requisitos não funcionais”, o “mago do github” ou hacker mais conhecido do mundo, mas deve conhecer um pouco de cada uma dessas áreas para se tornar um profissional mais capacitado e preparado para desafios de um projeto.

Por que precisamos de QAs Técnicos?

Abaixo eu vou descrever alguns cenários que eu vejo e algumas situações que eu vivi antes de decidir me tornar um QA técnico e quero deixar bem claro que não tenho nenhum preconceito e que os slides abaixo não devem ser lidos sem o contexto descrito junto deles, pois podem facilmente passar uma ideia diferente da que eu quero passar, especialmente o terceiro.

Não entendi :(

Falta de Conhecimento Técnico para argumentação

Eu já passei por algumas situações muito frustrantes e desagradáveis por falta de conhecimento técnico, mas uma se destaca. Era muito ruim quando eu saia de uma reunião de uma hora ou mais e não sabia fazer um resumo do que tinha sido discutido. Muitas vezes a sopa de letras me confundia e em outras eu me perdia em conceitos e detalhes técnicos.

Mas o pior era quando algum tempo depois de uma dessas reuniões a consequência (normalmente um problema grave) vinha a tona, e eu finalmente entendia o que tinha sido discutido. Então eu percebia que se eu soubesse desses detalhes técnicos alguns meses atrás eu poderia ter ajudado a evitá-los e hoje não seriam preocupações do projeto.

Diferentes pontos de vista

Ver com olhos técnicos 

Perdi a conta de quantas vezes eu já discuti com um desenvolvedor/arquiteto/analista de requisitos, ou mesmo com testadores mais experientes e mantive a minha posição firme durante horas ou dias, e depois de algum tempo eu percebi que na verdade eu estava errado.

É fundamental que um QA saiba olhar em diferentes pontos de vista, desde o olhar do crítico do produto, passando pela visão do cliente e claro, pela visão técnica. Ter conhecimento o suficiente para entender esses pontos de vista não só é importante para evitar esses erros muito comuns, como também para ajudar o desenvolvedor ou arquiteto a entender o nosso e fortalecer nossos argumentos quanto buscamos inovar em qualidade ou justificar algum teste específico.

Visão distorcida do mercado

Visão distorcida do mercado

Eu não apoio nem acredito que esse é um modelo correto, muito pelo contrário, eu tenho convicção que o meu papel em um projeto de desenvolvimento de software onde qualidade é um diferencial, é tão importante quanto o dos desenvolvedores e demais membros do time, mas eu devo admitir que hoje esse cenário é comum em empresas e até mesmo alguns “profissionais” de teste pensam assim.

O  “plano de carreira” que podemos dizer que é “comum” no Brasil é um universitário contratado como testador/analista de testes ou analista de infra-estrutura normalmente como estagiário, depois de formado ele é contratado como desenvolvedor, promovido para arquiteto ou analista de negócios e depois de vários anos ele se torna um gerente de projetos. Podemos ver isso contando nos dedos os desenvolvedores com mais de vinte anos de experiência e que ainda são desenvolvedores, mas é muito comum que profissionais com esse perfil tenha se tornado gerente de projetos. O mesmo para QAs com mais de cinco anos de experiência, a maioria se torna gerente de testes.

Pagamento e reconhecimento inferiores

Claro que alinhado a esse plano de carreira, vem uma diferenciação salarial, onde os cargos “menos preparados” como Analista de teste/testador, suporte e analista/técnico de infraestrutura ganham muito menos do que profissionais “mais capacitados” como arquitetos e desenvolvedores ou com “mais responsabilidade” como analistas de requisitos/negócios ou gerentes de projetos.

Como disse anteriormente, não acho justo que um profissional que ama destruir aplicações, testar performance, garantir segurança e economizar muito dinheiro ganhe menos e seja menos reconhecido do que os demais profissionais, ao mesmo tempo não é nem um pouco produtivo para um excelente testador ou desenvolvedor, que ama ser técnico e colocar a mão na massa, deixar de ser técnico só para  ganhar um aumento salarial.

Pesquisa salarial

Infelizmente não tenho dados que  comprovem a “teoria da conspiração” citada acima, mas realizei uma pesquisa em três fontes diferentes e confiáveis, com escopos diferentes, mas em todas elas a tendência acompanhava a escada e a diferença entre o salario de um analista de testes sênior e um gerente de projetos chegava a ser de quase quatro vezes.

Fonte:

Perdendo credibilidade

Perda de credibilidade

Existem duas formas de perceber uma pessoa. Todos nós que trabalhamos na área a algum tempo e que por ventura fazemos entrevistas e participamos de eventos etc., sabemos que algumas pessoas se vendem muito bem, e algumas buzzwords, alguns cursos e certificações são aliados dessas pessoas.

Muita gente se capacita de verdade ao tirar uma certificação ou ao fazer um curso de pós graduação em teste de software, mas muitos profissionais acomodados tem tirado uma ou duas certificações e cursos relativamente baratos para rechear o currículo, aproveitando que é muito complicado testar um QA. Ao mesmo tempo entidades gananciosas se aproveitam de pessoas ingênuas para vender processos e livros antigos como estado da arte, gerando um número gigantesco de QAs com mentalidade de tester de tela de cadastro todos os anos.

Com isso, dezenas de pessoas que trabalham com cada um desses profissionais, tem uma péssima experiência com esses QAs “super capacitados”, o que acarreta essa perda de credibilidade que enfrentamos hoje. Ao mesmo tempo a maioria das empresas “rockstar”, não se importam com certificações, MBAs ou cursos de curta duração na área de teste de software, pois o que temos hoje não condiz com o que eles precisam/acreditam.

Quais as consequencias da ausencia de QAs Técnicos

Ganhamos rótulos que não merecemos

Agora tenho que ser tester :(

Já ouvi vários jargões por não ser técnico, e um dos que mais me chateou é o famoso “Se ele é tester é porque não aprendeu a programar na faculdade“. Essa impressão que causamos em algumas pessoas se deve a fatores como os retratados anteriormente, onde muitas empresas que não se importam com qualidade contratam pessoas sem qualificação para teste de software e muitas vezes as “promovem” para um papel “mais nobre” quando conseguem alguma qualificação. Claro que esse efeito é potencializado por pessoas que efetivamente não tem interesse em estudar e se qualificar e acreditam que testers realmente não devem saber programar, mas esse não é o mais comum hoje em dia.

Mudar esse tipo de mentalidade é uma missão de cada um de nós, mostrando que não somos QA simplesmente porque temos alguma deficiência técnica, porque nos frustramos em algum ponto da nossa carreira em computação ou porque somos preguiçosos, mas porque acreditamos que a qualidade do produto é algo importante para o cliente e para a equipe e que nós podemos com o nosso ponto de vista diferente criar um ambiente mais dinâmico e  confortável para a equipe e redução de custo e tempo para o cliente através do aumento da qualidade.

Tester chato!

Testers são chatos e não tem noção de importância e prioridade

Muitos dos nossos jargões e práticas como “Todos os bugs devem ser resolvidos”, “temos que testar tudo” ou “não vamos entregar antes de detalhes do layout funcionarem no netscape 0.3 do windows 98″ colaboram para isso.

Quando falamos técnicos, como citado anteriormente, não estamos falando de saber codar ou de estar apto a substituir um developer, mas sobre entender as diferentes situações e tomar decisões mais coerentes e estar verdadeiramente apto a implementa-las. Dessa forma, um QA mais técnico entende conceitos como Fail Fast, Lean Startup e principalmente a adaptar sua forma de trabalho para os valores do cliente, da empresa e principalmente do time de desenvolvimento (o time envolve o PO e stakeholders  do cliente). O time deve se sentir confortável, confiante e mais produtivo com a ajuda de um QA/Tester, não faz sentido ter uma pessoa no time que empurra o time para baixo e o torna mais lento. Mais qualidade != mais devagar, a qualidade significa redução de custo e tempo em software.

Monkey Tester

Macaquinos que testam

Nota: O contexto sobre macaquinhos refere-se ao estereótipo atribuído a testadores que só executam testes manuais seguindo scripts e não é e nem deve em nenhuma hipótese ser atribuído a racismo ou preconceito.

O pior e mais comum estereótipo que ganhamos ao longo do tempo, o famoso macaquinho de teste. Esses estereótipo também é reflexo da nossa cultura de assimilar pessoas sem experiência e capacitação para serem QAs/Testers em empresas sem qualidade, e de criar essa mentalidade de que sempre temos que cadastrar todos os detalhes e chatear as pessoas sobre isso.

A postura extremamente defensiva de alguns escritores/profissionais conceituados e até algumas entidades de teste e certificações sobre testadores serem pessoas focadas em testes manuais baseados em requisitos definidos em fases anteriores, é no meu ponto de vista, a principal responsável por esse estereótipo. Software não é algo que possa ser desenvolvido seguindo uma receita e muito menos testado dessa forma. Cada pedaço de software foi desenvolvido com um propósito e com um valor esperado para o cliente que não pode ser detalhado com técnicas simples de teste de software, mas sim com pessoas motivadas e capacitadas para entender o problema e propor ações para avaliar se as soluções desenvolvidas vão atender aos problemas com o valor esperado. Nem sempre teste manual é a opção mais produtiva, barata ou recomendada.

Alternativas ao QA Técnico

O mercado está buscando alternativas

Acho que muita gente que participa do DFTestes e de outras listas viu a confusão que uma palestra chamada “O Teste está Morto” apresentada pelo Goolger Alberto Savoia no Google Testing Automation Conference causou. Para quem não presenciou, a palestra basicamente falava que a mentalidade dos QAs deve mudar e ela foi uma das inspirações para essa minha apresentação, mas ao contrário do que eu escrevi, ele não cita em nenhum momento automação ou testes mais sofisticados, só que o teste deve focar no valor. Mas por ser uma palestra com um nome forte e por ser de um evento que possuía os nomes “Google” e “Automation” acabou gerando muito barulho por parte de pessoas mais defensivas.

A palestra do Fred George sobre como a Foward, uma empresa de desenvolvido apenas com desenvolvedores causou menos barulho que a do Savoia, mas é ainda mais ousada, pois não falou que os QAs tinham que mudar de mentalidade, mas que eles não são necessários quando os developers são qualificados e comprometidos com a qualidade. Outro indicador que estamos sem QAs técnicos é que a cada dia encontramos mais e mais cargos como Software Developer in Test ou outros developers focam em teste, que muitas vezes são contratados por empresas com sérias restrições de qualidade e ambientes que mudam com frequência, onde testes automatizados são importantes redutores de risco e abordagens manuais podem ser muito custosas e falhas.

O Devops não é uma alternativa ao QA, mas ele toma hoje boa parte do que um QA técnico poderia fazer em um projeto, como cuidar dos ambientes, automatizar rotinas e responsabilidades sobre os servidores de integração continua, etc.

Como podemos mudar isso? Como podemos evoluir como QAs Técnicos?

Um velho ditado diz que só o peixe morto vai com a corrente e isso não deixa de ser verdade para nós. Tornar-se um QA técnico não é algo que podemos fazer com um plano de curto prazo ou com um curso ou certificação como dito anteriormente. Nem sempre a empresa em que trabalhamos ve valor nesse tipo de QA e muitas vezes você não estará apto a exercer atividades de um QA técnico nessa empresa, então esteja preparado para estudar em casa e se for mais animado participar de projetos crowd sourced ou sociais/open source na internet. De qualquer forma, aqui vão algumas dicas sobre como pode aos poucos desenvolver mais skills técnicas como QA:

Livros são seu guia

Leia, leia e leia mais um pouco depois

Procure livros recentes, sobre conceitos novos implementados em empresas conhecidas por sua qualidade. Evite o pensamento que a maioria das empresas estão procurando abordagens ultrapassadas e não dão valor para isso, entenda o que é melhor e o que encaixa nos seus valores e seja um transformador. Aprenda a implementar esses novos conceitos, estude-os, entenda os problemas da sua empresa e busque implementar as soluções mais adequadas  aos poucos, e muitas delas podem estar nesses livros.

Mostre o valor com o dia a dia. Nenhuma pessoa sensata quer mudar toda a empresa de um dia para o outro e também não será convencida a começar uma mudança organizacional simplesmente por cause de uma talk ou de um livro dizendo que isso vai resolver o problema. Entenda o conceito de baby steps para transformação organizacional e inicie as mudanças na sua empresa mostrando o valor de pequenas mudanças e aos poucos vai conseguindo transformar. Qualifique seus amigos, especialmente os QAs.

Aprenda a programar

Aprenda a programar

Programar não é a coisa mais complicada do mundo e como todas as coisas complexas do mundo, você vai ficando melhor e entendendo muito mais rápido quando pratica.

Durante o TDC eu usei a analogia de dirigir um carro (e muito provavelmente alguém já usou isso também). Me lembro que a primeira vez que eu olhei para o carro falei “Marcha, setas, volantes, embreagem, retrovisores e painel ao mesmo tempo? Sem chance…”, aquilo parecia muito complexo, mas depois de algumas aulas as coisas pareciam menos complexas e aos poucos eu fui entendendo como controlar. Com programação é a mesma coisa. No início, configurar as variáveis de ambiente do Java é algo estranho, depois entender como uma class funciona, IDEs etc. Eu estaria mentindo se dissesse que vai desenvolver qualquer coisa em um mês, mas com toda a certeza qualquer ambiente ou linguagem deixa de ser um monstro logo no primeiro mês de estudo.

Traga isso para o seu dia a dia, converse com algum desenvolvedor da sua empresa e demonstre mais interesse, peça algumas dicas e estude em casa. Conhecer uma linguagem de programação pode ser o primeiro passo para tornar o seu trabalho muito mais simples, diferenciado e profissional.

Ferramentas de teste

What is up in software testing?

Você já lê muito sobre os novos conceitos e sobre práticas e experiências, porque não entender sobre as novas e velhas ferramentas que cercam esses conceitos?

Estudar ferramentas usadas por empresas de alta qualidade podem abrir muitas oportunidades, além de ajuda na implementação de conceitos do Agile, Continuous Delivery, Specification by Example e tantos outros. Ferramentas open source também estão mais acessíveis do que nunca através do github, google code, bitbucked, redes sociais e tantas outras ferramentas de comunicação e compartilhamento. Sugerir mudanças e adaptações ou mesmo desenvolver essas mudanças pode gerar funcionalidades novas e mais produtivas para todos, ajudar no network e criar novas oportunidades.

Entender das ferramentas dos desenvolvedores também ajuda a melhorar os mecanismos de teste de baixo nível, além de criar uma atmosfera colaborativa no time e de mudar a imagem de QA Manual para a equipe de desenvolvimento.

Requisitos não funcionais

Aprenda mais sobre arquitetura e requisitos não funcionais

Qualquer testador que estude arquitetura e requisitos não funcionais se tornam testadores muito melhor do que quando não conhecia. Afirmo isso com tanta convicção pois além de saber como quebrar o negócio o testador que entende quais as tecnologias estão suportando o negócio, ele consegue ser mais efetivo e  encontrar problemas arquiteturais que podem interferir no negócio, como segurança, performance, usabilidade, portabilidade, etc.

Além disso, como citado pelo Wandi na palestra durante o TDC, os maiores salários e reconhecimentos na nossa área estão mais concentrados nos profissionais que dominam os testes baseados na arquitetura e nos requisitos não puramente funcionais.

Entenda os diferentes processos

Entenda os diferentes processos e quando usar o que

Como QAs, sabemos que não devemos encontrar defeitos, mas sim fazer o possível para que eles não existam, portanto trabalhar de forma reativa testando a aplicação depois que ela está desenvolvida não deve ser nosso objetivo principal. Entender os diferentes modelos de desenvolvimento de software e como extrair o melhor de cada um é uma maneira de buscar qualidade para o projeto e evitar esse tipo de abordagem reativa aos defeitos.

É importante saber também que apesar dos milhares de evangelistas de waterfall, rup, agile e tantas outras metodologias de desenvolvimento de software que temos no mercado e na academia, nenhuma contem as ferramentas e práticas para resolver todos os problemas em todos os projetos, e algumas vezes temos que usar mais de uma ou de outra, dependendo da empresa que estamos, do modelo adotado pelo cliente e pelas restrições que o projeto possui.

Integração continua

Integração Continua

Integração continua é a ferramenta básica de suporte a qualquer equipe de desenvolvimento. Sem ela a equipe não sabe se está mantendo o nível de qualidade, os testadores tem que trabalhar muito mais em testes manuais repetitivos e o deploy se torna um evento aterrorizante para o cliente, para o seu time e principalmente para você, que se torna o centro das atenções (pra não dizer alvo) nesse momento.

Ter um mordomo lembrando a equipe de manter o código bem testado, de validar o ambiente e de testar todas as funcionalidades desenvolvidas até o ultimo commit é uma das coisas que torna um QA mais produtivo e motivado. Não existem testes manuais de regressão, o deploy é algo planejado desde o primeiro dia, nenhuma mudança em uma funcionalidade ou alguma nova feature vai bagunçar com tudo que já foi desenvolvido, nenhuma “tela” vai chegar com o principal fluxo quebrado, entre outras das centenas de vantagens que uma ferramenta de CI proporciona para o time e principalmente para o QA.

Conheça diferentes plataformas

Domine diferentes sistemas operacionais

Eu sei que o Windows é confortável, que o Mac é hipster e que o Linux é código aberto e que cada um deles deve ter algumas outras centenas de razões para serem amados e únicos na vida de cada um de nós, mas cada um possui seus pontos fortes e você não pode prever se o seu próximo cliente precisa de um QA que domine Linux ou se o seu projeto vai te obrigar a usar Mac para desenvolvimento mobile e nem se sua plataforma de desenvolvimento será .Net, logo Windows.

Aprenda um pouco de cada um. Entenda quais as facilidades existem para desenvolvedores e testadores em sistemas Unix Based como Linux e Mac OS, conheça as IDEs e ferramentas que só funcionam no Windows. Não somos usuários e por isso não podemos nos dar ao luxo de ficar confortável no sistema operacional que mais gostamos.

Aprenda e compartilhe

Aprenda e compartilhe com quem realmente faz!

Livros são importantes, certificações podem nos ajudar a entender melhor alguns conceitos, a faculdade nos dá a base para aprender e abre várias oportunidades, mas nada disso supera o poder da comunidade.

Somos nós que trabalhamos todos os dias com tudo isso é que sabemos como o bixo pega no dia a dia. Somos nós que temos prazos apertados, que temos clientes ligando e pedindo pra “testar mais rápido” e que sofremos pra implementar uma ferramenta nova. Não devemos subestimar o conhecimento dos nossos colegas de profissão e devemos extrair o máximo deles.

Quando possível devemos compartilhar o que aprendemos ou o que descobrimos, ajudando outros QAs com as mesmas dúvidas/problemas que tivemos, dessa forma podemos conhecer e discutir outras abordagens de teste e evoluímos como comunidade e não somente como individuo.

É muito importante saber que por melhor QA que você seja sozinho, você sempre terá uma ligação com a comunidade e seus problemas e que evoluir sem compartilhar vai te trazer menos benefícios do que se a comunidade evoluir junto.

Vamos fazer?

 Vamos fazer?

O principal objetivo dessa talk não era falar sobre como o papel de QA no Brasil está ruim, mas que a cada dia novas oportunidades aparecem e que precisamos melhorar como comunidade e como profissionais.

Acho muito interessante o blog do Elias. O Elias é hoje provavelmente a principal referência técnica em QA atuando no Brasil, e é muito legal ver que no blog dele, em março de 2007 (nem é tanto tempo assim) ele escreveu um post dizendo que estava começando na “área de testes e qualidade”. Hoje, pouco mais de cinco anos depois ele é uma referência, conheceu realidades diferentes, provavelmente defendeu ideias que não concorda hoje ou mesmo pratica alguma coisa que a algum tempo julgava errada ou desnecessária, mas o mais importante é que ele se reciclou aos poucos, compartilhou o que aprendeu, reconheceu os erros que cometeu e ajudou as pessoas a entender os acertos.

O mesmo aconteceu para muitos dos outros profissionais que são também são exemplos para todos nós. O que todos eles tem em comum é que eles não disseram “eu não quero aprender isso ou aquilo”, mas sim “eu vou aprender e isso pode me fazer melhor como QA”.

A figura desse slide mostra diferentes estágios para tudo na nossa vida. Aonde estamos para aprender mais sobre teste técnico? Falamos que queremos aprender ou estamos realmente aprendendo? Realmente não podemos aprender ou essa barreira é apenas uma limitação que nós mesmos colocamos na nossa frente?

Feedback

Feedback me!

Ninguém é dono da verdade e eu não pretendo que ninguém concorde com tudo que está escrito neste post e muito menos neste blog, mas eu sinceramente espero que algo positivo possa ser tirado deste e de outros posts para cada um que ler aqui e ficarei muito feliz ao receber o seu feedback para melhorar como escritor e como profissional.

Ao longo desses anos como profissional eu pude notar o como eu mudei e depois de começar a escrever eu pude perceber isso de uma forma mais explicita ainda. Todos os dias repensamos nossas práticas, valores e conceitos, e muitas vezes mudamos sutilmente de pensamento sobre muitos deles, principalmente sob influencia do meio em que estamos inseridos e das experiências proporcionadas por esses meios. Eu fui um testador e desenvolvedor, implementei CMMi até o nível 5 e hoje acredito que ágil é a melhor forma de ter qualidade, defendi os trackers de defeitos e hoje sempre que possível resolvo o defeito na hora com os devs, tirei quatro certificações e não acredito nelas mais, era Windows hard user e atualmente não consigo viver sem meu Mac e meu Ubuntu. Muito disso graças aos inúmeros feedbacks que eu recebi ao longo da minha carreira e muitos deles foram por causa deste blog :) Portanto, se tem um feedback positivo ou negativo, saiba que ele será muito bem vindo.

Não quero que ninguém perca o seu trabalho, nem que as pessoas leiam esse post e digam “Poxa… tô ferrado”. Como eu disse acima, ninguém deve tentar ser o melhor amanhã, mas sem dúvida deve ser melhor hoje do que ontem. Reconhecer que temos que melhorar pode ser um primeiro passo para melhorar, um segundo passo pode ser aprender uma coisa nova por dia e entender que esse objetivo está longe de ser uma meta inalcançável, mas na verdade é uma das melhores formas de tornar o trabalho mais prazeroso.

Bons testes :)

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

10 thoughts on “The Developers Conference: O Mundo Precisa de QAs Técnicos!

  1. Olas!

    Em primeiro lugar parabéns pela post e pela Palestra no TDC 2012! Eu estava lá e realmente foi muito muito bacana.

    Em segundo lugar, eu concordo totalmente com a necessidade de testadores/QA etc que entendam de computação, não somente de desenvolvimento, como você pontuou neste post. Uma grande dificuldade na minha equipe é encontrar pessoas que possam dar suporte a todos os tipos de testes que precisamos.

    Abraços,

    Alan.

  2. Parabens pelo post cara…
    Vc contribui muito e com qualidade a nossa comunidade…

    Obrigado and keep on the good work.

    Abraço,
    Thiago Felipe Peçanha

  3. Parabéns Camilo,

    Acompanho seu blog e a discussão no DFTestes e você sem contribui com muita propriedade e conhecimento para a comunidade.
    Eu me identifiquei com vários pontos da sua apresentação e realmente tive que mudar justamente para agregar valor para a empresa e não ser uma dor de cabeça para a equipe do projeto.
    Já tentei automatizar tudo sem planejamento, criar casos de testes para tudo, cadastrar bug cosmetic pra mostrar que era importante, etc… e vi que para cada caso deve-se avaliar a melhor solução e buscar sempre o melhor custo/benefício para o projeto.

    A única coisa que eu acredito que um QA técnico também pode ajudar a equipe é a revisão de código/arquitetura. Na empresa onde trabalho, temos 3 equipes de desenvolvimento distintas e temos que cobrar um padrão de código (senão vira bagunça e cada equipe coda de seu jeito. Imagina a manutenção disso!), entre elas cito: OO, desenvolvimento em camadas, documentação, tratamento de exceções, etc…
    Claro que temos alguns plugins que nos ajudam a avaliar o código e que também devs experientes já codificam com poucos problemas, mas já pegamos muitos trechos de códigos bizarros e em conversa com os devs melhoramos a app como um todo…

    Abraços
    Eduardo.

  4. Hey Camilo! Levei 2 noites de folga de trabalhadora + mamãe para ler esse teu post, hehe, mas valeu a pena! Vários dos teus pontos me fizeram balançar positivamente a cabeça, outros a refletir “hum, é… Talvez ele tenha razão” e poucos foram o que eu poderia dizer que discordo – e devo confessar que minha expectativa antes de começar a ler é que eu teria mais pedras para atirar sobre o tema que na verdade foi muito bem abordado por ti. Queria poder discutir o assunto ao vivo – sim, isso é um convite ou, se preferires, uma intimação ;) -, acho que vai ser legal falarmos de vários desses pontos sabidos mas pouco discutidos.

  5. primeiramente, parabéns pelo texto!

    concordo com a ideia de que o pessoal envolvido no teste tem que deixar de lado o medo de tocar em um código fonte. Isso só menospreza as pessoas que trabalham com QA e acaba criando a fama do macaco apertador de botão.

    o ponto sobre o feedback é extremamente importante, mas nada adianta se a mentalidade e a cultura de quem está recebendo não mudar. Quem tem que querer fazer a mudança do macaco apertador de botão para o cara que poderá ajudar a entregar um produto que vai agregar o cliente é o próprio QA/Tester/Analista de teste…

    hj posso dizer que já comecei a minha caminhada para ser, um dia quem sabe??, um QA técnico e me vejo em algumas coisas que tu citou.

    cara, novamente, parabéns pela abordagem e pela forma que abordou… e espero que teu texto sirva de reflexão para muitos profissionais.
    :)

  6. Olá Paulo,

    Muito obrigado pelo comentário e pelos elogios.

    Sair da zona de conforto de testador e encarar os desafios que testes automatizados proporcionam é um pouco cansativo e exige muito estudo e força de vontade sim, mas ao mesmo tempo torna o nosso trabalho mais dinâmico, simples e criativo do que executar testes sequenciais.

    Fico muito feliz de compartilhar um pouco dos pensamentos aqui do blog, e tenho certeza que vai conseguir chegar aonde quer :)

    Novamente obrigado pelo comentário e sinta-se a vontade para sugerir melhorias ou tópicos para posts futuros.

    Abraços,

    Camilo

  7. Muito obrigado Thiago,

    Fico muito feliz com comentários como o teu :) Sinto que a missão está sendo cumprida.

    Fique a vontade para ajudar a melhorar ainda mais a qualidade dos posts aqui mandando o seu feedback.

    Abraços,

    Camilo

  8. Olá Eduardo,

    Primeiramente muito obrigado pelo comentário e pelo feedback. Fico muito feliz que tenha essa visão sobre o post e sobre as contribuições.

    Sinto muita experiência no seu comentário. Assim como você, eu já fortaleci muitos desses estereótipos, e hoje entendo muito bem porque cada um deles impacta no nosso mercado e na forma como os demais papeis do desenvolvimento de software tem visões muitas vezes destorcidas do QA/Tester.

    Eu vejo que estamos falando muito disso nos ultimos tempos, em palestras, forums, listas, artigos e etc. Eu tenho certeza que muitos QAs estão mudando assim como nós mudamos.

    Obrigado por lembrar da revisão de código e por colaborar aqui no bugbang.

    Fique a vontade para visitar o blog e colaborar nos posts sempre que quiser. Envie também suas notas e feedbacks para ajudar a alinhar os assuntos discutidos aqui e melhorar a qualidade dos posts também.

    Abraços,

    Camilo

  9. Olá Alan,

    Foi um prazer conhecer você :D

    Eu acho que blogs como o teu, com foco totalmente técnico em português são um combustível e tanto para ajudar na transformação que esperamos do mercado e da postura dos QAs/Testers.

    Continue com essa iniciativa e postura de estar sempre aberto para compartilhar conhecimento e conte comigo para o que precisar.

    Abraços,

    Camilo

  10. Parabéns! Mesmo depois de tanto tempo seu artigo continua na atualidade. Pela primeira vez vejo alguém abordar algo tão polêmico e mandar muito bem! Parabéns pelo artigo e pela humildade.

Leave a Reply