Por que os desenvolvedores não fazem testes de unidade e integração?

A 27ª Mesa Redonda DFTestes teve como tema “Por que os desenvolvedores não fazem testes de unidade e integração?”. A discussão gerou 8 respostas e 7 pessoas participaram, sendo elas: eu, Janaina Trilles, Sarah Pimentel, Maria Meire, Edwagney Luz, Felipe Silva e Bruno Augusto.

Abaixo segue um resumo da discussão, baseado nas duas perguntas principais da mesa redonda. Quem quiser acessar a discussão na íntegra, pode acessar por meio deste link.

Por que os desenvolvedores não fazem testes de unidade e integração?

A Sarah Pimentel deu a sua resposta baseada na sua experiência, dizendo que:

Alguns casos que vivenciei era mais uma questão de conversar não com os desenvolvedores, mas com os gerentes. Nem sempre é “má vontade” dos desenvolvedores, em alguns casos é falta de tempo mesmo. O gerente não prevê a criação/execução de testes unitários e se o desenvolvedor aumentar a estimativa dele de desenvolvimento para englobar os testes unitários o gerente vai cair em cima e cortar o tempo da estimativa.

A aplicação de testes, de uma forma geral, não só os unitários, mas também os de sistema, está sempre envolta em muitas questões culturais.

O Edwagney fez um comentário bem interessante sobre a questão, colocando que a acomodação é um dos motivos para que os desenvolvedores não realizem testes de unidade e integração.

Esse é um tema bastante interessante e um grande indício de que o ser humano é sim acomodado e gosta de entrar numa zona de conforto e para não sair de lá jogar a culpa no tempo. Explico!

As tecnologias de hoje permitem ganhar muito mais tempo com desenvolvimento do que anos atrás. Quem foi desenvolvedor nas décadas de 80 e 90 sabem do que estou falando. Nessa época não tínhamos ainda o conceito de teste formal de software, como temos hoje e TODA a execução do teste era feito pelos próprios desenvolvedores. Já ouviram falar em “teste de mesa”? Para quem nunca ouviu falar disso, esse é um teste que era feito “à mão” usando papel e caneta onde os desenvolvedores simulavam a entrada de dados nas suas estruturas condicionais e de repetição, e verificavam se essa estrutura iria funcionar da forma como eles imaginavam para o desenvolvimento.
Esse era o teste unitário. Ele era feito por qualquer bom desenvolvedor. Era a forma de garantir que ao menos as principais funcionalidades estavam funcionando de forma isolada.

Esse método também era bastante usado nos testes de integração, onde os próprios desenvolvedores se viam na necessidade de testar seus módulos de forma integrada. O ambiente era direcionado a esse teste. Quem faria isso? Ninguém… Éramos nós mesmos.

Quando começaram a surgir as novas tecnologias, reduzindo o tempo de desenvolvimento e os conceitos de teste, os desenvolvedores entraram em uma tamanha acomodação que hoje nem mesmo os testes básicos eles fazem mais. Como assim? Há não… Vou perder meu tempo testando pra quê, se existe uma equipe só pra fazer isso?

Minha reflexão em relação a tudo isso é, existe culpa dos desenvolvedores por não mais executarem os testes?

Penso que atribuir culpa a alguém ou a alguma área é a forma mais fácil de taparmos o sol com a peneira. Não é assim que funciona. Antes de botar culpa em alguém façamos algumas reflexões:

Qual a política de testes foi adotada pela empresa? Todos na organização conhecem essa política? Todos a conhecem e sabem falar dela para outras pessoas (com propriedade)?

Essa política atribui papéis e responsabilidades bem definidos? A equipe de desenvolvimento sabe exatamente qual teste é executado pela equipe de teste?

O que aconteceu com os desenvolvedores que os fizeram a não executarem mais testes é simples. ACOMODAÇÃO.

