O papel do QA em um ambiente devops. Vamos falar sobre isso?

Ainda muito comum nas empresas de desenvolvimento de software, o processo de desenvolvimento estrutural ou em espiral usado é uma forma de criar bloqueios entre as equipes desse setor, operacionais e de controle de qualidade, gerando um “engessamento” no processo e dificuldades de comunicação; em algumas vezes até mesmo criando ruídos e prejuízo na convivência diária. Além de um nível preocupante de estresse diário, o alto risco nas entregas das atividades é um fator fundamental para as tentativas de resolver essas barreiras

Com o surgimento da metodologia ágil, as coisas tomaram outro rumo. Com a necessidade de minimizar riscos e custos associados aos problemas durante o desenvolvimento de software, o método vem com o propósito de uma melhor integração entre as equipes e um “feedback” mais curto ao cliente.

Em 2008 iniciou a aparição do termo Infraestrutura Ágil em diversos eventos e listas de discussão, levantando a abordagem de como as metodologias ágeis estão imperando na administração de infraestruturas.

Mas foi em 2009, durante a conferência Velocity da O’Reilly, um trabalho apresentado por John Allspaw (10+ Deploys per Day: Dev and Ops Cooperation at Flickr), o termo Dev and Ops foi pela primeira vez citado. Nessa palestra John apresentou como problemas foram superados no Flickr, com a mudança de cultura institucional, e proporcionando uma melhor comunicação entre a Equipe de Desenvolvimento e Equipe Operacional, dando assim o nome de DEVOPS.

Desde então o DevOps vem tomando força e sendo cada vez mais aprimorado e implementado nas empresas. Como as metodologias ágeis já vinham sendo fortemente aplicadas, o DevOps veio para aprimorar as práticas ágeis, integrando as equipes e automatizando os processos de desenvolvimento e operação, dessa forma possibilitando redefinição da estrutura organizacional e do processo de TI tradicional.

Essa abordagem coloca uma grande ênfase na automação de construção, implementação e teste. O uso de ferramentas de Integração Contínua (CI), ferramentas de teste de automação, se tornam uma norma em um ciclo de DevOps .

O DevOps envolve “Desenvolvimento Contínuo”. Onde o código foi escrito e comprometido com o Controle de Versão, será construído, implementado, testado e instalado no ambiente de Produção pronto para ser consumido pelo usuário final. Esse processo ajuda a todos em toda a cadeia, já que os ambientes e processos são padronizados. Toda ação na cadeia é automatizada. Também dá liberdade a todas as partes interessadas para concentrar seus esforços em projetar e codificar um produto adequado, em vez de se preocupar com os vários processos de construção, operações e controle de qualidade.

Papel alterado do QA com DevOps.

Para entender melhor como o papel da equipe de qualidade vem se modificando com o tempo, vamos voltar poucos anos e analisar as atividades dos profissionais de qualidade nas metodologias tradicionais.

Nessas metodologias, as atividades de testes são realizadas sempre no final de cada versão, sendo esse o momento que a equipe de teste analisa os requisitos a partir das documentações geradas.

As equipes de testes tinham uma burocracia em suas atividades: criação de planos, geração de documentações, criação de cenários de testes, “reports” de relatório de execução Ou seja, uma certa autonomia em suas atividades, mas um alto grau de dependência da equipe de desenvolvimento, na qual suas atividades apenas iniciariam após que todo o processo de desenvolvimento fosse encerrado.

Com a chegada das metodologias ágeis as coisas começaram a mudar. Como vimos anteriormente, os grandes produtos são quebrados e desenvolvidos em pequenas entregas e, nela, todo o processo de desenvolvimento e testes deverão ser realizados repentinamente. Para que essas pequenas entregas tenham seus objetivos alcançados, muitos utilizados durante as metodologias em cascata tiveram que sofrem alterações, exclusões e necessitaram de um grau elevado de automação, ação que ocorreu com um envolvimento dos desenvolvedores de forma mais fortemente na criação de testes automatizados.

