A evolução da engenharia de software deu-se a partir do modelo de cascata que propunha fases estanques para o desenvolvimento de software [123]. Do aprimoramento do modelo de cascata surgiram novos processos, tais como o modelo em espiral e o Rational Unified Process (RUP) [31], todos com grande ênfase na documentação do processo.
Devido à grande quantidade de fracassos de projetos de software [66, 67, 65], nas últimas décadas alguns líderes de projetos adotaram modos de trabalho que se opunham a este modelo tradicional, e tiveram grandes sucessos [57]. Até que em 2001, 17 desses líderes, que possuíam formas de trabalho semelhantes, juntaram-se para debater metodologias de desenvolvimento na tentativa de criar um novo método que agregasse as melhores ideias. No entanto, essa discussão levou à conclusão de que era difícil definir um método perfeito para todas as situações; no entanto, chegou-se a um consenso de 12 princípios, que foram sintetizados nas premissas do Manifesto Ágil [18].
Dentre os métodos ágeis que satisfazem o manifesto, existem os que focam em aspectos mais geren- ciais, como Lean [109, 112] e Scrum [131], e outros que também dão ênfase a práticas de desenvolvi- mento de software tal como a Programação eXtrema (XP) [17]. Todos preconizam o controle de quali- dade disseminado por toda a equipe e durante todo o desenvolvimento.
O controle de qualidade no desenvolvimento com métodos ágeis normalmente é associado à au- tomação de testes, já que essa prática surgiu da mesma comunidade. Automação de testes é uma das práticas primárias de XP [15]. As baterias de testes podem ser executadas sem esforço a todo momento, o que possibilita a verificação contínua da qualidade do sistema durante e após a implementação.
No entanto, a automação de testes não é exclusiva dos métodos ágeis e nem depende significa- tivamente de outras práticas, por isso é uma técnica de desenvolvimento independente que pode ser empregada por qualquer equipe utilizando qualquer metodologia, mesmo as mais tradicionais. Também é importante ressaltar que os métodos ágeis não se opõem a quaisquer revisões adicionais que sejam
feitas para aumentar a qualidade, apenas não é uma prática primária da filosofia. 2.4.1 Programação eXtrema
A Programação eXtrema, também conhecida como XP (de Extreme Programming), foi criada por Kent Beck em 1996, o mesmo criador do arcabouço de testes SUnit [13], que serviu de referência para muitos outros arcabouços de testes automatizados. XP surgiu de um desafio de reverter a situação de um projeto de folha de pagamento da empresa Chrysler, que já havia estourado os limites de custos e prazos. Para isso, o projeto adotou uma nova metodologia, que aplicava, ao extremo, um conjunto de práticas recomendadas de programação [19, 6] com disciplina e organização. Devido ao sucesso do projeto, Kent Beck reuniu as práticas que trouxeram os méritos da metodologia e a oficializou como Programação eXtrema, através do primeiro livro de XP [15].
Dentre as práticas recomendadas por XP temos os Testes Automatizados [44], que estão diretamente relacionados a outras práticas da metodologia. Algumas das práticas de XP dependem fortemente dos testes para que sejam executadas com sucesso. Por isso, para aplicar XP apropriadamente, é fundamental o emprego efetivo de testes automatizados. A seguir, descrevemos as principais práticas de XP que se relacionam diretamente com testes automatizados.
Refatoração
Refatoração é o processo de alterar um sistema de software para aperfeiçoar a estrutura interna do código-fonte sem alterar seu comportamento externo [59, 110]. Este processo, realizado através de passos pequenos e sistematizados, é um artifício poderoso para aprimorar o design da aplicação e melhorar a legibilidade e clareza do código. Existem ferramentas que auxiliam na automatização dessa tarefa [14, 122, 79] e estudos de refatorações em outras área do projeto, tais como banco de dados [4].
No entanto, como toda manutenção de código, refatoração também está sujeita a introduzir erros no projeto, seja através do descuido ou do manuseio incorreto de ferramentas. Por isso, é essencial que exista uma boa bateria de testes automatizados que assegure que os comportamentos não foram modificados indevidamente. Do ponto de vista do cliente, um erro introduzido em uma parte do sistema que estava funcionando corretamente pode ser frustrante, por isso o uso de testes automatizados em conjunto com a refatoração é uma prática fundamental.
Propriedade coletiva do código
Propriedade coletiva do código é a prática que propõe que todos os membros da equipe são responsáveis de alguma maneira por todo o código-fonte e, portanto, todos têm total liberdade para trabalhar em cima do código criado por outro membro. Essa prática é fundamental para não tornar um projeto dependente de um programador específico, assim como ajuda na velocidade do desenvolvimento, dado que qualquer trecho do código pode ser modificado a qualquer momento, aumentando a disponibilidade de trabalho e direcionando os esforços em algo que agrega valor diretamente ao produto final.
No entanto, esta prática traz riscos já que cada desenvolvedor possui ideias e maneiras próprias de solucionar problemas de computação. O conflito de soluções pode desorganizar o código-fonte e estragar o que estava funcionando. Portanto, esta é uma operação muito suscetível a erros e merece um controle de qualidade com alta cobertura de casos de testes que possam ser executados a qualquer momento e de forma ágil, como é possível com testes automatizados.
Designincremental
É uma das práticas mais conflitantes com as metodologias tradicionais, pois ela incentiva a não planejar todo o esqueleto da aplicação de uma só vez, e sugere que o design seja construído gradativamente de
acordo com o aprendizado da equipe e as necessidades prioritárias do cliente.
Entretanto, alterações de design e de arquitetura no sistema podem ser muito perigosas já que po- dem afetar diversos módulos do sistema, ou seja, muitas classes poderão ter de ser refatoradas. Essas alterações são ainda mais críticas quando utilizadas linguagens com tipagem dinâmica, que não possuem ajuda do compilador para verificação de tipos de variáveis, pois as interfaces de muitas classes podem ser alteradas, o que possibilita a inserção de erros de integração.
Por isso, a extrema importância de testes que sejam abrangentes, como os testes automatizados de integração e aceitação. Técnicas de escrita de testes, como Desenvolvimento Dirigido por Testes e por Comportamento (vide Capítulo 9), também influenciam diretamente no design, dado que ele emerge à medida que novos casos de testes são adicionados.
Integração Contínua
Integração Contínua é uma premissa do desenvolvimento incremental e das entregas frequentes ao cliente. Ela tem como objetivo integrar rotineiramente o sistema e todas suas dependências para ver- ificar que nenhuma modificação tenha danificado o sistema, sejam elas alterações no código-fonte, em configurações ou mesmo em dependências e outros fatores externos [52].
Parte do processo de verificação é feito pelo próprio compilador que verifica erros estáticos do código-fonte e de mapeamentos de dependências. Já os erros de lógica, de configuração e integração de componentes só podem ser verificados em tempo de execução, por exemplo, através de testes autom- atizados. Muitas ferramentas para automação de testes já possuem artifícios que facilitam a execução automática dos casos de testes, o que facilita a configuração nos ambientes de integração contínua. Entregas Frequentes
O ciclo de entrega de versões para o cliente deve ser curto, assim a equipe foca seu tempo nas tarefas mais prioritárias e o cliente consegue dar feedback rápido a respeito do software produzido. Segundo as metodologias ágeis, é dessa aproximação, entre cliente e equipe de desenvolvimento, que o software evolui da melhor forma para atender às principais necessidades do cliente.
Entregas frequentes implicam alterações rotineiras no código do sistema, tornando o software alta- mente vulnerável a erros de regressão, que é um dos principais tipos de erro que os testes automatizados ajudam a prevenir. Essas alterações vão se tornando cada vez mais perigosas à medida que o sistema fica mais extenso e mais complexo, por isso fazer entregas frequentes só são interessantes quando há segurança para fazer as modificações.
Tracking
Acompanhamento do projeto ou tracking é uma das atividades propostas em XP para ajudar a geren- ciar o desenvolvimento do software. Esta atividade se dá através da coleta, observação e interpretação de métricas (Capítulo 10). As métricas que serão coletadas e analisadas dependem do contexto atual do sistema e das decisões tomadas pela equipe, isto é, a metodologia não possui regras ou métricas obrigatórias que devem ser monitoradas.
Entretanto, o acompanhamento da qualidade do produto final é natural em projetos sérios que val- orizam a criação de bons produtos. Todavia, qualidade é um aspecto subjetivo, então é necessário utilizar diversas métricas que consigam representar satisfatoriamente a qualidade do produto final. Entre uma infinidade de aspectos que podem ser acompanhados, estão o design, elegância e simplicidade do código-fonte, assim como as métricas de testes automatizados. Como os testes influenciam diretamente na qualidade do produto final, as métricas são fundamentais para o acompanhamento e gerenciamento da qualidade do projeto.
Metáfora, Envolvimento real com o Cliente e Testes de Aceitação
A comunicação efetiva é fundamental para o sucesso de um sistema de software, contudo ela não é trivial. Mesmo um texto sem ambiguidades pode ter interpretações diferentes por seres humanos, já que a discrepância de conhecimento e de vocabulário podem levar a múltiplas interpretações. É natural que pessoas de comunidades específicas tenham um modo de falar e escrever peculiar, utilizando termos próprios ou mesmo um vocabulário formal que não é rotineiro para outras comunidades.
É por isso que XP incentiva um envolvimento real com o cliente, para que a equipe e os clientes eliminem problemas de má interpretação e criem um vocabulário próprio a partir de metáforas que todos consigam interpretar da mesma maneira. Uma forma de facilitar a criação de metáforas é através dos testes de aceitação que criam uma ponte de comunicação entre cliente e desenvolvedores por meio de documentos úteis que ajudam a encontrar defeitos e a certificar que o sistema é válido, isto é, faz o que deveria ser feito.
Como foi descrito no decorrer de toda essa Seção, testes automatizados estão fortemente relacionado com as principais práticas de métodos ágeis. Para algumas delas, a escrita de testes automatizados é um pré-requisito, enquanto, para outras, a automação dos testes traz muitas vantagens.