De novo, culpa deles, não. Isso é natural do ser humano. Os desenvolvedores se acomodaram, pelo fato de acharem que, se existe uma equipe de teste, eles VÃO executar todos os testes no software. Só que em nenhum momento falaram para eles que não é bem assim. Cada um tem o seu escopo e sua participação no processo, isso É OBRIGAÇÃO DA ORGANIZAÇÃO em comunicar todos e todas as areas na empresa.

Para o Felipe Silva vários fatores contribuem para que o desenvolvedor não realize tais testes:

1. Penso na primeira como sendo a desvalorização de tais testes primeiramente por quem cobra os desenvolvedores (aquele que fica pondo pressão) e consequentemente pelos desenvolvedores (que se mostrarem baixo desempenho – por estarem testado tudo que supostamente deveriam testar – podem acabar perdendo o emprego),
2. O segundo ponto é a cultura de trabalho reativo acomodada na organização, que sem perceber (as vezes por que se negam a aceitar que isso ocorre sempre) preferem fazer duas vezes do que fazer o certo na primeira vez,
3. O terceiro ponto é os desenvolvedores não saberem que o processo de testes é composto por vários testes e que a equipe de teste não faz todos (não ainda), se eles não sabem disso é porque não deram condições para isso.

Em nenhum dos 3 casos eu os culpo (desenvolvedores) por isso, pois acho que a coisa começa em cima e reflete em baixo.

Na minha opinião alguns motivos para que o desenvolvedor não realize testes unitários e de integração são:

• Existe uma rede de proteção chamada equipe de Testes;
• Não tem
  • motivação;
  • conhecimento sobre testes;
  • noção do quanto dos benefícios de ter testes de unidade e integração;
• São uns bundões e/ou imaturos;
• Auto-confiança em excesso, “para que testar fui eu que desenvolvi”;
• Dão manutenção em sistemas legados;

O grande problema é quando dois ou mais motivos juntam, o que é comum.

O que podemos fazer para incentivar/ajudar os desenvolvedores a realizar tais testes?

A Janaina Trilles compartilhou a sua dificuldade, que acredito que também seja a de muitos, mas acredito que o caminho seja tendo persistência mesmo, tentando ir mudar aos poucos.

Eu tenho grande dificuldade de fazer os desenvolvedores ter a cultura dos testes unitários, é sempre um problema na empresa .Não sei como eu posso mudar esse conceito, já falei que fazendo isso dimínui bastante defeitos e gera menos retrabalho.

Segundo o Felipe Silva, podemos ajudar sim, mas é algo que irá dá trabalho e demorará, uma vez que o problema muitas vezes está na cultura da equipe/empresa.

1. Ter no cronograma condições de se fazer estes testes, e fazer sem ser atropelado. Ter essas condições no cronograma não necessariamente significa aumenta o tempo do cronograma, pode-se pensar em N soluções para otimizar o tempo gasto em certas tarefas ou automatizar as que forem possíveis,
2. A organização, precisa ser “testadora”, digo, ser do mesmo time que nós, não somos “aqueles que apontam os defeitos”, somos “um de nós”, somos amigos do sucesso organizacional (pois tais testes ajudam tanto a ter melhor qualidade no produto entregue quanto ajuda reduzir o tempo gasto com testes funcionais), isso aqui não é da noite pro dia, mas tem que ser trabalhado incansavelmente a nível macro (todos envolvidos no projeto).
3. Alguma estratégia de divulgação da cultura de testes, do dia a dia, do que é feito e o que não é feito pelos testadores, seja por treinamento ou por qualquer outra forma que consiga atingir o objetivo de levar os opressores (líderes) e oprimidos (desenvolvedores) ao conhecimento do efeito negativo de se trabalhar reativamente.

Fácil falar e trabalhoso e não tão rápido de se conseguir, pois é humano, é cultural, é organizacional, envolve métricas, envolve dinheiro, envolve o cliente, envolve o emprego de cada um.

Eu penso, que podemos ajudar divulgando conteúdos relacionados ao assunto, dá uma palestra na empresa sobre esses testes, etc.

Se você tiver conhecimento/domínio sobre alguma linguagem de programação, pode conversar com o desenvolvedor para combinar um dia de sentar junto para tentar escrever alguns testes de uma funcionalidade que ele for implementar.

