Autor: Vagner Carlos Marcolino Lima (aluno do Mestrado Profissional em Computação Aplicada da UTFPR)
O principal objetivo do artigo é investigar os potenciais fatores que podem limitar a adoção industrial de TDD. Os autores buscaram contribuir com: (a) uma análise qualitativa dos efeitos de um conjunto de fatores sobre TDD com base nos estudos primários selecionados na revisão; (b) uma identificação do conjunto de fatores limitantes; e por fim, (c) uma discussão das implicações para pesquisa e indústria desses fatores.
Para realizar tal investigação eles utilizaram o método de Revisão Sistemática da Literatura, o qual busca responder uma questão ou uma hipótese (Quais fatores podem limitar a adoção industrial de TDD?) a partir da composição e agregação de evidências de estudos primários, sendo eles selecionados a partir de um protocolo especifico. Os autores utilizaram como base o protocolo proposto por Kitchenham e Charters (2007). Os passos que os autores seguiram são apresentados abaixo:
- Processo de busca:
- Começa com o desenvolvimento do protocolo de revisão, ele descreve o proposito da revisão, questão de pesquisa, critérios preliminares de inclusão e exclusão dos artigos, detalhes da string de busca e bases de dados;
- A partir da string de busca definida, a busca foi realizada na língua inglesa, e foi uma busca completa (full-length), o resultado foi coletado pela ferramenta EndNote;
- Foram excluídos "short papers" (menos de seis páginas), tutoriais, trabalhos em andamento, palestras e lições apreendidas industriais puras.
- Processo de exclusão de artigo: foram removidos artigos
- Primeiro estágio, duplicados, com base no critério citado no item 1 e no titulo (off-topic);
- Segundo estágio, baseados no abstract;
- Terceiro estágio, baseados no texto completo. Neste estágio cada artigo foi lido por pelo menos dois pesquisadores, e para avaliar a qualidade dos artigos eles utilizaram questões semelhantes às utilizadas por Dyba e Dyngsoyr (2009). Aqui, especificamente, os autores investigaram: 1) se o artigo foi um artigo de pesquisa; 2) se foi uma avaliação da TDD; 3) se o objetivo de pesquisa estava claramente definido; 4) se o artigo tinha uma descrição adequada do contexto/configuração. Por fim, os artigos passavam por esse estagio se a seguinte expressão boleana fosse verdadeira: (1 AND 2 AND (3 OR 4)).
- Processo de extração de dados:
- Primeiro passo: extração dos dados gerais e efeitos declarados explicitamente de TDD sobre requisitos para uma adoção bem sucedida de TDD; b) segundo passo: a matriz resultante (efeitos x estudos primários) foi revista.
- Síntese dos dados: os fatores limitantes foram definidos com base nas 18 áreas de efeito, seguindo as seguintes regras:
- A área de efeito continha pelo menos dois estudos com observações de efeitos negativos de ou sobre TDD;
- A área de efeito continha mais estudos negativos do que positivos de ou sobre TDD;
- Efeitos negativos na área de efeitos foram observados em pelo menos um estudo executado em ambiente industrial.
A partir da revisão sistemática os autores levantaram 18 áreas de efeitos de TDD. E, com base nessas áreas eles identificaram os 7 fatores limitantes, a saber.
FL1 – Tempo de Desenvolvimento
(ou aumento no tempo de desenvolvimento)
Para esse fator houve 9 estudos com menção negativa, sendo 6 da indústria com profissionais (5 estudos de caso e 1 experimento) e 3 acadêmicos com estudantes (2 experimentos e 1 estudo de caso), entretanto, 5 estudos com menção positiva, mas isso na maioria deles considerando tempo geral do projeto.
O tempo de desenvolvimento pode ser considerado um fator crítico para o negocio, por isso ele deve ser um limitante. Entretanto, dependendo da maturidade da organização a perda inicial (aumento no tempo de desenvolvimento) pode sobrepor o ganho em longo prazo com os outros benefícios do TDD.
FL2 - Experiência/conhecimento
(ou experiência/conhecimento de TDD insuficiente).
Para esse fator houve 2 estudos com profissionais com menção negativa (atribuíram problemas de implementação de TDD por falta de treinamento/experiência em TDD) e mais 2 estudos que apontaram diferenças significantes na forma de aplicar TDD quando realizada por desenvolvedores experientes ou novatos.
Notou-se que os participantes na maioria dos experimentos receberam algum tipo de treinamento. A experiência/conhecimento sobre TDD é quase que um pré-requisito.
FL3 – Projeto
(ou falta de projeto inicial – “upfront”).
Para esse fator houve 3 estudos com menção negativa (2 experimentos acadêmicos e 1 estudo de caso com profissionais), alegam problemas arquiteturais quando usa-se TDD.
As evidências empíricas, os estudos primários avaliados, não suportam que a falta de projeto no inicio pode ser considerado um fator limitante para adoção de TDD. Da mesma forma que não há evidências que suportam que somente o "projeto TDD" é bom.
FL4 – Habilidades em teste
(ou falta de habilidade do desenvolvedor em escrever casos de teste)
Para esse fator houve 2 estudos com menção negativa (1 experimento acadêmico com estudantes e 1 estudo de caso com "mix" de profissionais e estudantes).
Se TDD baseia-se na criação de casos de teste no inicio de cada ciclo, logo, seria interessante que o desenvolvedor tivesse a habilidade/conhecimento em projeto de casos de testes. E mais, pensamos que não há investigações explicitas da qualidade dos casos de testes produzidos pelos desenvolvedores TDD.
FL5 – Aderência TDD
(ou aderência insuficiente ao protocolo TDD)
Para esse fator houve 3 estudos de casos com profissionais com menção negativa, na realidade, por vários motivos, acabavam abandonando o protocolo TDD, e mais, 2 estudos de caso com profissionais que reportaram correlação entre baixa aderência ao protocolo e baixa qualidade.
A combinação dos cinco estudos que motiva a inclusão deste fator. No entanto, é longe de ser certo que há uma relação bem delineada de causa-efeito entre baixa adesão ao protocolo TDD e baixa qualidade. Não improvável que fatores de confusão (por exemplo, prazos de desenvolvimento apertados) podem levar tanto a baixa adesão TDD baixo quanto a má qualidade.
FL6 – Questões específicas de ferramenta e domínio
Para esse fator houve 9 estudos com menção negativa (5 estudos de caso com profissionais, 1 pesquisa (survey) na indústria com profissionais e estudante e 3 experimentos acadêmicos.
Ferramentas de suporte são vitais para o TDD. Com a quantidade razoável de "negativas" (9 estudos) dificilmente esse fator seria ignorado. As situações mais problemáticas são ferramentas para suportar a aplicação de TDD em (a) aplicações GUI e (b) aplicações em rede.
FL7 – Código Legado:
Para esse fator houve 2 estudos de caso com profissionais mencionaram problemas com o manuseio (tratamento) de bases de código legado.
TDD, na sua forma original, não discute como manter código legado. Ao invés disso ela parte do princípio que o código será escrito desde o início usando TDD. Em grandes organizações isso é raro, logo, adotar TDD pode ser problemático. Sem os suítes de regressão adequados para tal situação os desenvolvedores ficam ansiosos ou até temerários em manter código legado.
E mais, os autores delinearam pesquisas futuras na perspectiva da comunidade de teste de software, por exemplo, em linhas gerais, como integrar as perspectivas dos testadores TDD e testadores tradicionais.
Por fim, o processo de busca e exclusão dos artigos foi abrangente e os delineamentos para trabalhos futuros – ainda que com certo viés – não são triviais, porém o critério de definição dos fatores limitantes foi um pouco incipiente, seria razoável, por exemplo, definir pesos para os tipos de estudos, e com isso, possivelmente a quantidade – que foi pequena – e os tipos de fatores limitantes mudariam.
Referência
[1] CAUSEVIC, A. SUNDMARK D. PUNNEKKAT, S. Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5770623&tag=1>
Acessado em: 09 nov. 2010.