Analisando a fundo o Scrum, o próprio Guide especifica que, como um dos papéis do Scrum temos o “Time de Desenvolvimento” e é assim que o Guide fala sobre esse time: “Scrum não reconhece títulos/cargos para membros do Time de Desenvolvimento além de Desenvolvedor, independentemente do trabalho realizado por aquela pessoa; não há exceções para essa regra”. Isso gerou um certo “frio na barriga” dos profissionais de testes, sendo até mesmo cogitada a possibilidade da “Morte dos Testadores”.

Porém essa análise é um tanto equivocada. Por mais que tenhamos um “upgrade” nas atividades de QA, não podemos considerar que tais atividades são dispensáveis para que o produto final alcance o grau de qualidade buscado a cada evolução das metodologias. Logo podemos considerar que os profissionais de teste/qualidade deverão também passar por esse processo de “upgrade”, no qual deveria considerar a busca de uma mudança de mentalidade, expectativa, atividade e responsabilidades.

O papel do profissional de testes nas metodologias ágeis não só mudou, como também ficou cada vez mais importante.

Essa mudança se deu com a criação do Manifesto de Testes Ágeis. Nesse manifesto podemos ver a mudança de comportamento e responsabilidade que esses profissionais devem buscar.

A fim de dar conta de um modelo mais distribuído de experiência em testes e responsabilidades no modo DevOps, os profissionais QA devem procurar posicionar-se organizacionalmente para que seu trabalho possa agregar o maior valor possível no ciclo de vida de desenvolvimento de software. Isso significa obter uma responsabilidade nova e significativa para tomar decisões estratégicas de nível superior em relação a problemas de teste e qualidade. Isso poderia significar uma mudança no organograma.

Há a oportunidade de incorporar a experiência em controle de qualidade diretamente nas equipes de desenvolvimento, apoiando-os nas atividades de criação de testes de unidades. Esta é uma área que tem sido mais eficaz para lidar com a transição de QA até agora. Há também o potencial de desviar os profissionais de QA para grupos de ferramentas, responsáveis por escrever o teste ou fornecer ferramentas para todo processo.

Então, em vez de executar os testes e lidar com o trabalho prático, os profissionais de controle de qualidade passarão para uma função mais consultiva e distribuída, para ajudar os desenvolvedores a aprender como escrever melhores testes e melhorar sua abordagem de seleção de qualidade. Porque, no final do dia, os desenvolvedores ainda são desenvolvedores. Eles não foram treinados para procurar problemas de qualidade. E mesmo que se importem com isso, vão sentir falta das coisas.

Independentemente de como os organogramas vão impactar os trabalhos atuais desses profissionais, eles precisam começar a pensar sobre como aprimorar suas habilidades para agregar valor à medida que mais do seu trabalho diário é automatizado. Isso significa estar pronto para ajudar a elevar uma abordagem de teste em vez de executá-la.

Com isso mais dados operacionais precisam migrar para a organização, para que ela tenha uma visão melhor das expectativas. Por exemplo, enquanto no passado o QA estava focado estritamente na documentação de defeitos, agora o foco deveria estar em coletar dados de uma escala mais ampla de testes automatizados e usá-los para expor as causas mais prováveis para esses defeitos e onde eles estão propensos a cortar novamente, se as causas não forem resolvidas. Vejamos no ciclo DevOps, as responsabilidades da equipe de QA se espalha por todo processo, desde a criação dos “Stories” até o “deploy” em produção.

O que é preciso para ser um QA DevOps?

Após tudo que vimos, podemos tomar como conclusão que o QA conquistou o seu “lugar ao sol”. No universo DEVOPS o QA vem tornando-se uma peça cada vez mais importante em todo processo de desenvolvimento e não exclusivamente na fase de testes. O QA se tornou responsável, junto com toda equipe, de manter a qualidade do produto durante toda a fase da vida útil do projeto, desde o levantamento de requisito, passando pela fase de desenvolvimento, “build” das partes do projeto (por sprint) e testes de sistemas com o usuário.

Para tal, o QA DevOps deve estar cada vez mais qualificado e requerido, o que tenha conhecimentos além dos necessários para atividades de testes.

Abaixo vamos falar um pouco mais do que é preciso para ser um QA DevOps:

• Ter o mínimo de “skill” para entender “por backgroud “