Realmente, introduzir testes unitários e de integração no desenvolvimento é um processo que costuma ser demorado, não é fácil mudar a cultura dos desenvolvedores, principalmente, pelo fato que eles têm que sentir que testes são importantes, pois é algo que terá que ser mantido, caso contrário, iremos ver a teoria das janelas quebradas na prática.

Bem pessoal é isso. Até a próxima! 🙂

Fique por dentro das novidades, assine o feed do QualidadeBR.

Técnicas de Integração de Sistema – Big Bang e Sandwich

Para finalizar a série de posts sobre técnicas de integração de sistema, irei abordar a técnica Big-bang e a Sandwich.

Big-Bang

Na técnica Big-bang, os módulos são testados isoladamente e depois integrados de uma só vez, como pode ser visto na figura abaixo.

Para executar uma integração usando a técnica Big-bang necessitamos de stubs e drives para testar os módulos isoladamente.

Ela é normalmente usada devido às pressões do dia a dia e os testes são aplicados para demonstrar uma operabilidade mínima do sistema.

O maior problema do uso da técnica Big-bang é caso haja alguma falha na interface de um módulo com outro, pois neste caso, será difícil ser preciso e encontrar a causa da falha. Já que ela é uma técnica que usa uma abordagem não incremental.

Vantagens

• Conveniente para sistemas pequenos

Desvantagens

• Necessita de drivers e stubs para cada módulo;
• Só permite o teste em paralelo no início dos testes;
• Localização difícil da falha;
• Fácil perder falhas de interface.

Sandwich

Na técnica Sandwich, um sistema é integrado misturando a técnica Top-down com a Botton-up, dividindo o sistema em três camadas:

• Lógica – camada que contém os módulos que são mais frequentemente chamados. Esta camada é testada utilizando a técnica Bottom-up;
• Meio (middle) – são os restantes dos módulos;
• Operacional- camada que contém os módulos principais, do ponto de vista operacional. Sendo testada utilizando a técnica Top-down.

Muitas vezes uma abordagem combinada Top-down para os níveis superiores e Botton-up para os níveis inferiores pode ser o melhor ajuste para o teste de integração da sua aplicação. Se os níveis superiores da estrutura do programa forem integrados de cima para baixo, o número de drivers pode ser reduzido substancialmente na integração dos módulos inferiores. Agora se os módulos inferiores forem integrados de baixo para cima, o número de clusters (módulos que executam uma sub-função do sistema) pode ser reduzido substancialmente na integração dos módulos superiores.

Usando a técnica Sandwich a integração é mais flexível e adaptativa, porém ela é mais complexa de ser planejada.

Comparação

Para encerrar o último post dessa série, segue abaixo, uma tabela comparativa das 4 técnicas de integração que vimos nessa série:

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Chapter 8 – Testing the Programs, Software Engineering: Theory and Practice: wps.prenhall.com/wps/media/objects/3087/3161346/slides08.ppt

V. Binder. Testing Object-Oriented System: Models, Patterns, and Tools. Addison Wesley, 2000.

Aula 13 – Teste de Software, Walter de Abreu Cybis: http://www.inf.ufsc.br/~cybis/ine5322/Aula13_Teste_de_SW_cont.pdf

System Integration, Dr. Stéphane S. Somé. University of Ottawa: http://www.site.uottawa.ca/~ssome/Cours/SEG3203/integration.pdf

Técnicas de Integração de Sistema – Bottom Up

Continuando a série de posts sobre as técnicas de integração de sistema, aliás, preciso parar de começar e não terminar essas séries de posts (a das resoluções de questões da CTFL terminou, pelo menos por enquanto :)).

No último post sobre técnicas de integração de sistema, tínhamos comentado sobre a Top-down. Agora irei falar sobre a inversa da Top-down a Botton-up.

Na técnica Botton-up, a integração do sistema começa com a partir do nível mais baixo do software, ou seja, o módulo. O módulo é dito como o mais baixo nível se ele não depende de outro módulo. A Bottom-Up assume que todos os módulos foram individualmente testados antes.

