Durante muito tempo, testar utilizando metodologias ágeis era um grande mistério. Até hoje é impossível alguém dizer que aplicou uma metodologia de testes em projetos ágeis e funcionou perfeitamente. O que existe hoje são boas práticas ou alguns cases (não necessariamente de sucesso) utilizando essas metodologias chamadas "ágeis".
Escrevo isso por causa de um comentário feito sobre Bernard Homès numa palestra dele: "Would you fly in an airplane which software was developed and tested by Agile methodologies? Traduzindo: você voaria num avião cujo software foi desenvolvido e testado utilizando metodologias ágeis?" É claro que não. E a partir disso fiz uma reflexão...
Uma coisa deve ficar clara: metodologias ágeis são "bem vindas" quando a qualidade não é o requisito principal daquela aplicação. Como uma empresa é capaz de dizer que seus softwares são de ponta e têm qualidade se estes são desenvolvidos utilizando metodologias ágeis? Isso é hipocrisia, qualquer um que conhece desenvolvimento de software sabe que isso é uma grande piada. Como que vão garantir a qualidade no desenvolvimento do software se a alteração do requisito é feita ao telefone pelo Product Owner e gritado para a equipe pelo Scrum Master? Controle de mudanças? Em software pequeno é fácil ter esse controle. Só que nenhuma empresa quer que seu software seja pequeno e nunca tenha alterações por parte dos clientes? Bom, na verdade a resposta é sim, e obviamente isso seria o ideal, mas isso não existe, OK? Clientes pedem alteração o tempo todo, e é dinheiro jogado fora ficar alterando software on-the-fly. "Ah para, isso é ser ágil! Não tem burocracia, é só chega e dá-lhe".
Esse pensamento do "chega e dá-lhe" veio à tona porque ninguém sabe desenvolver software, a gente tem mania de dizer que documentação só serve para virar rascunho, e que ninguém usa para nada. Com certeza, ninguém usa porque ninguém controla. Chega uma hora que não faz mais sentido cuidar da matriz de rastreabilidade, é muito grande, desnecessária e ninguém usa para nada, não é? Daí quando o projeto está perdido, vão dizer: ué, não tem uma matriz de rastreabilidade? Deveriam ter feito... Foi incentivado no início? Não! Agora os Testes de Regressão causam uma GRANDE dor de cabeça.
Esses dias eu vi uma propaganda "nossa empresa tem uma metodologia própria, o Outsourcing Dinâmico". Que, nada mais nada menos, é praticar o outsourcing utilizando metodologias ágeis. Ou seja, sugar dinheiro do seu cliente da forma mais "inocente" possível. O cliente acha que o projeto está sendo ágil mas na verdade está sendo uma grande farsa, pois o tempo que gasta fazendo uma alteração de cada coisa que não está de acordo, é tempo perdido.
Bom, antes de qualquer coisa, gostaria de declarar que eu não sou um defensor das metodologias tradicionais. Como eu costumo defender as citações de Glenford J. Myers: "testing is context dependent", eu já diria nesse caso que: "methodologies are context dependent". Ou seja, metodologias ágeis podem ser ótimas, mas para contextos específicos. Não caiam na ilusão de que é aplicável para qualquer tipo de projeto.
Assinar:
Postar comentários (Atom)
12 comentários:
Luiz,
Se apenas o último parágrafo é a sua opinião, então tudo bem. Faz todo sentido.
Agora se o post todo contém a sua opinião, e você realmente não voaria num avião desenvolvido usando metodologias ágeis, acho que você precisa entender melhor o que é, e o que não é ágil. Antes de ficar falando essas heresias (espero ter entendido errado).
E você deve saber, que o problema está muito mais na forma que as pessoas implementam as metodologias, do que na metodologia em si.
Abraços!
Primeiro: Quem falou essa "heresia" não fui eu, foi Bernard Homès, presidente do ISTQB na França (e deu risada ainda).
Segundo: Eu assino embaixo do que ele disse.
Concordo que o grande problema das metodologias ágeis está na forma como as pessoas implementam a tecnologia. Isso serve para portais web, e-commerces e principalmente, projetos com caráter de inovação.
A técnica "Pairwise testing" veio, por essência, da Engenharia Elétrica, onde os engenheiros eram obrigados a cobrir o máximo de combinações numa infinita gama de válvulas, para ter uma configuração ideal de um circuito específico. Por mais genial que seja, um profissional nunca vai conseguir prever todos os cenários existentes numa combinação de X, Y, Z valores, etc. não em tempo hábil, através de Testes Exploratórios (esta que é a técnica largamente utilizada e sugerida em projetos ágeis).
Tem um tema que é abordado nas certificações nível Advanced do ISTQB que se chama Critical Systems e Systems of Systems. Que é, nada mais nada menos, que o estudo feito em cima de sistemas críticos (não crítico de prazos, mas crítico de envolver vidas) ou muito complexos. Imagina ter uma configuração com infinitos circuitos integrado com infinitos sistemas de controle. Não quero nem imaginar a reunião de sprint planning para definir um projeto desses...
Então Luiz,
A primeira coisa que estranhei no comentário do Bernard, foi que ele logo mostrou um preconceito: "se algum sistema crítico foi desenvolvido usando metodologias ágeis, eu não usaria esse sistema ou onde ele foi implantado.
E isso não faz sentido, não é a metodologia que foi usada no projeto, que irá dá a confiança na qualidade do sistema.
Talvez, pelas experiências dele, ele tenha ganho esse preconceito e a impressão que desenvolver de forma ágil, é igual desenvolver com baixa qualidade.
Mas agora generalizar isso não faz sentido. E pela experiência dele, que pelo visto é MUITO mais ampla que a minha, ele deveria saber que há tantos outros fatores mais importantes que a metodologia que foi usada, para serem avaliados e que impactam mais na qualidade final do sistema.
Agora pela posição dele, presidente ISTQB na França, não é de se estranhar essa opinião dele, uma vez que o ISTQB é a favor de uma postura mais convencional, seguindo a escola convencional de Teste de Software.
Abraços!
Eu estava lá com o Luiz Gustavo, no CInTeQ 2011, quando o Bernard Homès fez este comentário um tanto quando 'bombástico'... olhei perplexa e segui o reciocíonio dele. Concordo que, em partes muito se fala sobre metodologia ágil como ausência de documentação forma. Mas com certeza não ausência de informação para testes.
Trabalhei em uma empresa que utilizava como metodologia a AUP: Agile Unified Process, que é uma versão simplificada do RUP para uma forma de desenvolvimento mais ágil.
E o processo era constituído de um backlog que incluíam as tarefas de teste inclusive. Cada funcionalidade da Sprint a ser entregue era coberto por testes manuais detalhadamente especificados e com cobertura de 98% dos fluxos especificados. Todos os métodos entregues naquela Sprint também eram cobertos por testes automatizados. A cobertura era avaliada por uma ferramenta de análise estática do código que nos mostrava os fluxos dos métodos que não haviam sido cobertos com testes.
Além disso também existiam os testes automatizados de integração e de sistema que faziam parte de outro Backlog, senão o da entrega dos componentes.
Então na minha opinião o que importa na realidade não é se a metodologia é Ágil ou não. O que importa é se são planejadas na Sprint e aplicadas técnicas de teste compatíveis com o nível de criticidade do sistema.
O Luiz Gustavo comentou sobre Pairwise Testing, porque esta técnica não poderia ser planejada no Backlog e aplicada da Sprint?
Talvez neste caso, não se tornaria necessário outro Backlog?
- Um backlog de testes e controle da qualidade das entregas
- Outro backlog para aplicação das técnicas necessárias para garantir a qualidade da entrega do 'produto'.
Será que isto tornaria o processo menos ágil?
Essa é uma questão que eu gostaria que fosse respondida pelo pessoal que defende as metodologias ágeis... Ter uma visão de como eles organizariam as atividades de teste nessa situação.
Bárbara,
Sendo o "Pairwise testing" uma técnica, ela poderia muito bem ser levada em consideração durante a segunda parte da reunião do planejamento da sprint.
Quanto ao backlog... ele é único, pois ele é do produto. Por isso, acho que não é necessário a criação de um outro backlog.
Abraços!
Prezados, só para constar: já participaram de algum projeto com mais de 10-15 testadores? Sem contar desenvolvedores, analistas, etc.
10 ou mais Testadores não, já trabalhei numa equipe de Teste com mais de 10 pessoas, mas não havia apenas Testadores.
Você já? Se sim, que tipo de sistema vocês estavam testando? Não era possível modularizar o desenvolvimento e assim, subdividir as equipes?
Abraços!
É o que era feito, éramos uma equipe de mais de 40 testadores (apenas testadores) e o sistema era modularizado.
Era impraticável utilizar uma metodologia que fosse diferente da formal.
Aliás, as primeiras duas releases do projeto eram feitas de forma (quase) ágil, na terceira release o projeto já estava absurdamente grande e teve que adotar um trabalho mais formalizado, através da metodologia tradicional.
Utilizava-se SME (Subject Matter Experts) e Test Analysts, estes interagiam de forma que ia manter a qualidade básica do produto e iria permitir a evolução contínua do mesmo. Aliás, foi uma forma bem interessante de proceder com o projeto, funcionou. Fiquei pouco mais de um ano no projeto e tinha muita água para rolar. Só que a situação do projeto era completamente diferente de como eu entrei.
Interessante Luiz.
Só pra constar: eu não acho que você deva utilizar sempre uma metodologia ágil. Você deve usar o que se encaixa melhor para o seu contexto.
Quanto a essa sua experiência, seria legal você fazer alguns posts a respeito, hein. Fiquei curioso em saber mais detalhes. (hehe)
Abraços!
Caros - Este é um tópico discutido em muitos forums na internet.
Agile vs Waterfall
Podiamos até ir mais fundo e adicionar Agile Plus na briga, uma "evoluação" do Agile utilizada em grandes empresas que pode gerar ainda mais discussão.
Para não estender muito meu comentário, gostaria de salientar que todos os comentários deixados são válidos, já liderei projetos grandes e pequenos utilizando as 3 metodologias citadas acima e posso dizer que cada uma tem seus pontos negativos e positivos. Em alguns casos mais negativos do que positivos.
Confesso que Agile ainda não me conquistou quando colocamos a qualidade como fator primordial de um projeto.
Para finalizar, sou da opinião de que a metodologia/estratégia de teste deve ser definida de acordo com o tamanho/complexidade/recursos do projeto.
Abraços.
Levando em conta onde já trabalhei e onde trabalho agora eu noto que os desenvolvedores caminham em direção a agilidade quase que de forma inconsciente, principalmente quando as metas e prazos são definidos sem a possibilidade de argumentação. Levando isto em conta eu sou a favor de aproveitar esta ação inconsciente para adotar a metodologia ágil por completo a fim de melhor controlar a situação, seguido de práticas que refinem o funcionamento das equipes e dos projetos. Digo isto por que no meu caso a empresa já tem o produto desenvolvido de forma "errada" (nível baixo de controle e qualidade) e o agile parece ser a única forma de melhorar a situação tanto da equipe de desenvolvimento quanto a de teste em relação aos produtos que temos.
Só para constar: Nao vejo problema em usar metodologias ageis, porem como ja foi falado, dependendo do contexto do projeto, é MUITO dificil acreditar que seja praticavel. Venho da área de telecomunicações e desenvolvimento de produtos. Há seis anos trablaho com testes em software embarcado de telefones celulares. São cerca de 5 produtos diferentes testados simultaneamente todo mes, em fases diferentes, features diferentes, publico alvo diferente, estrategia comercial diferente, em tres plataformas diferentes. Só na america latina são mais de 50 operadoras, cada qual com suas exigencias, customizacoes e parametros fora de SPEC que precisam ser cuidadosamente levadas em consideracao. Alem disso sao cerca de 80 testadores(diferentes, devido a alta rotatividade), em dois test centers diferentes, sem contar os que fazem teste em campo. Apesar de parecer simples, atualmente os smartphones tem uma capacidade multitarefa impressionante, o que possibilita interações entre suas inumeras aplicações. O universo de posibilidades é infinito, e extremamente dinamico (para nao dizer caótico). Apesar de todo desenvolvimento ser agil (e nao teria como não ser), se fossem usados metodos ageis para testar tudo isso, sinceramente eu tambem nao pegaria esse avião kkkkkk. abraço.
Postar um comentário