Qual é o lugar dos testers no ecossistema DevOps? A própria fundação da cultura DevOps é construída sobre a eliminação de barreiras entre as funções de desenvolvedor e QA: entre os dois objetivos que distinguem as equipes Dev x Ops, o QA desempenha um papel fundamental na entrega de valor do negócio. O DevOps acaba por integrar perfeitamente as 3 funções em uma única entidade de TI e garantir a entrega desse valor. Neste cenário, o controle de qualidade (QA) e os testes funcionam como uma ponte entre todas as disciplinas, desde clientes e negócios até desenvolvimento e operações em DevOps.
O DevOps refere-se principalmente a um mindset que se concentra na comunicação e colaboração entre desenvolvedores e testers. Isso foi necessário porque, em configurações onde o DevOps não está presente, os desenvolvedores geralmente não estão atentos a questões mais sérias envolvendo QA e operações (é o clássico “funciona bem na minha máquina” que acaba dando a palavra final nesses casos). Além disso, equipes de QAs e Ops geralmente carecem de contexto sobre os requisitos de negócios de qualquer software, uma vez que trabalham em vários projetos simultaneamente.
Fonte: wikipedia
O objetivo do DevOps é garantir que os desenvolvedores e os QAs estejam na mesma página em todos os estágios de um projeto. Em uma configuração onde o DevOps não está presente, os desenvolvedores simplesmente “jogam o código por cima da parede” para os QAs; os QAs, por sua vez, encontram bugs e os levam aos devs para que seja feito o debug. (Neste cenário, frequentemente, os desenvolvedores culpam os QAs e o ambiente de testes pelos bugs).
Quando os bugs são finalmente resolvidos, o QA então joga o código “por cima da parede” para o Ops; como as equipes de operações devem limitar as alterações em seus sistemas, há uma grande possibilidade de seu sistema travar quando o código for lançado. Ops então culpa QAs e Devs, e o ciclo de sprint de desenvolvimento continua.
Em DevOps, as funções de QA e Dev são confusas. As estratégias de desenvolvimento são criadas tendo em mente prioridades de teste. O QA atua como uma ponte entre o desenvolvimento e as operações, implementando o mecanismo colaborativo no coração do DevOps.
Os testers são incluídos nas sessões de brainstorming desde o início. Além disso, os desenvolvedores realizam testes de unidade em seu próprio código antes de enviá-lo para a base de código principal. Por outro lado, os QAs se envolvem ativamente na correção do código quando podem.
Naturalmente, uma configuração de teste de software em um ambiente DevOps requer uma estratégia de teste confiável e muito bem definida para manter o código o mais limpo e livre de erros possível. É aqui que entra o controle de qualidade.
O QA como um consultor
A cultura DevOps tem tudo a ver com a transformação de mentalidades individuais e coletivas em direções mais colaborativas para todos. Os desenvolvedores assumem mais responsabilidades de testers para que os QAs não tenham que perder tempo identificando erros básicos no código.
No entanto, essa mudança não acontece em um simples passe de mágica: os desenvolvedores vão precisar de algum treinamento para isso. Acontece que, com os desenvolvedores realizando mais testes, o controle de qualidade (QA) fará a transição para uma função mais consultiva, ajudando os desenvolvedores a criar testes melhores e se tornarem também melhores na triagem de qualidade. O controle de qualidade também é responsável por ajudar os desenvolvedores a obter uma melhor compreensão das filosofias e processos de teste. Essa mudança fundamental na abordagem técnica não poderia ser realizada, de outra forma, sem um envolvimento sério e contribuições dos departamentos de QA.
No final do dia, os devs não foram treinados para procurar problemas de qualidade, mas apenas para corrigi-los. Mesmo quando eles se preocupam em fazer isso, eles provavelmente deixarão passar algumas issues. No DevOps, as responsabilidades do QA começam com a transferência de conhecimento e treinamento dado aos desenvolvedores.
O QA como um estrategista
As melhores práticas do modelo SCRUM incorporam experiência em QA diretamente no blueprint de desenvolvimento. Ao envolver o controle de qualidade desde o início de um sprint, as equipes de Produto e Growth tornam-se mais fluídas e evoluídas.
Como estrategista, o engenheiro QA toma decisões de alto nível sobre quais padrões o software deve atender em sua forma final. Na medida em que os QAs devem ter conhecimento íntimo de como os usuários finais pensam e interagem com o software, eles estão em melhor posição para aconselhar as equipes de desenvolvimento sobre quais recursos incluir, quais bugs comuns devem ser observados em testes de unidade e para quais tipos de usuários o software deve ser direcionado.
O teste de QA na abordagem DevOps também inclui a elaboração de casos de testes automatizados que por sua vez constituem a parte de Continuous Testing do pipeline CI/CD. Diferentes softwares devem ser testados para diferentes bugs, e é prerrogativa do QA decidir quais testes estariam melhor posicionados para identificar tais bugs.
Em ambientes DevOps bem consolidados, o controle de qualidade vem muito mais cedo. Os sprints de desenvolvimento não começam sem que as especificações sejam revisadas pela equipe de QA, também responsável pelas recomendações envolvendo questões de segurança, desempenho e estabilidade.
Como estrategistas, os QAs também são responsáveis por selecionar as ferramentas e frameworks mais adequados para testes manuais e de automação. Lembrando que uma implementação DevOps bem-sucedida depende muito de automação. É de extrema importância usar os frameworks certos de automação de testes, estabelecidos em cadeias de ferramentas ideais para automatizar grandes seções do pipeline de desenvolvimento e implantação.
Para QA testers, o DevOps oferece oportunidades para evoluir e se alinhar com os horizontes em mudança da tecnologia e das prioridades dos usuários. Os engenheiros de qualidade ocupam um lugar de poder e de responsabilidade no DevOps, mas isso deve começar com uma mudança em como eles abordam sua função em primeiro lugar.
1) As equipes de QA e de testes devem fazer parte das equipes técnicas. Elas precisam ir além do teste funcional manual e concentrar esforços em estratégias de automação (de testes, inclusive). O controle de qualidade torna-se o facilitador da qualidade no ciclo de vida de desenvolvimento do Produto (SDLC).
2) A qualidade precisa ser bem definida para atender aos requisitos. Em vez de tentar alcançar a “perfeição” no software, o QA deve se concentrar em obter uma experiência de usuário satisfatória dentro do prazo determinado.
3) Métricas que medem a qualidade devem ser estabelecidas e medidas. Essas métricas devem detectar possíveis defeitos no software logo no início do ciclo de desenvolvimento.
4) Metas individuais e equipes precisam ser otimizadas. As organizações precisam fortalecer o comportamento necessário e promover a transformação cultural entre as equipes incentivando a garantia de qualidade.
5) Os requisitos precisam ser específicos. As equipes de QA devem se envolver proativamente no processo de definição de requisitos para ajudar e orientar as equipes de desenvolvimento na direção mais adequada.
6) QA e testes devem se concentrar mais em testes de regressão automatizados em áreas críticas, a começar pelas principais funcionalidades do software.
7) QA e testes devem ser direcionados ao uso de ferramentas de automação para automatizar os testes sempre que for possível.
8) As equipes de desenvolvimento, operações e QA devem ser facilitadas e incentivadas a se comunicar, colaborar e otimizar seus esforços.
9) A integração contínua é a chave para identificar defeitos no início do ciclo de vida de desenvolvimento. Para que a integração contínua seja implementada de forma eficaz, todas as partes interessadas devem integrar seu trabalho, muitas vezes no dia-a-dia.
10) Um processo de teste contínuo totalmente automatizado precisa ser integrado ao SDLC para um processo de entrega contínua bem-sucedido de Produto que minimiza riscos, reduz custos e acelera o tempo de lançamento no mercado por meio de releases contínuos e frequentes.
Qual é o lugar dos testers no ecossistema DevOps? A própria fundação da cultura DevOps é construída sobre a eliminação de barreiras entre as funções de desenvolvedor e QA: entre os dois objetivos que distinguem as equipes Dev x Ops, o QA desempenha um papel fundamental na entrega de valor do negócio. O DevOps acaba por integrar perfeitamente as 3 funções em uma única entidade de TI e garantir a entrega desse valor. Neste cenário, o controle de qualidade (QA) e os testes funcionam como uma ponte entre todas as disciplinas, desde clientes e negócios até desenvolvimento e operações em DevOps.
O DevOps refere-se principalmente a um mindset que se concentra na comunicação e colaboração entre desenvolvedores e testers. Isso foi necessário porque, em configurações onde o DevOps não está presente, os desenvolvedores geralmente não estão atentos a questões mais sérias envolvendo QA e operações (é o clássico “funciona bem na minha máquina” que acaba dando a palavra final nesses casos). Além disso, equipes de QAs e Ops geralmente carecem de contexto sobre os requisitos de negócios de qualquer software, uma vez que trabalham em vários projetos simultaneamente.
Fonte: wikipedia
O objetivo do DevOps é garantir que os desenvolvedores e os QAs estejam na mesma página em todos os estágios de um projeto. Em uma configuração onde o DevOps não está presente, os desenvolvedores simplesmente “jogam o código por cima da parede” para os QAs; os QAs, por sua vez, encontram bugs e os levam aos devs para que seja feito o debug. (Neste cenário, frequentemente, os desenvolvedores culpam os QAs e o ambiente de testes pelos bugs).
Quando os bugs são finalmente resolvidos, o QA então joga o código “por cima da parede” para o Ops; como as equipes de operações devem limitar as alterações em seus sistemas, há uma grande possibilidade de seu sistema travar quando o código for lançado. Ops então culpa QAs e Devs, e o ciclo de sprint de desenvolvimento continua.
Em DevOps, as funções de QA e Dev são confusas. As estratégias de desenvolvimento são criadas tendo em mente prioridades de teste. O QA atua como uma ponte entre o desenvolvimento e as operações, implementando o mecanismo colaborativo no coração do DevOps.
Os testers são incluídos nas sessões de brainstorming desde o início. Além disso, os desenvolvedores realizam testes de unidade em seu próprio código antes de enviá-lo para a base de código principal. Por outro lado, os QAs se envolvem ativamente na correção do código quando podem.
Naturalmente, uma configuração de teste de software em um ambiente DevOps requer uma estratégia de teste confiável e muito bem definida para manter o código o mais limpo e livre de erros possível. É aqui que entra o controle de qualidade.
O QA como um consultor
A cultura DevOps tem tudo a ver com a transformação de mentalidades individuais e coletivas em direções mais colaborativas para todos. Os desenvolvedores assumem mais responsabilidades de testers para que os QAs não tenham que perder tempo identificando erros básicos no código.
No entanto, essa mudança não acontece em um simples passe de mágica: os desenvolvedores vão precisar de algum treinamento para isso. Acontece que, com os desenvolvedores realizando mais testes, o controle de qualidade (QA) fará a transição para uma função mais consultiva, ajudando os desenvolvedores a criar testes melhores e se tornarem também melhores na triagem de qualidade. O controle de qualidade também é responsável por ajudar os desenvolvedores a obter uma melhor compreensão das filosofias e processos de teste. Essa mudança fundamental na abordagem técnica não poderia ser realizada, de outra forma, sem um envolvimento sério e contribuições dos departamentos de QA.
No final do dia, os devs não foram treinados para procurar problemas de qualidade, mas apenas para corrigi-los. Mesmo quando eles se preocupam em fazer isso, eles provavelmente deixarão passar algumas issues. No DevOps, as responsabilidades do QA começam com a transferência de conhecimento e treinamento dado aos desenvolvedores.
O QA como um estrategista
As melhores práticas do modelo SCRUM incorporam experiência em QA diretamente no blueprint de desenvolvimento. Ao envolver o controle de qualidade desde o início de um sprint, as equipes de Produto e Growth tornam-se mais fluídas e evoluídas.
Como estrategista, o engenheiro QA toma decisões de alto nível sobre quais padrões o software deve atender em sua forma final. Na medida em que os QAs devem ter conhecimento íntimo de como os usuários finais pensam e interagem com o software, eles estão em melhor posição para aconselhar as equipes de desenvolvimento sobre quais recursos incluir, quais bugs comuns devem ser observados em testes de unidade e para quais tipos de usuários o software deve ser direcionado.
O teste de QA na abordagem DevOps também inclui a elaboração de casos de testes automatizados que por sua vez constituem a parte de Continuous Testing do pipeline CI/CD. Diferentes softwares devem ser testados para diferentes bugs, e é prerrogativa do QA decidir quais testes estariam melhor posicionados para identificar tais bugs.
Em ambientes DevOps bem consolidados, o controle de qualidade vem muito mais cedo. Os sprints de desenvolvimento não começam sem que as especificações sejam revisadas pela equipe de QA, também responsável pelas recomendações envolvendo questões de segurança, desempenho e estabilidade.
Como estrategistas, os QAs também são responsáveis por selecionar as ferramentas e frameworks mais adequados para testes manuais e de automação. Lembrando que uma implementação DevOps bem-sucedida depende muito de automação. É de extrema importância usar os frameworks certos de automação de testes, estabelecidos em cadeias de ferramentas ideais para automatizar grandes seções do pipeline de desenvolvimento e implantação.
Para QA testers, o DevOps oferece oportunidades para evoluir e se alinhar com os horizontes em mudança da tecnologia e das prioridades dos usuários. Os engenheiros de qualidade ocupam um lugar de poder e de responsabilidade no DevOps, mas isso deve começar com uma mudança em como eles abordam sua função em primeiro lugar.
1) As equipes de QA e de testes devem fazer parte das equipes técnicas. Elas precisam ir além do teste funcional manual e concentrar esforços em estratégias de automação (de testes, inclusive). O controle de qualidade torna-se o facilitador da qualidade no ciclo de vida de desenvolvimento do Produto (SDLC).
2) A qualidade precisa ser bem definida para atender aos requisitos. Em vez de tentar alcançar a “perfeição” no software, o QA deve se concentrar em obter uma experiência de usuário satisfatória dentro do prazo determinado.
3) Métricas que medem a qualidade devem ser estabelecidas e medidas. Essas métricas devem detectar possíveis defeitos no software logo no início do ciclo de desenvolvimento.
4) Metas individuais e equipes precisam ser otimizadas. As organizações precisam fortalecer o comportamento necessário e promover a transformação cultural entre as equipes incentivando a garantia de qualidade.
5) Os requisitos precisam ser específicos. As equipes de QA devem se envolver proativamente no processo de definição de requisitos para ajudar e orientar as equipes de desenvolvimento na direção mais adequada.
6) QA e testes devem se concentrar mais em testes de regressão automatizados em áreas críticas, a começar pelas principais funcionalidades do software.
7) QA e testes devem ser direcionados ao uso de ferramentas de automação para automatizar os testes sempre que for possível.
8) As equipes de desenvolvimento, operações e QA devem ser facilitadas e incentivadas a se comunicar, colaborar e otimizar seus esforços.
9) A integração contínua é a chave para identificar defeitos no início do ciclo de vida de desenvolvimento. Para que a integração contínua seja implementada de forma eficaz, todas as partes interessadas devem integrar seu trabalho, muitas vezes no dia-a-dia.
10) Um processo de teste contínuo totalmente automatizado precisa ser integrado ao SDLC para um processo de entrega contínua bem-sucedido de Produto que minimiza riscos, reduz custos e acelera o tempo de lançamento no mercado por meio de releases contínuos e frequentes.
