Fala pessoal! Ou como prefere nossa futura presidenta(omg): Oi internautas.

Hoje vou falar um pouquinho sobre testes.

Acredito que os testes sejam o pesadelo de muitas equipes de desenvolvimento, isso acontece por muitos motivos:

1- Testes são, geralmente, feitos ao final do ciclo, justamente quando o cronograma está mais apertado

2- A função de tester é realmente espinhosa! Para muitos sua missão é achar problema no trabalho dos outros.

3- Normalmente o teste tem a finalidade de garantir a qualidade do software, mas como fazer isso se só é envolvido no fim do ciclo?

4- O teste que necessita de mais esforço é o teste funcional, justamente o teste que possui históricamente menos ferramentas de apoio.

5- Testar é chato prá burro (pelo menos é o que muitos pensam)

6- O esforço para teste é sub-estimado

Enfim, poderia descrever vários outros motivos de o porquê o teste se torna um pesadelo, provavelmente, vocês já passaram pelas situações a cima, e tem outros motivos a acrescentar nesta lista.

Mas, para não fugir de um lugar comum: podemos ver a luz no fim do túnel!

Acredito que, dentro da engenharia de software, a disciplina que mais evoluiu na última década foi justamente a qualidade de software. E como não poderia deixar de ser os testes continuam como uma parte muito importante desta disciplina.

Faz parte desta evolução uma série de técnicas, metodologias e ferramentas que ao longo da última década vem sendo desenvolvidas. O grande problema é que estas técnicas, metodologias e ferramentas ainda não tiveram a penetração necessária no mercado de TI, ou são adotadas de forma errada.

Com isso a maioria das pessoas continuam procurando garantir a qualidade do software como era feita a 20, 30, 40 anos. Com isto existem hoje três grandes filosofias que norteiam os processo de qualidade:

a) Compilou, funcionou – A ausência de críticas é um elogio! Se ninguém reclamou está funcionando!

b) Homologação realizada pelo usuário – Vamos culpar a vítima! Se alguma coisa quebrar a culpa é do usuário que não identificou o problema a tempo!

c) Macacos me mordam! Contrata-se uma capela de macacos que é responsável por testar, homologar, colher evidencias, documentar os testes, tudo isso controlado por uma planilha em excel, de forma extremamente repetitiva, mas aliada às melhores praticas de mercado.

Destas práticas qual você vive? Qual delas seria a melhor opção a ser adotada?

Com certeza a opção A!

Ué, se você não tem um processo eficaz de garantia de qualidade, não tem! Pelo menos assim você economiza uma boa grana!

Agora, se qualidade é algo importante para sua organização, se você realmente se preocupa com isso, deveria pensar no assunto com mais carinho!

Um processo de qualidade de software é coisa séria e complexa. É abosulatamente complexo de se implementá-lo. Não se iludam, não pensem que farão isso contratando tantas quantas forem as pessoas necessárias. Não pensem que farão isso comprando as melhores ferramentas da atualidade. Não pensem que farão isso adotando todas as boas práticas recomendadas por renomadas normas e institutos. Não, não dará certo! Você gastará muito dinheiro e o incremento de qualidade será pífio!

Ok, você pode estar pensando que eu sou um radical, e está só esperando ler este parágrafo para dar um alt+f4 e ir ler coisa mais útil! Confesso que exagerei um pouco, justamente para causar este sentimento. O que quero mostrar é que as premissas sobre as quais foram montados os processos de qualidade são falsas, leia mais um pouco, acho que valerá a pena!

Um pouco de teoria agora…

O grande problema da enegenharia de software está justamente no seu nome! Engenharia. Grande parte dela foi baseada em processo de produção, em processos industriais. Até os termos que utilizamos remetem a estes processos: Fábrica de Software, Controle de qualidade, garantia de qualidade….

Na produção industrial os processos são altamente repetitivos, e completamente isolados! Por exemplo, em uma fábrica de parafusos, se um parafuso sair defeituoso ele não afetará os outros parafusos, uma vez identificado o problema é possível corrigí-lo e tomar medidas para que ele não se repita mais. Na pior das hipóteses o lote de parafusos estará comprometido.

Em software não é bem assim. Se um parafuso estiver defeituoso ele causará problemas para sempre! Os processo de criação de software não criam softwares novos, independentes um dos outros. Ao contrário, normalmente, os pedaços de software vão sendo integrados de forma com que a complexidade do todo vá sendo ampliada exponencialmente ad infinutum.

O processo de controle de qualidade industrial se baseia basicamente na inspeção. Uma peça por lote é inspecionada e esta peça é verificada, caso ela esteja ok, infere-se que o lote inteiro esteja ok. Normalmente isso acontece!

O processo de controle de qualidade de software utiliza este principio, o da inspeção, o software é inspecionado, ou seja testado, para garantir que eteja ok. O problema é que em software não existe lote de produtos! Voce acaba adotando uma ou mais das seguintes estratégias:

a- Testa tudo! o Software inteiro!
b- Testa os componentes novos.
c- Testas os componentes que podem ser afetados pelas alterações recentes
d- Testa os pontos cruciais do sistema

Nenhuma destas técnicas responde de forma eficiente aos nossos anseios!

Nós só tivesmos uma evolução razoável (como eu disse nos últimos 10 anos) a partir do momento em que o desenvolvimento de software passa a ser visto de forma distinta do processo industrial.

Sem medo de me tornar repetitivo: O processo de qualidade de software é difícil de ser implementado, é difícil pois normalmente é baseado em premissas erradas.

Não vou fugir em dar respostas concretas, mas este post já está longo demais!

Como lição de casa para vocês vou deixar esta:

– Esqueçam tudo o que vocês sabem sobre qualidade de software! Está tudo errado! Mesmo o que está certo está errado! Mesmo o que trás resultados concretos está errado! Esqueça! Coloque no arquivo morto das ligação neurológicas!

Depois de ter esquecido volte ao blog para ler a continuação deste posta na semana que vem! Prometo que vou apresentar mais respostas do que perguntas.

Um abraço e até lá!