Para integrar um conjunto de módulos usando a Bottom-Up, nós precisamos construir driver (controlador) que chamará o módulo a ser integrado. Uma vez que a integração de um grupo de baixo nível de módulos tenha sido considera satisfatória, o driver irá substituir o atual módulo e um ou mais drivers serão usados para integrar mais módulos com um conjunto de módulos já integrados. O processo de integração Botton-Up continua até todos os módulos terem sido integrados.

Segue abaixo um exemplo de uma integração usando a técnica Botton-up:

Integração Bottom-up dos módulos E, F, e G

Integração Bottom-up dos módulos B, C, e D com o E, F, e G

Integração Bottom-up do módulo A com todos os outros.

As vantagens da técnica Botton-up são:

• Permite verificação antecipada de comportamento de baixo nível;
• Stubs não são necessários;
• Mais fácil para formular dados de entrada para algumas sub-árvores;
• Mais fácil para interpretar dados de saída para outras sub-árvores.

As desvantagens da técnica Botton-up são:

• Os testadores não podem visualizar as funções em nível de sistema a partir de uma parte do sistema já integrada. Aliás, eles não podem visualizar as funções em nível de sistema até o último driver ser colocado;
• Geralmente, as decisões principais estão incorporadas nos módulos de alto nível. Desta maneira as principais falhas do sistema não podem ser encontradas até que os módulos de alto nível estejam integrados. Logo a verificação de comportamento de  alto nível é retardada.

Após ter visto a técnica Botton-up e a Top-down (aqui), podemos comparar as duas:

• Validação das principais decisões: Os módulos de alto nível contêm as principais decisões. As falhas na modelagem dessas decisões são detectadas antecipadamente, se a integração realizada é a Top-down. Na técnica Botton-up, essas falhas são detectadas no final do processo de integração;
• Dificuldade em elaborar os casos de teste: na abtécnica Top-down, como mais e mais módulos são integrados e stubs são utilizados mais distantes do módulo de alto nível, torna-se cada vez mais difícil a elaboração do comportamento do stub e a entrada do teste. No entanto, na técnica Botton-up, um comportamento é elaborado para um driver, através da simplificação de um comportamento de real do módulo;
• Reusabilidade de casos de teste: usando a técnica Top-down os casos de teste são elaborados para testar a interface de um novo módulo e pode ser reusado para fazer testes de regressão nas próximas iterações. E futuramente os casos de teste podem ser reusados para o teste de nível de sistema. No entanto, usando a técnica Botton-up, todos os casos de testes incorporados aos drivers, exceto o driver para o teste alto nível, não podem ser reusados.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

NAIK, Kshirasagar; TRIPATHY, Priyadarshi. Software Testing and Quality Assurance. Hoboken (New Jersey): John Wiley & Sons, Inc., 2008.

Teste de Integração, Sistema e Aceitação, Alexandre Mota. (link)

Técnicas de Integração de Sistema – Top Down

A Top Down, que em tradução literal seria algo como “de cima para baixo”, é uma das técnicas mais conhecidas para teste de Integração usando a abordagem incremental.

Como se pode perceber pelo próprio nome, usando a técnica Top-down, o teste começa do nível mais alto para o mais baixo, ou seja, os componentes de mais alto nível são integrados primeiro.

Para entender melhor, vamos pensar no exemplo abaixo:

Exemplo Top Down

Como pode ser percebido, o sistema nesse exemplo, é o álbum de música, que é formado por várias músicas, que serão chamadas de componentes. Por fim, uma música é formada pela junção de vários instrumentos, que serão chamados de módulos.

Pela técnica Top-down iremos primeiro testar os componentes de alto nível, que são as músicas, só para depois verificar cada módulo (instrumento) de cada componente (música).

Algo importante de se notar, é que no final do Teste de Integração teremos a integração dos módulos testados e não o sistema como um tudo. Na analogia apresentada, teríamos cada música verificada e não o álbum inteiro. O teste que verificaria o álbum inteiro seria o Teste de Sistema.