Conheça o sistema “por debaixo dos panos”, tenha ao menos entendimento de como está sendo produzido, linguagem, ferramentas, banco de dados, etc. Saiba ao menos como funciona e o que pode afetar a funcionalidade do sistema. Esse passo é muito importante para que o QA possa, no caso de erro, identificar se o ocorrido é um bug do sistema ou um mal funcionamento de algo, como também, visualizar melhorias e sugerir à equipe.

• Entender como funciona o ambiente em que se encontra a aplicação.

Uma vez conhecendo tudo que está nos bastidores do desenvolvimento do produto, será muito importante ter conhecimento como cada parte funciona no processo de desenvolvimento, o que cada coisa faz, como faz e a quem recorrer se houver algum problema. Com isso, o QA poderá antecipar alguns possíveis erros e criar cenários para garantir que eles não ocorram, e se ocorrerem, que serão devidamente identificados e corrigidos.

• Deve saber/gostar programar.

Por mais que algumas empresas, no mercado, que ainda trabalhem com execução de testes funcionais manuais, é primordial que um QA DevOps saiba de alguma linguagem de programação (especialmente do sistema que está sendo desenvolvido), pois a automação de testes de software é uma realidade do dia-a-dia de qualquer QA, e quando estamos falando de DevOps, a automação é fundamental, pois estamos falando em agilidade, redução de tempo e entregas curtas com qualidade, onde a automação é a melhor forma de acompanhar o ritmo de desenvolvimento ágil.

• Sempre estudar novas tecnologias

Diariamente novas ferramentas estão surgindo no mercado, e os projetos não ficam atrás. Com frequência, as equipes estão incorporando novos sistemas para ajudar no processo de desenvolvimento, portanto é importante sempre se atualizar e estuda-las, ou ao menos as que estão no auge, saiba o que elas fazem, se não souber a fundo, ao menos saiba que elas existem 😀

• Aplicação do princípio DRY: don’t repeat yourself.

Não sei se você já ouviu falar, mas na área de testes, há um termo muito usado que é o Paradoxo da Pesticida, que resumidamente é quando um “tester” que repete várias vezes a execução de um mesmo cenário, os testes deixarão de ser úteis e provavelmente perderão sua qualidade, não encontrando novos defeitos. Então uma prática interessante é a “don’t repeat yourseft”, não repita você mesmo, quando se trata de execução de testes podemos indicar o trabalho “Pair Testing”, onde dois ou mais testadores se reversam na criação de cenários, revisão e execução dos mesmo, onde o mais indicado seria quem criou o cenário não executá-lo.

• Entender que você é o homem do meio.

Como vimos anteriormente, durante um processo de desenvolvimento estrutural, os testes eram realizados durante a fase de testes, após o desenvolvimento. Nesse cenário muitos testadores se sentiam parte menos importante do processo, principalmente com atrasos do desenvolvimento, as atividades de testes que sempre eram reduzidas e impactadas. Com um processo ágil ou DevOps, o QA faze parte do processo como todo, logo o QA está requisitado, está mais participativo, mais valorizado.

• Saber ao menos o básico de inglês para se comunicar

Uma “pedra no sapato” de quase todo profissional de TI, o idioma Inglês, que é uma peça fundamental para um bom profissional de QA DevOps. Então reserve um tempo no dia para investir no seu inglês, a leitura é fundamental, a conversação é importante, principalmente se tiver pretensão de querer fazer carreira internacional.

• Para se tornar um QA DevOps é gostar do faz.

Além de tudo que já se falamos acima, o mais importante é “Goste do que você faz”, faça com amor, com alegria. O trabalho de QA não é apenas encontrar bugs é ver a satisfação do cliente com o produto entregue com qualidade, é ver a empresa sendo valorizada devido aos seus esforços, e ser reconhecido pelos gerentes da empresa.

Referências:

https://efagundes.com/blog/devops-e-metodos-ageis-de-desenvolvimento/

https://gaea.com.br/o-que-e-devops-conceito/

https://www.devmedia.com.br/processo-de-teste-agil-x-tradicional/36854

Dentre tantas coisas que formam a Cultura DB1, compartilhar conhecimento é uma das principais! Estamos sempre em busca de novos talentos que se identifiquem com essa ideia. Você é um deles?