QA? Acho que não !

-2

Outro dia participei de uma dinâmica na empresa com vários profissionais na área de Teste. Nessa dinâmica discutimos vários assuntos, mas conforme o papo se desenrolava uma palavra começou a sair com muita frequência e logo me chamou a atenção. Essa palavra sempre me gera certo desconforto, pois na minha opinião ela não faz o menor sentido. Estou falando da modinha “QA”.

Acho irônico pensar que todos no time são responsáveis pela qualidade, sendo que um papel do time se autointitula “QA”, alguém que garante a qualidade.

Não temos controle sobre o orçamento, cronograma, contratações, demissões e na maioria das vezes ao menos temos autoridade para colocar a mão no código. Dito isso, como você pode garantir a qualidade?

Estamos usurpando o gerenciamento das funções e estamos nos preparando como bodes expiatórios, pois se somos as pessoas que garantem a qualidade, quem você acha que vai levar a culpa se qualquer problema sobre a qualidade do produto for encontrado após sua liberação?

GARANTIA DA QUALIDADE É ASSUMIR A RESPONSABILIDADE SEM AUTORIDADE.
- “Jerry Weinberg”

Tester

Eu acho que QA é o papel/termo/cargo/ou da forma que você encarar, mais indefinido. Se você perguntar aqui ou em qualquer lugar, várias pessoas vão dizer que são QAs (seja o papel que realizam ou o cargo que tem na carteira) mas cada um realiza tarefas diferentes.

Eu por exemplo sou QA, as pessoas me chamam assim na empresa, e eu me considero um pouco assim. Porém minhas principais tarefas hoje envolvem implementar os pipelines de Continuous Delivery (isso envolve infra, desenvolvimento e testes) e desenvolver ferramentas que suportem esse processo.

Já trabalhei em alguns modelos, teve uma época que os times não tinham um profissional de testes, os desenvolvedores desenvolviam e testavam (ou não) e a gente tinha muito problema. O modelo não funcionava.

Depois de 2010 a gente começou a falar de agile tester e de ter esse perfil dentro dos times, então fizemos o experimento de ter em cada time devs + testers, funcionou bem melhor do que só ter devs. Nessa época foi praticamente impossível contratar testers que tivessem conhecimento sólido em programação, então a empresa contratou e treinou essas pessoas.

Depois de mais um tempo esse modelo foi se transformando organicamente em times onde todos são capazes de ajudar em todas as tarefas. Mas ainda assim você observa que alguns perfis são mais fortes em algumas pessoas. O desenvolvedor por exemplo não pensa em tantos cenários quanto um testers acaba pensando, e um tester quando pega pra desenvolver talvez não implemente a melhor solução possível. Mas isso tudo é prática, quando mais se executa e desenvolve uma habilidade melhor se você fica.

Concordo em 100% que a qualidade das entregas é responsabilidade de todos que estão envolvidas nela, desde o cliente, analista de negócios, dev, tester, coordenador, etc. Mas ainda assim acho que as pessoas se destacam em determinados papéis, ninguém sabe fazer tudo da melhor forma.

É o tipo de cenário que vejo bastante, os devs aqui que desenvolvem há mais de 5 anos, por exemplo, vão codificar soluções melhores que as minhas, que faço isso a menos tempo. Por outro lado eles tem dificuldades em assuntos como continuous delivery, infrastructure as a code, pensar em diferentes cenários para uma funcionalidade, que são coisas que eu faço com bastante frequência e tenho mais prática.

Na minha opinião pessoal, todo mundo devia ser Analista de Sistemas e fim, mas no mundo real existe bastante essa divisão de papéis ou cargos em empresas de todo mundo.

Samy

@marioramos18 disse:

Acho irônico pensar que todos no time são responsáveis pela qualidade, sendo que um papel do time se e autointitula “QA”, alguém que garante a qualidade.

Todos são responsáveis. Não existe uma pessoa “resolve a parada” Só se ela fizer tudo. Mas ter uma pessoa que pode ser o “incetivador” de qualidade é algo que fica um pouco melhor.
Sobre o título…Na boa, já li “project guru” pelos stackoverflows da vida e isso não representa nada…

@Ramses-Saccol-de-Almeida bem lembrado cara! É uma situação que eu tenho passado essa semana. Peguei pra acertar todos os projetos no Sonar e descobri alguns que estavam com teste unitário quebrando e esses testes não estavam sendo executados em Integração Contínua. Ou seja, estava tendo deploy de novas versões mas tinha teste quebrando só que não estava sendo executado e ninguém tinha percebido. Tinha vários projetos que não estavam gerando cobertura de testes, estavam com plugins desatualizados enfim, alguns detalhes que acabam passando no dia a dia, muitas vezes os caras estão atarefados com as entregas e não se atentam a esses detalhes. Então eu vou lá, acerto e explico e tento ajudar no que puder.

É a mesma questão dos pipelines, estamos migrando do Jenkins para o Go CD, os times de dev não conseguem parar as entregas para fazer esse tipo de migração. Então a gente faz, ensina a usar e a manter.