Vantagens

• Permite verificação antecipada de comportamento de alto nível;
• Módulos podem ser adicionados, um por vez, em cada passo, se desejado;
• Permiti a busca em profundidade (depth-first search) e a busca em largura (breadth-first search).

Desvantagens

• Retarda verificação de comportamento de baixo nível;
• Entradas de casos de teste podem ser difíceis de formular, por geralmente, demandar de uma entrada maior de informações;
• Saídas de casos de teste podem ser difíceis de interpretar, cada passo executado, pode gerar um resultado e o Tester deverá ficar atento a esses resultados, pois essas saídas intermediárias pode apresentar alguma inconsistência.

Bem, hoje vimos como que a técnica Top-down funciona na realização dos Testes de Integração, espero ter ajudado na compreensão dessa técnica, caso tenha ficado alguma dúvida, sinta-se à vontade em colocá-la nos comentários. Até a próxima!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Teste de Integração, Sistema e Aceitação, Alexandre Mota. (link)

Técnicas de Integração de Sistema – Incremental

Ao realizar os testes de integração uma dúvida que pode surgir é a de como combinar os módulos do software. Existem 5 abordagens diferentes para realizar a junção dos módulos, a fim de obter a montagem de todo o sistema:

• Incremental
• Top down
• Bottom up
• Sandwich
• Big bang

Neste post, irei falar sobre a abordagem Incremental, que como o próprio nome sugere ocorre aos poucos, módulo a módulo.

A interação ocorre através de uma série de ciclos de teste. Em cada ciclo de teste, os módulos vão se integrando com os já existentes e testados para gerar maiores módulos. A idéia é concluir um ciclo de testes, os desenvolvedores corrigirem todos os erros encontrados, e continuar o próximo ciclo de testes. O sistema completo é construído incrementalmente, ciclo por ciclo, até que o sistema esteja operacional e pronto para a realização dos testes de nível de sistema.

Uma aplicação da abordagem Incremental ocorre frequentemente na fabricação de bolos: a confeiteira degusta a massa do bolo antes de colocá-la no forno, e antes de colocar a cobertura ela verifica a sua consistência e sabor.

A seguir veremos as vantagens e desvantagens do uso da abordagem Incremental na realização dos testes de integração, sendo interessante notar que boa parte das vantagens e desvantagens apresentadas, também ocorre no desenvolvimento incremental.

Vantagens

• O tester não precisa esperar até que todo o sistema esteja pronto, para iniciar os testes;
• Há um menor risco de fracasso geral do projeto, já que cada módulo é verificado antes e caso algo esteja errado a correção será implementada já no próximo ciclo de teste;
• A integração dos módulos só é realizada, após eles já terem sido verificados, ou seja, se algum erro acontecer a causa, provavelmente, será a comunicação entre esses módulos.

Desvantagens

• A modulação pode ser uma tarefa difícil de ser realizada, pois os módulos necessitam ser pequenos, mas com alguma funcionalidade completa;
• Em determinadas situações, a realização do teste só poderá ser feita com a utilização de Mock Object.

Considerações Finais

Na utilização da abordagem Incremental para a realização dos testes de integração, alguns aspectos devem ser considerados, tendo em vista o número de ciclos de testes:

• O número de módulos do sistema;
• A complexidade dos módulos;
• A complexidade da interface entre os módulos;
• O número de módulos a serem usados para o agrupamento em cada ciclo de teste;
• Verificar se os módulos a serem integrados foram devidamente testados antes;
• O tempo de resposta da equipe de desenvolvimento em cada ciclo de teste.

Por hoje é só pessoal. Em breve comentarei sobre a técnica Top-down, que é uma técnica de fazer a integração de forma incremental. Até lá!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

NAIK, Kshirasagar; TRIPATHY, Priyadarshi. Software Testing and Quality Assurance. Hoboken (New Jersey): John Wiley & Sons, Inc., 2008.

alisson.brito.googlepages.com/ProcessoDeSoftware_AlissonBrito.ppt