Voltei depois de quase duas semanas para fazer meu último comentário sobre a Agile 2008 Conference (antes tarde do que nunca!). Esses dias foram um pouco agitados e acabei não conseguindo escrever antes…
O painel de discussões entitulado From High-performing to Hyper-performing Agile teams com a participacao de Jeff Sutherland, Rob Mee e Jason Titus foi ótimo para mim. Eu não esperava ouvir certas coisas que ouví, mas foi ótimo para pensar e abrir mais ainda a cabeça.
Foram quase duas horas de discussão sobre vários assuntos, até o famoso mito do “Rails não escala” entrou em pauta. Mas o que eu quero falar é de uma boa parte da discussão que foi relacionada à PatientKeeper, empresa na qual o Jeff é CTO e na qual concebeu o Scrum para desenvolver vários sistemas na área da medicina que fazem desde o controle do histórico de pacientes e armazenamento digital de exames até soluções para ajudar a organizar enfermarias, departamentos administrativos e o que mais você imaginar que um hospital tem. A PatientKeeper é inclusive citada no livro do Ken Schwaber e reconhecida como o início da existência do Scrum.
A primeira coisa que me surpreendeu é saber que 80% dos testes desses sistemas não são automatizados. Por incrível que pareça, a justificativa do Jeff é muito razoável: todos os sistemas da PatientKeeper são feitos para funcionar numa variedade enorme de dispositivos, desde Palms até iPhones e computadores convencionais. Basicamente o sistema tem que funcionar onde os médicos se sentirem mais confortáveis para usar. Ele argumentou que é muito difícil automatizar testes de interface em todos esses dispositivos, e por isso eles têm uma equipe de testes responsável por fazer este trabalho.
Antes de tudo, não, eu não acho isso ideal, inclusive eu sou um grande adepto dos testes de aceitação automatizados. Mas no caso deles não é possível automatizar os testes, então, bola para frente oras!
Recentemente no meu time na Globo.com passamos por algo parecido quando acabamos optando por não fazer testes de uma aplicação da forma que achavamos ideal. Como já diz o ditado, o ótimo é inimigo do bom. O que nós precisavamos era de uma solução suficientemente boa e que fosse implementável. A solução ideal demoraria muito para ser implementada e daria um trabalho enorme para ser mantida. Já a solução que demos, apesar de não ser perfeita, já está pronta e começando a render seus frutos.
Resumindo isso tudo, temos que tomar cuidado para não sermos utópicos – algumas vezes temos que ser pragmáticos e fazer o que resolve o problema.
A segunda coisa é que me surpreendeu é que, para cada grande funcionalidade que eles fazem, é feito antes do desenvolvimento todo o design e um protótipo do sistema para aprovação de todos os usuários (os médicos) e só depois de aprovado o protótipo o sistema é desenvolvido.
Mais uma vez, eu não acho ideal. Definidas as necessidades do projeto e sabendo onde se quer chegar com o produto, o melhor é que o time inteiro trabalhe junto, história por história, criando pequenos incrementos de software até que tudo esteja pronto. Inclusive eu cheguei a perguntar se ele não estaria fazendo uma espécie de “Scrum waterfall”, e ele nem pensou para responder categoricamente que não. Em primeiro, esse esquema não é feito para qualquer coisa, mas sim para as grandes funcionalidades e mudanças ou para sistemas novos. E em segundo, ele disse que alguns médicos são extremamente resistentes para usar o software no início, e se eles suspeitarem que há qualquer problema no projeto do software ou que “aquele botãozinho está difícil de enxergar”, eles simplesmente destroem o produto e perdem a vontade de usar. Considerando tudo isso e ainda que as mesmas coisas têm que funcionar numa dezena de dispositivos diferentes, deve ser realmente um desafio e tanto projetar essas interfaces para terem uma boa experiência de uso. Por isso tudo o design das telas é crítico para eles, e para ajudar a lidar com essa questão o processo de trabalho foi adaptado para ter esse “pré-projeto” dos sistemas.
A mensagem que devemos tirar dessas experiências é que não dá para ficar preso a uma metodologia! As metodologias servem para ajudar e não para te impedir de atender aos seus clientes e entregar software da maneira que é mais adequada para eles. Indivíduos e interações são mais importantes que processos ou ferramentas, e é entender isso plenamente que te faz ser verdadeiramente ágil. Os processos ágeis como o Scrum são adaptativos, e é sim recomendável que você siga eles à risca no início mas nada te impede de fazer ajustes ao longo do caminho – desde que você não quebre os pilares básicos como o desenvolvimento iterativo e incremental e as práticas/reuniões/papéis no caso do Scrum.
13 replies on “[Agile 2008 Conference] From High-performing to Hyper-performing Agile teams”
“Mas no caso deles não é possível automatizar os testes [de aceitacao], então, bola para frente oras!”
A justificativa apresentada por eles e que vc expos no texto é legitima para nao haver testes de interface automatizados, mas qual seria o oimpedimento em relacao a automatizar os testes de aceitacao?
Quaqluer sistema de software minimamente funcional pode se beneficiar de testes de aceitacao automatizados. E mais complexidade se traduz em maior necessidade de que tais testes existam e sejam automatizados, nao menor como deu a entender no seu post.
Talvez hajam outras razoes que justifiquem o “80% dos testes desses sistemas não são automatizados”, nao estou duvidando dos numeros apresentados (apesar de achar que vc os super-enfatizou). O meu ponto é que testes de interface sao diferente de testes de aceitacao. Por mais que o cliente seja incapaz de dizer qual a diferenca, pra uma estrategia de desenvolvimento agil isso importa.
Por essas que vejo selenium com restricoes…
Considerando que a validacao de fato de UIs se da pela interacao homem-maquina o mais sensato mesmo nao seria eliminar o usuario do processo.
Testes de aceitação neste caso são testes de interface, achei que tinha ficado suficientemente claro. Eles não conseguem automatizar testes de interface, portanto não conseguem automatizar os testes de aceitação porque esses testes usam a interface!
Os testes de aceitação são diferentes dos testes de interface, porém os testes de aceitação muitas vezes USAM a interface. Se vc não tem como criar algo automatico que usa a interface pode ficar complicado fazer um teste de aceitação automatizado também, e esse é exatamente o ponto em que eles estão.
Por isso que eles têm esse percentual alto de testes manuais – que aliás é exatamente o que o Jeff relata e ele qe dá essa ênfase, não eu 🙂
“Não dá para ficar preso a uma metodologia!” porque “Indivíduos e interações são mais importantes que processos ou ferramentas”. Matou a Pau Guilherme!!! Nunca devemos tirar isso de mente, a final de contas é a essência de todo o resto. Abraço.
“Testes de aceitação neste caso são testes de interface, achei que tinha ficado suficientemente claro. Eles não conseguem automatizar testes de interface, portanto não conseguem automatizar os testes de aceitação porque esses testes usam a interface!”
Sim isso ficou claro, alias esse é justamente o meu ponto de discordancia. 🙂
“Os testes de aceitação são diferentes dos testes de interface, porém os testes de aceitação muitas vezes USAM a interface. Se vc não tem como criar algo automatico que usa a interface pode ficar complicado fazer um teste de aceitação automatizado também, e esse é exatamente o ponto em que eles estão.”
Muitas vezes usam mas nao é recomendado que assim seja neste caso por exemplo. O que significa que testes de aceitacao nao podem ser automatizados ou que devemos procurar outras ferramentas para o trabalho?
Se partimos de um ponto onde concordamos que os dois testes tem naturezas distintas entao nao é dificil compreender o meu ponto de vista; funcionalidades que sao objeto dos testes de aceitacao podem ser testadas em um nivel abaixo da UI. Isso é particularmente importante quando se tem mais de uma maneira de se chegar ate essa funcionalidade.
[]s
Opa, pera lá. Você está equivocado. E não é uma questão de você concordar comigo ou o Jeff Sutherland, é uma questão de você entender corretamente os tipos de teste e os conceitos.
Se você não está incluindo a interface no teste de aceitação, ele não pode ser considerado um teste de aceitação (a não ser que seu sistema seja uma API, que não é o caso).
A definição de teste de aceitação (http://en.wikipedia.org/wiki/Acceptance_testing) não deixa dúvidas:
“[…] acceptance testing is black-box testing performed on a system […]”
Por ser um teste de caixa preta (http://en.wikipedia.org/wiki/Black-box_testing), o teste envolve avaliar se dada uma determinada entrada no sistema ele terá uma determinada saída, sem haver nenhum conhecimento sobre o que há internamente no sistema em termos de infraestrutura, código, métodos ou qualquer coisa de programação.
Se você precisa conhecer, digamos, um Façade para testar uma regra de negócio, como é o que você parece estar propondo, você não está mais fazendo um teste de caixa preta no sistema, você está testando direto a infra do sistema – um teste de caixa branca (http://en.wikipedia.org/wiki/White_box_testing):
“White box testing uses an internal perspective of the system to design test cases based on internal structure. […]”
Neste caso que você citou, o que você está propondo poderia ser considerado um teste de integração (http://en.wikipedia.org/wiki/Integration_testing).
Eu não falei em momento algum que eles não fazem esse tipo de teste, aliás, nem o Jeff falou isso. Porém, é muito provável que façam, já que é um tipo de teste relativamente fácil e, como não testam todas as interfaces, pode ser bem útil.
[ ]s, gc
Testes unitarios sao black-box testing assim como testes de aceitacao (principalmente numa estrategia TDD que contempla refactoring). Nao entendi o que tem haver testes caixa branca com a discussao.
“Se nao testa a UI ou API nao pode ser de aceitacao”
Se vc aplicar abstracao black-box no teste de uma API nao tem porque falar em termos de web services, facades ou bibliotecas de classe. Pro XP e pro agile em geral a palavra aceitacao em “teste de aceitacao” é mais importante que a palavra teste.
Carlos,
Vou encerrar essa discussão por aqui porque já virou teimosia e saiu do tópico do post há muito tempo. Se vc quer discutir sobre testes, sugiro que vc leia mais sobre o assunto para podermos discutir melhor.
Testes unitários até podem ser testes de caixa preta, mas normalmente o que se faz não é isso. Principalmente quando você usa TDD, que usam-se mocks e testa-se intencionalmente se o caminho que vc quer dentro de um método ou parte do sistema é percorrido, o teste é de caixa branca porque você está conhecendo e exercitando intencionalmente várias partes do código interno. Até porque a intenção maior é o melhor design, alta coesão e baixo acoplamento.
E sobre testes de aceitação, quando você desenvolve uma história você está entregando para o cliente alguma coisa que foi feita do início ao fim, ou seja, algo completamente “usável” por ele. Um exemplo de história seria “Para poder transferir dinheiro para outras pessoas, eu como usuário quero poder dizer um número de conta, uma quantia X e clicar num botão para que a transferência seja feita”. Se o seu teste de aceitação testa a API que faz estas operações de transferência mas NÃO inclui a interface, o teste não pode ser considerado de aceitação. A API pode funcionar perfeitamente mas a interface não, e a funcionalidade não está entregue para o usuário. Neste caso, o teste de aceitação deveria ser um teste de caixa preta que, usando a interface, faz as tais operações no sistema. O teste da API não dá cobertura suficiente para garantir que os critérios de aceitação da história foram atendidos.
[ ]s, gc
Vlw a espera. @André Faria Gomes i++;
Guilherme Chapiewski: O homem que chamou o Jeff Sutherland de cascateiro!! Vai ficar para a história…. eh ehe he…
Tirando a piadinha, já trabalhei bastante com software para médicos e de fato a usabilidade é o maior risco. Médico é um usuário muito ruim. Se a usabilidade não ajudar o sistema será um fracasso. É lícito afastar este risco no início. Até porque é natural em processos ágeis focar em valor, mesmo que isso não se traduza em software que vai diretamente para produção.
[…] citar um exemplo, o próprio criador do Scrum – Jeff Sutherland – achou melhor adaptar o processo na sua empresa para fazer o design das telas antes do desenvolvimento. Nessa empresa os sistemas são feitos para serem usados por médicos e eles vêem o sistema como […]
[…] citar um exemplo, o próprio criador do Scrum – Jeff Sutherland – achou melhor adaptar o processo na sua empresa para fazer o design das telas antes do desenvolvimento. Nessa empresa os sistemas são feitos para serem usados por médicos e eles vêem o sistema como […]
Guilherme Chapiewski, enquanto eu concordo com o que falou, acho que foi muito rude ao expor sua opinião. Chegar num post útil como este e já chapar “Opa, pera lá. Você está equivocado”, e sair apontando dedos do início ao fim é bem desconfortável até ao leitor casual, como eu. Que tal dizer “Opa, acho que há um equivoco no uso dos termos”, amigavelmente?
Enfim, sobre o que postou, realmente não dá pra “aceitar” sem ir até o último ponto do sistema envolvido na operação. No entanto, reconheço que usando outros mecanismos pode-se obter o efeito desejado, afinal, não há apenas uma maneira de atingir um objetivo. Talvez no caso deles seja teste de aceitação manual, seguindo um roteiro. Talvez esta técnica funcione até melhor para eles, afinal um ser humano avalia uma interface muito melhor do que uma máquina.
Para nós que não temos dinheiro para sequer considerar a possibilidade de manter o tal roteiro de testes manuais atualizado, ou pagar os testadores, temos que implementar testes automatizados.
Eu estou exatamente tratando milhares de problemas que aconteceram comigo devido a este fato: falta de testes automatizados que realmente são de _aceitação_.
Minha equipe está criando um editor de jogos eletrônicos, e algumas das features deveriam funcionar com mouse. Estas features ficaram sem uso por alguns meses, pois estávamos focando em outras áreas do editor. Todos os testes da citada API passam, no entanto o mouse simplesmente não funciona no editor como esperado, exibindo comportamentos estranhos ao clicar, arrastar, etc. Ou seja: não consigo fazer quase nada nesta área específica do mesmo.
Investiguei um pouco e descobri que houve uma mudança na maneira como o editor implementa o input, mas só atualizaram os comandos que se lembravam. Isto tem acontecido por mais de um mês, chegando ao ponto de hoje eu preferir nem usar o editor para aquela tarefa específica. O time não fez por mal, ninguém se lembrava daquelas feature nem muito menos tinham tempo para voltar a ela (ou tantas outras passadas) durante o desenvolvimento das novas features. O que faremos agora é, aos poucos, re-adicionar as histórias antigas nas iterações atuais, implementando também desta vez os testes de aceitação automatizados.
Espero que outros evitem erros como este, deixando testes de aceitação automatizado de lado. Geralmente ninguém tem tempo para manter testada cada uma das features de GUI do seu projeto, que provalmente contém código de meses de trabalho. De que adianta para o usuário final estar tudo perfeitamente testado se o botão “Submit” não faz nada?? Ou talvez faça, mas a tela de confirmação não aparece? E ao clicar em voltar ele recebe um erro?
Para o cliente, fica a sensação de que esperou tanto pela release só para ganhar bugs novos, e para o desenvolvedor, retrabalho e mais retrabalho para as próximas iterações…
Reescrevi o final de meu post a partir do “Espero que outros(…)” pois estava meio confuso:
—————————————————-
Em qualquer projeto de médio porte se torna inviável manter funcionando 100% da interface sem que haja um mecanismo (automático ou não) para tanto.
Posso pelo menos garantir que seus desenvolvedores não usarão o tempo das novas features para testar manualmente as permutações de uso de sua interface antiga. A GUI VAI quebrar e você vai pagar o pato.
Espero que outros desenvolvedores ágeis percebam que os testes de aceitação automatizados são parte inseparável de suas suites de testes, ou teremos clientes muito insatisfeitos no mundo ágil… De que adianta estar tudo “perfeitamente testado” se o botão “Submit” não faz nada?? Ou talvez faça, mas a tela de confirmação não aparece? E ao clicar em voltar ele recebe um erro?
Nós desenvolvedores infelizmente temos a tendência de focar nas coisas mais complexas, e acabamos deixando de lado o trivial botão, caixa de texto, etc. Justo aquilo que o usuário mais precisa para usar seu software…
Para o cliente, fica a frustração por ver coisas que antes funcionavam não funcionando mais, e para o desenvolvedor, retrabalho e mais retrabalho para as próximas iterações…