À procura da qualidade perfeita

Ao criar um produto digital, por padrão, separamos o código fonte em camadas (front-end e back-end). A primeira, onde os usuários interagem com o produto e a segunda, é responsável por replicar o domínio de negócio da empresa. Elas sempre interagem entre si.

A imagem acima exemplifica a responsabilidade de cada uma das camadas: entrada (informações que o usuário insere, gerenciadas pelo front-end), processamento (processamento dos dados enviados, gerenciados pelo back-end) e saída (resposta do sistema para o usuário, novamente sendo gerenciado pelo front-end).

Mas o que acontece com a qualidade do produto quando começamos a agrupar essas camadas? Como podemos garantir a qualidade em cada uma delas?

A chave principal para garantir qualidade durante o ciclo de desenvolvimento do produto é uma boa estratégia de testes.

Dentro das camadas com testes de unidades:

  • Testar se um método retorna o que é esperado;
  • Testar se o módulo chama a interface corretamente.

Ligação entre camadas com testes de integração:

  • Testar se a combinação de módulos implementados está correto.

Exemplo: Enviando um módulo cliente com usuário e senha para o módulo de login, o cliente é autenticado.

Regras de negócio com testes de validação:

  • Testar uma funcionalidade criada de ponta a ponta.

Exemplo: Ao fazer uma requisição em uma API, é retornado o que é esperado.

Produto com testes de sistema:

  • Testa se a interação entre todos os sistemas envolvidos funcionam de acordo com os critérios de aceitação.

Exemplo: Se o usuário, na tela de login, informar o usuário e senha corretamente, é autenticado no sistema e aparece uma mensagem de sucesso.

Aqui na Creditas, dividimos bem as responsabilidades em cada uma das estratégias. O desenvolvedor é o responsável pelos testes de unidade, integração e validação. O Product Manager (PM) pelos testes de sistema, validando regra de negócio. Mas nem sempre foi assim, pois não tínhamos um especialista em qualidade e o primeiro passo, foi conseguir contratar um.

A idéia era conseguir entregar incrementos de produto com qualidade e também encurtar os feedbacks durante o ciclo de desenvolvimento.

Vou contar um pouco sobre o processo que iniciamos e estamos rodando desde então.

Desafio: Integração

O grande desafio foi como incluir um SQA no time, sendo que em nossa estrutura nunca existiu um.

No começo, haviam 3 times: o time de Growth, responsável pela captação de leads, exibição dos produtos de refinanciamento e SEO. Processing, responsável pela captação dos dados do cliente e documentos. E o terceiro time, Kill Bill, responsável por “matar” um sistema legado.

Nesse início, quando entrou na empresa e começou a conhecer o domínio do negócio, o SQA ficou responsável por automatizar boa parte das funcionalidades já existentes, gerando um aprendizado positivo, destacando duas: o SQA conseguiu entender o produto de interação do cliente e o backoffice usado pela operação.

Em pouco mais de um mês, ele já havia construído uma boa base de testes de sistemas para todas as features, e todos nós ficamos espantados e concluímos que seria interessante incluí-lo nos times.

Desafio: Qualidade + Gargalo

Como na maioria das empresas, nós tínhamos um pequeno problema de comunicação. Na maioria das vezes a funcionalidade não era planejada entre times e pessoas e, com isso, começamos a ter problemas nas entregas, pois só percebemos que os testes haviam quebrado depois de ter entregue a funcionalidade.

Além disso, o nosso Kanban contemplava uma coluna de Review, que incluía testes manuais de alguém de negócio (normalmente o PM) para validar requisitos de negócio e o testes automatizados de sistema criados pelo SQA. Isso começou a gerar um problema de gargalo na coluna Review.

O PM com suas milhares de tarefas diárias, não conseguia testar as funcionalidades em um tempo hábil ou quando conseguia, era mais rápido que a automação de testes de sistemas, achando algum problema no final da funcionalidade, que seria notado se automação já estivesse pronta, poupando seu tempo apenas a testar os requisitos de negócio.

A tabela abaixo mostra o tempo médio de uma funcionalidade na coluna Review, cada linha representa um sprint finalizado.

A maneira que encontramos de resolver tanto o problema de qualidade, que estava relacionado à falta de comunicação, quanto o problema de estoque gerado na revisão de produto, foi trazendo o nosso SQA para dentro do time, sendo responsável por uma das fases do fluxo.

Sabemos que o certo é garantir qualidade em todas as fases, mas esse era o passo mais imediatista e fácil de realizar.

Então adicionamos em nosso kanban uma coluna relativa ao BDD. Quando movido um item para a coluna, o SQA já sabia o que deveria ser testado. Também contamos com ele nas cerimônias do time, sendo assim, todos têm visibilidade do progresso e sempre testamos tudo antes de lançar.

A tabela abaixo mostra a divisão da coluna Review e sua diminuição do tempo.

Notamos que, com a divisão, o tempo de uma funcionalidade dentro da coluna Review caiu estrondosamente, pois o item já chegava correto, livre de problemas, que não caberia ao PM ter notado no momento de seus testes manuais.

Também com a automação dos testes na coluna BDD, quando se captava um problema, facilitou os desenvolvedores o arrumarem, obtendo uma resposta rápida se a solução criada resolvia o problema com a funcionalidade.

A partir de então, sempre visando otimizar ainda mais as métricas e diminuir a dependência do SQA dentro do time, focamos em automatizar os testes em nosso processo de Continuous Integration (CI) de forma que qualquer pessoa consiga rodar os testes criados.

A Seguir: Qualidade de Ponta a Ponta

As mudanças citadas anteriormente abriram um enorme precedente. Nosso SQA não se limita apenas a ficar criando e rodando seus testezinhos marotos a partir de um problema notado em uma entrega. Adicionamos ao papel de SQA uma nova responsabilidade: verificar se a funcionalidade entregue atende a um critério de aceitação comum a todas as funcionalidades, que é registrar eventos em um banco de dados usado pelos times de BI e Data Engineer. Isso nos ajuda a capturar feedbacks quantitativos e gerar insights sobre o uso da funcionalidade.

Estamos verificando e amadurecendo esse papel em nosso time e provavelmente ainda haverá muitas mudanças que irei compartilhar com vocês.

No geral, podemos concluir que só o fato de ter um SQA no time, não garante sucesso nas entregas, e sim como encaixar ele no processo e conseguir combinar os skills dele com o do time.

E vocês, como funciona a qualidade do produto em sua empresa?

Desde criança apaixonado por desenvolvimento de software, estuda frequentemente sobre Object-Oriented Design e Arquitetura de Software. Fanático por jogos e esportes em geral, principalmente pela NFL