Impressões do 6º Encontro Mensal da ALATS São Paulo – parte 2

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.

TestingPyramid

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.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s