Ontem, às 19:00 teve início a segunda parte da palestra “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, feita pelo Jorge Diz, no 6º Encontro Mensal da ALATS. A primeira parte da palestra ocorreu no final do mês setembro (30/09/09), porém teve que ser encerrada, antes do seu término, por ter ultrapassado o tempo disponível.
Abaixo, compartilho as minhas impressões sobre o encontro.
Sprint 1
Como de costume (aliás, um mal costume) cheguei em cima da hora. Ao entrar no auditório percebi que público presente era menor do que da última palestra, totalizando 9 pessoas. E dentro do auditório tinha uma mesinha, com o coffee, o que me fez pensar que não haveria o break, fato que acabou se concretizando. Ou seja, o Jorge planejou passar todo conteúdo numa sprint única.
O início da palestra se deu com o palestrante falando sobre o novo modelo de testes, necessário ao se utilizar metodologias ágeis. Utilizando a excelente explicação do fluxo ponta-a-ponta (erro -> defeito -> falha -> diagnóstico -> correção), influenciado pela metodologias ágeis, onde:
- O erro pode ser evitado utilizando o conceito de Poka-yoke, como por exemplo, usando linguagens de tipagem forte (ex. Ruby);
- Outra maneira de utilizar uma ferramenta que execute automaticamente os testes, a cada mudança nos arquivos do projeto relacionados com a mudança, ou seja, uma ferramenta que faça um teste de regressão de acordo com a mudança realizada, para verificar se a mesma não quebrou nada. Exemplo de tal ferramenta é o Autotest (que faz parte do pacote ZenTest);
- Para encontrar defeitos é necessário… testes :);
- É possível facilitar a identificação do motivo da falha, analisando a pilha de execução, exceções, logs e utilizando predicados fluentes (uma maneira de torna mais legível o método);
- Para realizar o diagnostico é necessário ter uma gestão de configuração e depois reportar utilizando uma ferramenta de gestão de incidentes, famoso bugtracking;
- Após a correção, se faz necessário a realização dos testes de regressão.
Agora você pode está pensando: mas boa parte das coisas que foram citadas eu já realizo no meu dia-a-dia?
Porém, utilizando agile muita dessas tarefas são realizadas de forma automatizada, realizando integração contínua, que acaba minimizando a quantidade de defeitos que seriam encontrados pela pessoa que fosse realizar o teste. E o mais importante é que o foco das metodologias ágeis é que o feedback possa ser o mais rápido possível (lembra do manifesto ágil: “Indivíduos e interação entre eles mais que processos e ferramentas”. Trazendo isso para a realidade de Teste de Software, significa que o fluxo ponta-a-ponta será mais ágil;) o desenvolvedor pode receber o feedback da existência do defeito em “tempo de programação”, utilizando uma ferramenta do tipo Autotest.
Um ponto interessante que o Jorge Diz levantou, foi a carência de fontes falando sobre Teste de Software em metodologias ágeis, porém há uma excelente fonte, o livro da Lisa Crispin e Janet Gregory chamado Agile Testing (eu tenho ele, e recomendo fortemente aos interessados, é sem dúvida, a melhor bibliografia sobre o assunto até o momento).
Em seguida, o palestrante apresentou novamente a pirâmide frágil, na qual a maioria dos testes executados são testes de interface e poucos testes de unidade e integração são realizados. E o modelo ágil propõe uma inversão dessa pirâmide, como pode ser visto na figura abaixo.
Uma boa metáfora existente para explicar a diferença entre os três níveis de teste apresentados na pirâmide, feita pelo Patrick Wilson-Welsh, citado no livro Agile Testing, é a do três porquinhos. A camada de baixo é feita de tijolos, os testes são sólidos, e não vulneráveis ao sopro do lobo mau. Já a camada do meio é feita de madeira, precisa ser modificada com uma frequência maior do que a camada de tijolos, para permanecer resistente ao sopro do lobo mau. Por fim, a camada do topo é feita de palha, é difícil ela ser mantida no seu lugar e o lobo pode facilmente derrubá-la. Ou seja, se temos muitos testes feitos de palha, iremos precisar gastar muito tempo colocando-os no lugar.
Logo após, a explicação sobre a pirâmide dos testes, Jorge Diz falou sobre as escolas de teste, e os consensos que existem em comum entre elas:
- Não é possível testar tudo;
- Quem testa deve ter atitude crítica;
- Testes tem custo;
- Testes informam sobre risco;
- Áreas concentram defeitos (bug clusters).
Encerrada a parte dos consensos, chegou a hora de falar sobre automação de testes no contexto ágil. Parte na qual foi apresentada uma série de ferramentas, de acordo com cada nível de teste e também uma explicação de alguns conceitos.
Para iniciar o assunto, o Jorge Diz logo apresentou as vantagens e desvantagens da automação:
Vantagens
- Menos sujeita a falhas humanas, desatenção;
- Menos sujeita a interpretações;
- Executar testes automatizados é muito mais barato que manualmente, quando repetidos;
- Regressão torna-se mais abrangente.
Desvantagens/Dificuldades
- Dependência de sistemas externos;
- Dependência internas do sistemas;
- Controle sobre o ambiente;
- Lentidão em alguns tipos de teste;
- Fragilidade da API/interface usuário;
- Custo da automação pode ser alto;
- Necessidades de pessoas especializadas, o que geralmente, gera um maior custo.
O Jorge explicou um paradoxo bem interessante, o do campo minado, no qual ficou bem claro a necessidade de realizar variações de cenários/caminhos de teste. Afinal, o intuito testes é que as minas explodam. 😉
Continuando a explicação sobre automação de testes, foi a vez de falar sobre as ferramentas existentes para realizar testes de sistemas Web:
- Simular o browser – htmlUnit, Webrat;
- Executar in browser em javascript – Selenium;
- Adicionar browser a partir de um programa em Java – Selenium RC;
- Acionar browser a partir de um plugin do browser – Selenium IDE;
- Acionar browser a partir de um wiki – StoryTest IQ (Selenium + FitNesse);
- Acionar browser a partir de um editor de workflow – CubicTest (Selenium + plugin Eclipse).
E necessário ter conhecimento sobre o que estamos testando, com determinada ferramenta, e para explicar isso, o Jorge citou as seguintes ferramentas:
- Xunit – Módulos, classes isoladamente;
- FIT – regras de negócio;
- Cactus – funcionalidades de componentes web;
- Selenium– Interface usuário;
- JMeter – Estresse/desempenho.
Depois foi a vez de falar sobre as ferramentas XUnit, onde o Jorge começou falando que o programador gosta de programa e não gosta de tarefas manuais e repetitivas e por isso devem investir na utilização de tais ferramentas, para realizar os testes de forma automática e aumentar a qualidade do código.
Com testes automatizados, os programadores conseguem gostar de testes, e testar torna-se uma tarefa central do desenvolvimento.
Em um time focado em automação de testes, há algumas mudanças:
- Testes passam a ser ferramentas de desenvolvimento;
- Teste unitário ocorre paralelo à codificação;
- Rede de segurança para refatoramento;
- Exemplos de uso do código sendo desenvolvido;
- Complementos à compilação passam a existir (testes unitários, por exemplo);
- Especificação de comportamento;
- Validação para a integração contínua;
- Adoção de um ambiente comum;
- Infraestrutura para outros tipos de teste.
É importante também salientar as premissas para os testes unitários:
- Teste unitário centrado no desenvolvedor;
- Resultado independente da ordem de execução;
- Independência entre métodos de teste;
- A suíte de testes deve ser executada em alguns segundos;
- Todo recurso está sob controle do programador (não pode depender do link de internet, banco de dados, sistema legado, etc);
- Não é testada a integração;
- Testes na mesma linguagem que o código sob teste;
- Resultado não sujeito a interpretação (ou passou ou não passou);
- Não colocar if no método de teste, se tiver ele é suspeito.
O Jorge Diz falou que o grande problema de realizar testes unitários é lidar com dependências. Levantando os seguintes pontos:
- Se não consigo instanciar facilmente, não consigo testar;
- Dependências podem se manifestar apenas em tempo de execução;
- Dependências problemáticas precisam ser eliminadas ou substituídas.
Então a dúvida que surgiu foi: como lidar com dependências?
E a resposta: é preciso eliminar ou substituir.
Eliminar
- Mudança no design para melhorar a testabilidade (exemplo da “vareta” para verificar o nível de óleo do motor);
- Código-alvo precisa mudar para poder ser testado.
Substituir
- Colaboradores substitutos em tempo de testes;
- Dependências configuráveis(injeção de dependência, instrumentação).
E o importante: Se não conseguir eliminar ou substituir, não é teste unitário!
Em seguida o Jorge fez uma bela explicação sobre os colaboradores:
- Dummy (sub objeto) – esta aí apenas para cumprir tabela;
- Stub (método) – retorna uma resposta pré-definida;
- Mock (objeto)- define previamente o comportamento esperado das interações da classe-alvo com o colaborador (proativo se ver algo errado ele já avisa, pois ele já tem incorporado o que tem que ser feito no Play[quando executa o teste]);
- Fake (serviço/objeto) – substitui um serviço por uma implementação mais apropriada para o testes;
- Spy (método/objeto)- registra comportamento para verificação posterior.
E há duas maneiras de testar de forma unitária:
- Teste de estado – Verifica o estado da classe-alvo depois de exercitar uma funcionalidade;
- Teste de interação- Verifica a comunicação da classe alvo com seus colaboradores.
Logo após a explicação sobre testes unitários e o uso de Xunit, o Jorge começou a explicação sobre o Selenium, e suas variações, que é voltado para testes de interface Web. E na sequência o Jorge falou sobre o FitNesse, voltado para testes de aceite.
O FitNesse tem as seguintes características:
- Ferramenta wiki, que pode ser utilizada por Analista de Teste e de negócios;
- Especificação de requisitos em planilhas;
- É possível utilizar o FitNess usando DSL (Domain specific language), que serve para que seja criada uma linguagem mais próxima do usuário, você cria um conjunto de frases que podem ser utilizados depois;
- Codificação de fixtures pode ser feita por programadores.
Também é possível importar um arquivo do excel para html, que é interpretado pelo FIT (FiTNess = Fit + Wiki).
Depois o tema foi BDD (Behavior-driven development), no qual há um formalismo para escrita de testes de cenários de negócio, geralmente da seguinte maneira:
- Parte explicativa: Sendo um <Papel>, eu quero <funcionalidade>, porque <motivação>;
- Parte executável: Dado que <pré-condições>, quando <ação>, então <verificações>.
Por fim, o Jorge citou as ferramentas que podemos usar com BDD:
Após, o término da palestra começou uma sessão de perguntas, que logo se tornou numa “mesa” de discussão (muito boa por sinal), onde variados temas foram discutidos: CMMI e metodologias ágeis, RUP é ágil ou não, dificuldades de implantar agile, as mudanças que ocorrem na área de Teste de Software e a maneira que ser realiza os testes e vários outros assuntos relacionados a palestra.
Conclusão
A segunda parte da palestra do Jorge Diz, foi muito boa. Ele começou já falando sobre metodologias ágeis, e a palestra fluiu muito bem, sobrando até um bom tempo para as perguntas, que acabaram gerando uma excelente discussão (não é todo dia que você consegue discutir sobre agile e Teste de Software). 🙂
Com a palestra do Jorge Diz, acredito que ficou claro para todos os presentes, que o tsunami da agilidade pode melhorar muito a maneira como realizamos os testes, tornando o processo muito mais efetivo, além disso, as metodologias ágeis já tem na sua essência a preocupação com a qualidade do software, e ela não é uma preocupação/responsabilidade de apenas uma área, e sim de todos comprometidos com o projeto. 😀
Fique por dentro das novidades, assine o feed do QualidadeBR.
QualidadeBR 