Aumentando a produtividade: um guia para implementar uma nova função de controle de qualidade para lançamentos mais rápidos

Olá!

Estou entusiasmado em compartilhar como consegui melhorar nosso fluxo de lançamento em 20% por meio da implementação de uma função de controle de qualidade do sistema.

Como minha empresa é uma típica empresa de produtos, as equipes são divididas não por produto, mas por componentes. Graças a isso, por um lado, conseguimos formar equipes poderosas com "detentores" do conhecimento. Mas, por outro lado, as funções dentro das unidades são relativamente isoladas, e diferentes conjuntos de habilidades e conhecimentos específicos impõem suas limitações. Por exemplo, às vezes preciso mover um testador da equipe de back-end para o front-end ou vice-versa.

Isso levou ao fato de que havia uma questão de orquestração eficaz nas equipes de controle de qualidade e gerenciamento da interação entre equipes. O que, é claro, acabou afetando o fluxo de lançamento.

Libere o fluxo antes das alterações

Antes das mudanças, nosso fluxo de lançamento era assim:

1. Uma Especificação de Requisitos de Negócios (BRS) é um documento que descreve as necessidades, expectativas e especificações detalhadas para um recurso, sistema, produto ou projeto específico dentro de um negócio. Ele serve como uma ponte entre as partes interessadas do negócio e as equipes de desenvolvimento ou implementação, garantindo um entendimento claro do que deve ser alcançado e como se alinha com os objetivos gerais do negócio. Deve conter cenários detalhados que descrevam como os usuários irão interagir com o recurso. O Feature Owner (FO) tem a tarefa de formular requisitos de negócios.
2. Uma Especificação de Requisitos de Software (SRS) é um documento abrangente que descreve a descrição detalhada do que se espera que um sistema de software realize. Por exemplo, como e quais comandos interagem, por qual protocolo e quais dados serão transmitidos. Se a equipe que trabalha no recurso utiliza uma interface gráfica, o SRS deve incluir layouts do recurso que está sendo desenvolvido. O Feature Architect é responsável por escrever o SRS.
3. Plano de ação de qualidade (QAP) – um conjunto de casos que um proprietário de recurso verifica antes de aceitar um recurso. Após a descrição dos documentos, procedemos à implementação da funcionalidade. Quando a primeira equipe termina de desenvolver e testar sua parte do recurso, ela é transferida para a segunda equipe. A segunda equipe realiza a integração/desenvolvimento/teste e passa para a próxima unidade. E assim por diante até que todas as equipes de componentes que participam do desenvolvimento de funcionalidades passem por este fluxo. O FO valida o recurso e o envia para a liberação.

Liberar problemas de fluxo

Então, tudo parece estar bem – documentos, aplicativos, casos de aceitação. No entanto, encontramos as seguintes dificuldades neste processo:

Problemas por parte do controle de qualidade:

• O teste de requisitos começa somente após o desenvolvimento. As tarefas que já foram implementadas pelos desenvolvedores, juntamente com seus requisitos, são entregues à equipe de QA. Mas, como sabemos, pode haver erros nos requisitos.
• Encontrar a equipe responsável por um bug leva bastante tempo porque nem sempre fica claro quais casos já foram testados por outras equipes.
• Sem reutilização de artefatos de teste. Como parte do teste de um recurso, as equipes de QA preparam conjuntos de dados de teste semelhantes. Mas devido ao isolamento e estreita especialização das equipes, elas não podiam transmitir esses dados umas às outras.

Problemas por parte do FO:

• Devido aos muitos recursos, escrever QAP leva muito tempo.
• A validação do recurso ocorre após o desenvolvimento por todas as equipes. No nosso caso, isso aumenta significativamente o fluxo de liberação devido a muitos problemas de integração.
• A preparação do ambiente de teste também é precisa devido à complexidade do produto e ao volume de integrações entre as equipes. Diferentes equipes estão testando seus componentes simultaneamente, aumentando os riscos de misturar, alterar ou excluir dados.

Controle de qualidade do sistema no fluxo de lançamento atualizado

Para facilitar a interação efetiva entre as equipes de QA e reduzir o fluxo de liberação, introduzimos a função de QA do sistema.

Isso ajudou a aliviar a carga de trabalho na forma de escrever casos de aceitação com FO e acelerar a escrita de cenários de teste, introduzir testes intermediários do componente de recurso antes de passá-lo para a próxima equipe e também mudar o trabalho demorado de preparar o teste ambiente ao QA do sistema, levando em consideração todas as nuances e requisitos das equipes para integrações e dados de teste.

O QA do sistema tornou-se um elo entre os requisitos técnicos e de negócios para cada recurso e o produto como um todo.

Integração para controle de qualidade do sistema

Para entender todo o ciclo de lançamento, os QAs do sistema precisam entender como um ciclo de lançamento específico funciona em cada equipe. A integração normalmente dura cerca de três meses, pois o controle de qualidade do sistema passa de 2 a 3 semanas em cada equipe, entendendo seus ciclos de lançamento específicos.

Resultados do novo processo

• Agora estamos testando os requisitos de BRS/SRS de proprietários de recursos e arquitetos. A detecção precoce de bugs resulta em economia de custos para os negócios.

• Estabelecemos um espaço de controle de qualidade entre equipes, onde os artefatos de teste são anexados a cada recurso – requisitos de negócios, requisitos técnicos, casos de aceitação, casos de outras equipes, dados de teste. Isso ajudou significativamente todas as equipes de controle de qualidade a estarem em um único contexto e a reutilizar os dados com eficiência.

• Acelerei o processo de localização de bugs pois o QA do sistema possui conjuntos de casos de teste de todas as equipes.

• Como o QA do sistema está escrevendo casos de aceitação para cada equipe, essa é uma excelente dica para acelerar e melhorar a qualidade dos testes.

• O processo de integração tornou-se indolor, pois o recurso é validado por casos de aceitação após cada comando.

• Tendo removido uma parte significativa da carga do FO, a aceitação de recursos e a preparação de um suporte de integração com dados de teste foram aceleradas.

  
  

No geral, acelerou o fluxo de lançamento em 15-20% e reduziu o número de bugs de integração quase pela metade, pois agora os detectamos tanto no estágio de redação dos requisitos de BRS e SRS quanto durante as integrações da equipe na estrutura do desenvolvimento de recursos.

Testes felizes e produtivos!