Samy

-2

@Samanta-Cicilia Respeito sua opinião Samanta, mas não vejo sentido em todos serem Analistas de Sistema. Por que um papel em uma equipe é uma heurística e não uma prisão. Segue alguns exemplos:

  • Se eu sou um desenvolvedor, eu posso fazer teste?
    R: Claro que sim, como desenvolvedor você já faz teste. MAS vc vai ter que aprimorar suas habilidades e lidar com certas deficiências e preconceitos se realmente vc quer fazer um grande teste.

  • Se eu sou um testador, eu posso programar?
    R: Estou certo que sim. MAS se vc fizer isso vai ter adotado, pelo menos que temporariamente a função de desenvolvedor. É difícil vestir dois chapéis ao mesmo tempo.

  • Se eu for um goleiro, eu posso tentar fazer gol?
    R: Não a nenhuma regra contra isso. MAS se você ir para frente a meta do seu time ficará aberta. E a pessoa que abrange o gol no seu lugar não poderá usar as mãos.

  • Se eu sou um zelador, eu posso oferecer sugestões a um CEO?
    Por que não? Mas seu papel não é necessariamente ouvir ou cumprir com as sugestões.

Em uma equipe Ágil é importante manter a “Distância crítica”, que nada mais é que a visão de várias perspectivas. Quando mais o desenvolvedor tentar realizar um grande teste (não falo de meras verificações com resultados facilmente previsíveis e observáveis), mais ele vai se afastar da mentalidade de construtor e vice versa. Não podemos deixar outras funções na equipe tirar nosso foco. Que é encontrar e descrever problemas que podem ameaçar o valor do produto.

Outra coisa, da maneira que você escreve, um tester não pode fazer parte de uma equipe Ágil, ao menos que saiba escrever código. O que tb n faz o menor sentido, n que saber programar n seja uma coisa boa, mas isso está longe de ser a parte central do “teste”. Geralmente isso acontece pq as pessoas n sabem distinguir Verificação de saída (o que é completamente automatizado), do teste (que não é).

Tester

@marioramos18 disse:

Por que um papel em uma equipe é uma heurística e não uma prisão. Segue alguns exemplos:

com certeza não é uma prisão. Eu sempre lembro de um exemplo que meu pai dá, se eu ver um copo sujo no meio da sala que eu trabalho, eu vou pegar e jogar no lixo. Não é porque tem uma pessoa pra fazer isso que eu vou deixa lá. A mesma coisa é no dia a dia, você assume vários papéis, seja desenvolvendo, testando ou especificando.

@marioramos18 disse:

um tester não pode fazer parte de uma equipe Ágil, ao menos que saiba escrever código

eu sou totalmente contra generalizações, como eu citei no texto, dos modelos que eu já trabalhei/trabalho. Aqui (e em algumas empresas que conheço) não tem tester que não desenvolva. Na verdade no exemplo que eu citei da contratação de pessoas que não tinham esse skill pra depois treinar, tivemos casos de testers que saíram da empresa porque não queriam desenvolver. De novo, depende muito do ágil que a empresa faz, porque se voltarmos a falar do caso de que todo mundo é responsável pela qualidade da entrega e que os times tem papéis que podem ser assumidos por qualquer um, inevitavelmente o tester vai desenvolver e o dev vai testar.

Samy

0_1458174517504_belagil.jpg

Na minha visão é só uma questão de interpretação da sigla QA.
Por isso que o mais indicado é TESTER, e tanto que o mundo ágil hoje chama este profissional como Agile TESTER.

Existem vários papéis sim e isso não é ruim…
Seria o mesmo debate porque existe um DBA (Data Base Administrator) se todos de desenvolvimento e infraestrutura trabalham com banco e diversos exemplos que podemos citar por ai.

{ }'s

@marioramos18 disse:

Por que um papel em uma equipe é uma heurística e não uma prisão

Acho irônico pensar que todos no time são responsáveis pela qualidade, sendo que um papel do time se autointitula “QA”, alguém que garante a qualidade.

Não podemos deixar outras funções na equipe tirar nosso foco. Que é encontrar e descrever problemas que podem ameaçar o valor do produto.

Tá, agora me gerou uma confusão. O debate é questão do cargo ou tomamos outro rumo?

0_1458221236542_que_ta_contesendo.jpg

Haha acabei me empolgando e abrangendo um pouco mais as coisas, o que importa é gerar discussão @Ramses-Saccol-de-Almeida

Tester

@marioramos18

Tá. mas a linha inicial era…???

-3

A linha inicial seria parar com essa modinha de QA “Garantia da Qualidade”, pois se vc pensar bem, não é isso que fazemos! Me soa mais como uma necessidade de fazer do teste mais do que ele propriamente é, como uma espécie de “enfeite” que vai deixá-lo mais bonito para outras pessoas. Penso como o @Elias-Nogueira, somos TESTER e ponto.

Tester

@marioramos18 disse:

A linha inicial seria parar com essa modinha de QA “Garantia da Qualidade”, pois se vc pensar bem, não é isso que fazemos! Me soa mais como uma necessidade de fazer do teste mais do que ele propriamente é, como uma espécie de “enfeite” que vai deixá-lo mais bonito para outras pessoas. Penso como o @Elias-Nogueira, somos TESTER e ponto.

Hum, entendi.
Mas ai está um ponto interessante. Quem pode garantir a “qualidade” no final de contas é que “paga” pelo projeto. O nosso papel é , na minha visão, mais acompanhar essa caminhada de qualidade por todo o processo. O ponto de vista da Samanta ilustra bem o que ela faz no serviço dela para isso acontecer.
Quando se tem a disseminação de “fazer bem”, “fazer correto”, “pensar na qualidade”, isso pode virar um hábito em toda estrutura. Em resumo, isso é um enorme trabalho psicológico e um moderado trabalho de aprendizado técnico para seguir.
Esse papo de QA “Garantia de Qualidade”, aposto uma maça podre que é mais papo de quem quer se expor do que gente que faz acontecer. É que nem ler “Rockstar Dev full Stack for entrepreneurs”. Sério, “Bullshit Title” com uma função que todo mundo sabe o que vai ser…
Muita gente compra a embalagem pelo produto…Sabe como é…

Olá,

Na minha pessoal opinião: Quality Assurance Engineer, que é o termo que usamos na minha empresa se refere ao profissional que é Engenheiro em Garantir a Qualidade. Ele vai trabalhar com métricas, processos, ferramentas e vai desenvolver testes também.

Exemplo: Engenheiro Civil: o Engenheiro não constrói o prédio sozinho nem com as próprias mãos mas ele planeja e acompanha a execução!

Logo… um Engenheiro em QA vai se especilizar em abordagens e estratégias de testes e na sua implementação.

Faz sentido pra alguém? =D

Bárbara Cabral

Acredito que QA atualmente é ser um semeador de qualidade, como normalmente um dev tem prazer em criar, nós temos prazer em ver tudo da melhor maneira possível, procurando sempre estar atendendo as expectativas. Mas além disso, penso que como integrantes de times podemos contribuir com muito mais que apenas teste, podemos ver qualidade derivada de alguns aspectos como : integração do time, aprendizado continuo, feedback, comunicação, ou seja, tudo que indiretamente impacta a qualidade, então para mim ser QA, Tester, ou Agile tester é sempre estar de olho no melhor caminho pro produto que o time trabalha.

“Always pass on what you have learned.”

Olá pessoal,

hoje pra mim QA faz mais sentido como sendo uma área, claro que quem trabalha nessa área consequentemente será um Analista de QA, mas vejo a área abrangendo pontos que vão além de testes.

Onde trabalho, por exemplo, a área de QA é responsável por:

  • cuidar do processo de desenvolvimento que as linhas de produto seguem, definindo as práticas de acordo com as certificações da empresa, implantando projetos de melhoria nesse processo (implantação de ágil, de ferramentas de ALM, etc…).
  • definir o processo de testes, sempre revisando como as equipes de teste trabalham, os gaps que a empresa ainda tem em testes (inspeção de código, agile testing, performance, automação, gerenciamento dos testes, etc…) implantando ferramentas, trazendo treinamentos para as equipes, auxiliando em dúvidas de melhores práticas.
  • Cuidar do processo de atendimento ao cliente, que seria a experiência do cliente ao contatar a empresa para suporte, dúvidas e etc. Nessa parte é olhada as ferramentas que auxiliam nesse processo como as de ServiceDesk e URA.
  • Indicadores, onde são acompanhados os indicadores corporativos das equipes que são usados para metas internas.
  • Auditoria, que audita se todos os processos acima definidos estão sendo seguidos pelas equipes.

Dentro dessa área aqui na equipe cada um tem seu foco, eu trabalho com foco em testes, mas vejo que o conjunto de todas essas frentes realmente podemos chamar de Garantia da Qualidade ou até mesmo de Engenharia Corporativa, pois todas visam melhorar o produto e a experiência do cliente com a empresa. Claro que a área em si não consegue “Garantir a qualidade” pois ainda tem muita coisa a ser feita e acho que sempre terá, mas a busca tem que ser contante hehe.

Enfim, sei que nem todas as empresas conseguem ter uma área que cubra todos esses pontos, portanto também não acho errado chamar de QA quem realiza testes pois normalmente são os profissionais de testes que tem uma visão mais voltada para a qualidade. Com o tempo acredito que isso vá mudar totalmente (já está mudando com o ágil sendo cada vez mais usado… ) e a qualidade passará de fato a ser responsabilidade de todos.

Acredito que discutir sobre isso também não vale muito a pena, pois essa questão de nomes de cargos, áreas e funções sempre vão existir em qualquer lugar, não só em empresas de tecnologia.

Valeu galera.

@barbaracabral disse:

Na minha pessoal opinião: Quality Assurance Engineer, que é o termo que usamos na minha empresa se refere ao profissional que é Engenheiro em Garantir a Qualidade

Na minha opinião isso me lembrou isso daqui: “Software Engineer in Test” [By google] =)

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.