Post

Radar de Qualidade

1 Star2 Stars3 Stars4 Stars5 Stars

Imagina você dirigindo um veículo de olhos fechados.

É simplesmente impossível certo?

Então me responda: Como está a saúde da empresa que você trabalha hoje?
Está difícil de responder?

Então responda as perguntas:

  • Quais times fazem testes funcionais manuais?
  • Quais times fazem testes funcionais automatizados?
  • Dos times que automatizam, quantos usam BDD?
  • Qual o percentual de cobertura destes testes?
  • Quais times fazem testes de performance?
  • Quais times tem seus testes automatizados integrados no pipeline do Jenkins?
  • Quantos times usam um ambiente de QA pra trabalhar?

Precisou perguntar pra cada QA da empresa?

Veja que nesta empresa brasileira (e-commerce) qualquer pessoas tem a resposta assim que entra:
1975070_770226633049213_8175802632823453851_n

Percebeu algo de errado onde você trabalha?
Será que você não está testando de olhos fechados.

Em quantas empresas você já trabalhou que não havia nem mesmo a informação se um determinado tipo de teste era feito ou não?
Que ninguém sabia como estavam os testes, não havia métrica de cobertura de testes e entre outras informações relevantes para o direcionamento das equipes. Você se sentia perdido?
Fica evidente que nestas empresas área de qualidade é mera formalidade.

A única métrica que sempre existe é a quantidade de bugs encontrados. Esta é a clássica e há quem faça até dancinha quando registra um bug. (Vide DFTestes), Ao nosso ver essa métrica não faz o menor sentido, pois causa desconforto nos programadores, eventualmente pedidos de demissão e brigas entre dev e qa, pois o qa faz a função de dedo-duro. E são pessoas, que tem esposas e filhos assim como nós.

O problema é comum em várias empresas: Trabalham sobre informações erradas, logo obtém resultados errados.
E como melhorar?
Estudar, ir em eventos, fazer cursos. Não apenas de testes mas também de agile.

Mas você pode olhar para os lideres de mercado e aprender pelo exemplo.
Na imagem acima, cada coluna é um time e cada linha é um quesito.
Desta forma, é possível ver claramente como anda a saúde de cada produto e por consequência a saúde da TI.
O quadro não resolve os problemas, ele apenas os deixa visíveis a todos.
O quadro da uma ideia se cada time faz ou não, de forma binária mesmo. Simples e eficaz!

Outra forma é o Sonar (http://goo.gl/VZ0AXu) que mostra tanto a cobertura dos testes integrados como unitários.
Os detalhes como a quantidade e percentual de cobertura é possível avaliar pelo Sonar.
it-coverage-tab

Estas são duas formas simples e eficientes de começar a enxergar por onde se quer caminhar e sair da velha métrica de quantidade de bugs encontrados.

Você também pode querer ler

Não Comentários

Leave a Comment

O seu endereço de email não será publicado.