Você precisa de Agile?

Parece que de repente, “todo mundo” começou a buscar ser ágil.

A primeira vista isso pode até ser visto como bom, uma vez que vários métodos ágeis são bem mais sensatos do que os métodos tradicionais. Porém, infelizmente, muitos estão apenas indo na “onda do Agile”, e esses correm um alto risco de morrer na praia.

Por experiência própria, posso dizer que Agile não é pra qualquer empresa/equipe.

E dentre as várias coisas que aprendi (a duras penas), foi que nem sempre precisamos de Agile, ou melhor, nem sempre o que mais precisamos é Agile.

Para ilustrar esse aprendizado, vou utilizar o exemplo da famosa XPTO Solutions.

A XPTO Solutions também conheceu o Agile, por meio de materiais de terceiro é claro (uma dica: busque primeiro o conhecimento da fonte original). E após ver que os seus concorrentes já estavam utilizando métodos ágeis, decidiu adotar também. E como a maioria, começou com Scrum.

No começo tudo parecia uma maravilha, vários post-its coloridos na parede, o gráfico burn-down correndo bem, etc. Porém, após algumas sprints, percebeu-se que tinham finalizados várias funcionalidades, porém nada tinha ido para a produção, e nem o cliente tinha visto o software que estava sendo desenvolvido, pois estava distante, e o máximo de participação que ele tinha na sprint, era feita por e-mail ou telefone com o Scrum Master.

Outro problema que apareceu, foi que muitas tarefas eram retrabalhos e resoluções de bugs, pois eles não faziam testes unitários e 70% dos desenvolvedores ainda eram juniores, e não conheciam práticas como TDD e ainda não tinham uma base sólida na linguagem de programação que é usada na XPTO.

O problemas que aconteceram na XPTO não são incomuns. E se formos analisar muitos desses problemas não têm nenhuma relação com o Agile, e iriam acontecer independente da metodologia utilizada.

Problemas como equipe inexperiente, cliente distante, gestão de conhecimento ineficiente, falta de motivação, acomodação, etc são comuns em qualquer empresa. E a solução ou medidas que poderiam amenizar os seus efeitos não estão numa metodologia de desenvolvimento de software.

Por isso que eu enfatizo, que antes de implementar Agile, precisamos analisar o ambiente a nossa volta, assim como um agricultor verifica o terreno para saber o que pode plantar nele. Não adianta forçar ser Agile, o seu desenvolvedor não irá testar só porque agora é Agile, o seu cliente não irá participar mais e/ou aceitar o contrato de escopo negociável, só porque agora a sua empresa é Agile.

E é bom lembrar, que Agile não é um fim, e sim um meio para você construir software com mais eficiência e qualidade, ter uma equipe mais motivada e um cliente mais satisfeito.

É importante ter em mente, que Agile não é apenas uma questão de mudança de hábito, mas também cultural . Vários paradigmas precisam ser quebrados quando implementamos Agile, e alguns deles já foram quebrados por pessoas como o Ricardo Semler, muito antes do Manifesto Ágil surgir, como por exemplo: uma participação mais democrática da equipe no dia-a-dia e nas decisões da empresa e valorizar mais pessoas do que processo.

Podemos fazer uma implementação de Agile de forma mais harmoniosa e sensata, ao buscar saber o que realmente precisamos antes do Agile em sí, uma vez que muitos dos problemas que enfrentamos, não estão relacionados com a metodologia que está sendo usada. Lembre-se, que “para que a semente dê frutos, é necessário preparar a terra.”

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte imagens:

http://bit.ly/aevP0r

http://bit.ly/c2t8zd

http://bit.ly/a8Y15t

BDD – Behavior Driven Development

Durante a Mesa Redonda do DFTestes sobre “Implementar BDD ou ATDD é possível na realidade?“, percebi que BDD e ATDD são duas siglas pouco conhecidas pela comunidade de Teste de Software brasileira. Portanto, acabei decidindo fazer dois posts para explicar o básico de cada técnica. 🙂

Neste primeiro irei falar sobre BDD, cuja tradução é: Desenvolvimento Direcionado por Comportamento.

Como disse no começo, ambos são técnicas e técnicas para a equipe de desenvolvimento de software, não de teste. Acredito que esse seja o motivo principal, do desconhecimento por parte do pessoal da área de Teste de Software dessas duas técnicas. Porém, é altamente recomendável o pessoal de teste também ter conhecimento sobre elas, uma vez que eles podem ajudar os desenvolvedores na implementação de tais técnicas,.

Mas antes de detalhar e dá algumas opiniões sobre BDD, vou contar um pouco de história.

Surgimento do BDD

Num certo dia, um tal de Dan North estava refletindo sobre as dificuldades dos programadores ao usar TDD:

Saber por onde começar;
O que testar e o que não testar;
Até onde testar;
Como chamar os testes;
E entender porque um teste falha.

E essas dúvidas e mal entendimentos eram observados com uma certa frequência pelo nosso amigo Dan North.

Foi aí que o Dan North viu a necessidade de criar algo para apresentar TDD de uma maneira direta ao lado iluminado da força. Evitando todas as armadilhas que podem levar o jovem aprendiz a ser tentado pelo lado negro da força.

Dan North então respondeu essa necessidade com a criação do BDD, que possui três princípios básicos:

Tudo é comportamento: A área de negócios e a de Tecnologia devem se referir para o sistema da mesma forma;
Onde está o valor do negócio: Todo sistema deve ter comportamentos que sejam um verificador do valor para o negócio;
Faça o suficiente: Analisar, projetar e planejar tudo de cima para baixo, evitando o detalhamento prematuro.

O BDD evoluiu a partir de práticas ágeis e foi desenvolvida para tornar elas mais acessíveis e eficazes para os times que estão iniciando a entregar software de forma ágil. Com o tempo, o BDD cresceu para abranger também a análise ágil e a automação dos testes de aceitação.

Mas afinal o que é BDD?

Em poucas palavras, o BDD é uma técnica de desenvolvimento de software, onde os programadores desenvolvem o software direcionados por comportamentos. Tais comportamentos são a nível de negócio e ajudam o programador a entender melhor a funcionalidade que será desenvolvida.

Além disso, várias ferramentas (ex.: JBehave e Cucumber) permitem ao programador transformar esses comportamentos em verificações automatizadas.

Melhorando a comunicação

A técnica de BDD confia no uso de um vocabulário bem específico e pequeno, com o objetivo de minimizar a falta de comunicação e garantir que TODOS (stakeholders, desenvolvedores, testadores, analistas e gerentes), não estão apenas na mesma página, mas também estão usando as mesmas palavras. BDD pode ser considerada uma Ubiquitous Language (“Linguagem Onipresente”).

Essa é a grande sacada do BDD, pois permite que todos os envolvidos no projeto possam utilizar da mesma fonte, os comportamentos, para a partir deles realizar o seu trabalho.

Comportamento?

Um comportamento é descrito através de uma história, cujo modelo é:

Como um [X]
Eu quero [Y]
Então [Z]

Onde:

X- é a pessoa que será beneficiada;
Y- é alguma funcionalidade
Z- é o benefício ou valor da funcionalidade;

Esse é um modelo que foi criado pelo Dan e pelo Chris Stevenson. E foi evoluído por eles para algo mais flexível para não ser artificial ou restrito aos analistas e estruturado o bastante para que as histórias possam ser quebradas e possam ser automatizadas. E aí a seguinte forma foi definida para definir um cenário, que está associado a uma história:

Dado algum contexto inicial (entradas),
Quando um evento ocorre,
Então verifique alguns resultados.

hmmm… isso me parece com algo

Sim, se parece com um caso de teste não é?

Entradas, ações e resultado esperado. Essa é a estrutura básica de um caso de teste, e é também a do cenário, proposta pelo BDD. A diferença está nas palavras e forma descrita, afinal é bom lembrar que um caso de teste nem sempre é algo tão entendível para os clientes.

BDD na prática

Eu já utilizei um pouco o BDD usando o Cucumber. E para fechar o post deixo um exemplo de implementação do BDD com o Cucumber, mais a título de exemplo mesmo (não irei explicar como instalar, implementar as steps definitions, executar, etc quem sabe num próximo post). Acredito que com ele fique mais fácil para encaixar as ideias e conceitos apresentados anteriormente.

No Cucumber temos a seguinte nomenclatura básica:

Funcionalidade: igual ao modelo de história elaborado pelo Dan e Steve;
Cenário: igual ao cenário explicado anteriormente.

Um exemplo de fluxo de BDD seria: cliente defini a funcionalidade e cenários associados a ela > desenvolvedor entender a funcionalidade e cenários e implementar as steps definitions > desenvolvedor roda um comportamento, irá falhar > desenvolvedor implementar o código para o comportamento > desenvolvedor executa o comportamento, que deverá funcionar.

Lembrando que esse é apenas um exemplo de fluxo de BDD, a forma de implementação e pessoas envolvidas pode variar de empresa para empresa, mas o fluxo básico acaba sendo esse mesmo (elaborar e rodar o comportamento, que irá falhar > desenvolver o código para o comportamento > executar o comportamento, que deverá passar), ou seja, igual ao do TDD.

Abaixo um exemplo, mostrando uma funcionalidade e cenários associados a essa funcionalidade:


#language: pt

Funcionalidade: Gerenciar produtos
    Para gerenciar produtos
    Como um usuário
    Eu quero criar, editar, apagar e visualizar produtos

    Cenário: Visualizar os produtos
        Dado eu tenho os produtos iPad, iPhone
        Quando eu vou para lista de produtos
        Então eu devo ver "iPad"
        E eu devo ver "iPhone"
    Cenário: Criar um produto
        Dado eu não tenho produtos cadastrados
        E que eu esteja na lista de produtos
        Quando eu clico "New"
        E eu preencho "Name" com "iPad"
        E eu preencho "Price" com "499"
        E eu aperto "Create"
        Então eu devo ver "Product was successfully created."
        E eu devo ver "iPad"
    Cenário: Editar um produto
        Dado eu tenho o produto iPad
        E que eu esteja na lista de produtos
        Quando eu clico "Edit"
        E eu preencho "Name" com "iPhone"
        E eu preencho "Price" com "199"
        E eu aperto "Update"
        Então eu devo ver "Product was successfully updated"
        E eu devo ver "iPhone"
    Cenário: Apagar um produto
        Dado eu tenho os produtos iPad, iPhone
        E que eu esteja na lista de produtos
        Quando eu clico "Destroy"
        Então eu não devo ver "iPad"
        E eu devo ver "iPhone"

Saiba mais:

Alguns bons artigos em português:

Tradução do Danilo Sato do artigo original do Dan North.

Introduzindo Desenvolvimento Orientado por Comportamento (BDD)

Artigo do Ronaldo Melo Ferraz, onde ele faz algumas considerações sobre TDD e BDD.

Algumas considerações sobre TDD e BDD

Artigo do Urubatan, mostrando algumas diferenças entre TDD e BDD e também o Cucumber.

Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://behaviour-driven.org/

http://blog.dannorth.net/introducing-bdd/

O modelo deveria ser flexível o suficiente para não parecer artificial ou restritivo para os analistas, porém estruturado o suficiente para que pudéssemos quebrar as histórias em pedaços que pudessem ser automatizados. Nós começamos a descrever os critérios de aceitação com base nos cenários, da seguinte fo

Cobertura CInTeQ 2010 – Dia 1 (parte 1)

Nesta segunda-feira teve início o CInTeQ (Congresso Internacional em Testes e Qualidade de Software), um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB.

A seguir, relato como foram as primeiras palestras do primeiro dia do evento.

Abertura do evento – Osmar Higashi – Atuação do BSTQB e Panorama Atual dos Testes no Brasil

O paguá que vos escreve chegou atrasado… chegando só no fim da palestra de abertura do evento, que foi ministrada pelo diretor executivo da RSI Informática e BSTQB (Brazilian Software Testing Qualifications Board), Osmar Higashi.

O palestrante falou sobre a atuação do BSTQB no Brasil, as certificações avançadas, números de certificados e uma notícia bem importante: a aplicação da prova avançada para a área de gerência de testes (CTAL-TM: Advanced Level Test Manager) aqui no Brasil, que ocorrerá ainda nesse ano (atualização[24/03]: o César Chaves disse nos comentários que já houve a primeira prova CTAL-TM: Advanced Level Test Manager no Brasil, ela ocorreu em fevereiro/2010).

Além disso, o palestrante disse que os Syllabus das outras certificações avançadas já estão sendo traduzidos (alguns já estão até completamente traduzidos) e que o BSTQB está trabalhando para aplicar os outros exames avançados no Brasil.

Resumindo, parece que o BSTQB está querendo atuar mais fortemente no Brasil, prova disso é a própria realização do CInTeQ, o que é muito bom para o nosso mercado e para os profissionais.

Eduardo Habib – Teste de Segurança em Aplicações Web

O Eduardo é Gerente de Testes no SYNERGIA e mestre em Ciência da Computação pela UFMG. Sua apresentação foi sobre uma tema ainda não muito comentado na comunidade de Teste de Software Brasileira, testes de segurança.

A palestra do Eduardo teve como foco apresentar as falhas de segurança mais comuns em aplicações Web, alguns exemplos de como testá-las e ferramentas open source que auxiliam nesse tipo de teste.

O palestrante começou falando que antigamente a segurança não era uma preocupação no desenvolvimento de aplicações Web, pois o conteúdo era todo estático e não haviam informações confidenciais nos sites.

Porém, hoje em dia os sites possuem informações confidenciais de seus usuários, desde login e senha até o saldo da conta corrente. Portanto, a segurança passou a ser uma característica fundamental em vários sites, e são precisos testes para averiguar se a aplicação é realmente segura.

Algumas informações importantes passadas pelo Eduardo durante a palestra:

Muitas pessoas não se importam com a segurança de determinada aplicação, porém esquecem que essa aplicação pode ser a porta de entrada para as aplicações que ele se preocupa;
O uso de SSL – Secure Sockets Layer não impossibilita ataques, e os ataques que mais ocorrem não são evitados com SSL. Porém, isso não que dizer que você não deva utilizar SSL, pois caso você faça isso, você abrirá outras “brechas” para os crackers;
Há um aumento considerável no número de incidentes relacionados a segurança (figura abaixo), e esses números não estão dando sinais que vão diminuir. Por isso cada vez mais se faz necessário realizar testes de segurança;
Houve um aumento de incidentes de 61% de 2008 para 2009;
De 1999 até 2009 o aumento de incidentes foi de 11530%;
75% dos sites de bancos possuem falha grave, segundo a Universidade de Michigan (pesquisa não contemplava bancos brasileiros);
64% de 1364 sites corporativos possuem falhas graves de segurança, segundo o WhiteHat Security.

Total de Incidentes Reportados ao CERT.br por Ano (Fonte CERT.br)

A origens principais desses incidentes são devido aos seguintes problemas:

O usuário pode enviar QUALQUER dado;
É necessário assumir que toda entrada pode ser maliciosa;
Requisições podem ser feitas em qualquer sequência;
Usuários não irão usar apenas um navegador para acessar a aplicação;
Muitas aplicações não fazem verificação a cada requisição, ou seja, após o usuário estar logado, as requisições não são mais autenticadas.

O Eduardo ainda falou sobre as falhas que mais ocorrem, sendo elas:

Falhas de injeção (ex. SQL injection);
Cross Site Scripting (XSS);
Falhas de autenticação e de gerenciamento de sessão;
Referência insegura a objetos;
Problemas de configuração;
Falha ao restringir o acesso a alguma URL;
Redirecionamento inválido;
Problemas no armazenamento de informações confidenciais;
Proteção na camada de transporte insuficiente;
- Sem criptografia;
- Certificados inválidos.

Mas então como podemos testar a segurança de uma aplicação Web?

Segundo o Eduardo a primeira coisa a ser feita quando for testar um software é pensar como que um cracker irá obter a informação, e para isso é preciso fazer um bom mapeamento, cuja melhor forma é a automática. Existem ferramentas open source que fazem esse mapeamento, e essas são chamadas de web spider.

Um ponto bem interessante da palestra foi a apresentação da ferramenta WebGoat, que já possui várias falhas de segurança e foi criada, justamente para ensinar as pessoas a como encontrar essas falhas e como funcionam as técnicas utilizadas pelos crackers, ou seja, é uma ferramenta obrigatória para quem quer começar a fazer testes de segurança.

O palestrante também mostrou uma lista de addons do Firefox e ferramentas que podem auxiliar durante os testes de segurança:

Por fim, o Eduardo concluiu que:

Todo sistema/aplicação é passível de invasão;
Os usuários são potenciais invasores;
É necessário otimização e cautela durante a programação,
A análise de riscos pode ajudar no início da elaboração dos testes de segurança, fazendo você focar nas áreas chaves;
Novas tecnologia irão criar novas “brechas”;
Não há ferramentas open source tão boas, quanto as pagas.

Impressões da palestra

Eu achei a palestra do Eduardo bem interessante, talvez por não conhecer muito bem a área de Segurança de Informação e por nunca ainda ter feito testes de segurança.

O Eduardo atingiu com sucesso a proposta da palestra. Sem dúvidas quem participou da palestra saiu dela com uma visão muito melhor e já sabe por onde começar a fazes os testes de segurança, que cada vez são mais necessários e que cujas falhas costumam gerar um prejuízo muito grande para as organizações.

Rex Black – Dealing with the Testing Challenges of Agile Methodologies

A expectativa para essa palestra era muito alta, afinal o palestrante era nada mais nada menos, do que a lenda, o mito, o “monstro”, o “dinossauro”, o “megaboga”, o gigante … Rex Black, presidente da RBCS e autor de excelentes artigos e livros, que fazem juz aos adjetivos colocados, e o tema da sua apresentação “Lidando com os Desafios do Teste para as Metodologias Ágeis”, o mais interessante da agenda dos dois dias de evento, pelo menos para mim, que estou lidando com esses desafios ultimamente.

Bem, agora vamos ao que interessa, a palestra.

O Rex Black (RB) iniciou a sua apresentação dizendo que os desafios que serão comentados são inerentes a forma ágil de desenvolvimento de software, e basicamente esses desafios possuem duas origens:

Do próprio agile;
Interpretações das pessoas.

Após esse breve e importante esclarecimento, o RB perguntou para a platéia quem utiliza metodologias ágeis, e um bom número de profissionais levantaram a mão. E isso mostra como é verdadeira a afirmação feita na sequência, de que ciclos de vida ágeis estão se tornando comum.

Alguns pontos importantes levantados pelo Rex foi:

Todas metodologias afetam o teste de software (isso parece até óbvio, mas muitas pessoas não percebem isso ou percebem da pior maneira);
No contexto ágil é necessário saber quais estratégias de teste funcionam bem. O RB citou três que funcionam bem:
- Teste baseado em riscos (na minha opinião, teste baseado em riscos sempre funciona bem! [quando bem aplicado é claro]);
- Automação de teste, incluindo teste de regressão funcional;
- Teste reativo, cujos principais representantes são os famosos testes exploratórios.

E mesmo utilizando essas estratégias, elas não irão aliviar todos os desafios de teste com projetos ágeis. Por isso é muito importante entender os desafios, identificar os caminhos e saber como lidar com eles.

Volume e velocidade da mudança

No mundo ágil mudanças ocorrem toda hora, e elas não são encaradas como problemas e sim como oportunidades, por isso deve-se dar as boas-vindas a elas.

Bonito isso! Mas como nós, profissionais de teste, podemos lidar com essas mudanças, uma vez que geralmente, elas costumam gerar grande retrabalho para nós:

Utilizando testes baseado em riscos, pois eles podem acomodar as mudanças;
Testes automatizados também ajudam a acomodar as mudanças: testes unitários e até de GUI (mesmo o último sendo mais “quebrável”);
O testadores devem ser manter atualizados para evitar ter falsos positivos.

Nos projetos agéis o tempo é muito curto

Em projetos agéis você não terá muito tempo para manter os testes, o tempo é muito limitado. Então ao automatizar você precisa saber que testes no banco de dados, são mais estáveis que testes na GUI. Além disso, o teste baseado em risco vai mais uma vez te ajudar, pois irá fazer você ser mais focado no que é mais importante. Lembre-se, no mundo ágil é preciso ter foco!

Testes unitários inadequados e inconsistentes

Uma das coisas em agile que o Rex Black mais gosta são os testes unitários, mas como o Fred Brooks disse “não existe a bala de prata” (isso em 1987, eu nem era nascido rs).

Mas antes de comentar sobre testes unitários o RB fez uma interessante analogia para explicar dois tipos de complexidades:

Complexidade acidental: tentar colocar o sapato do pé direito no pé esquerdo;
Complexidade essencial: você está no avião retira os seus sapatos para ficar mais à vontade, depois quando o voo já está chegando no seu destino, você vai colocar os sapatos, mas tem dificuldade, pois os pés estão inchados.

Ou seja, há uma complexidade causada por nós mesmos e outra causada por uma série de fatores do nosso contexto.

E assim sendo, os testes unitários precisam ser consistentes com a nossa aplicação, que por sua vez precisa ser adequada para que seja possível realizar testes unitários (ex.: problemas de testabilidade).

Mas testes unitários possuem dois problemas:

Eles têm um limite de “alcance” de bugs, de 25% a 30%, enquanto bons testes de sistemas tem média de 85%;
Nem todos os programadores fazem testes unitários.

O Rex Black frisou que os testes de unidade precisam acontecer, mas você precisa de ciência das suas limitações, pois não vamos fingir que agora tendo testes unitários não será preciso fazer mais outros testes.

Alguns outros pontos interessantes levantados pelo RB:

“Em agile não é preciso escrever nenhuma documentação”, essa é uma interpretação errada do manifesto;
Relatórios inválidos de bugs (com falso positivos) são um desperdiço de tempo, por isso é necessário os testadores estarem em constante interação com os desenvolvedores;
Todas equipes precisam encontrar o equilíbrio entre documentação e reuniões;
É preciso tomar cuidado para não espremer os testes, por exemplo: o projeto tem sprint de quatro semanas, e sempre há novos commits, os testes acabam sendo espremidos na última semana de todo sprint, ou seja, acabamos fazendo “cascatinhas”;
Os clientes da RBCS adotam agile utilizando equipes independentes de teste;
Não é necessário equipes totalmente independentes do time e nem totalmente dentro dos sprints, e sim um meio termo;
Sprint para o teste e outro para desenvolvimento não funciona;
Em agile tudo que você faz é um conjunto de coisas que você não faz (profunda essa frase rsrs);

O que aconteceu com a nossa base!?

Uma das respostas clássicas quando se pergunta qual é o objetivo do Teste de Software, é dizer que é garantir que a aplicação tenha sido implementada de acordo com os requisitos. E assim, os requisitos acabam sendo a principal fonte de informação e torna-se a base para os nossos testes.

Mas segundo o Rex Black, isso é um problema no contexto ágil, pois os requisitos podem mudar e então, os testes baseados em requisitos podem ser não efetivos, afinal estaremos atirando em alvos que estão sempre em movimento.

Ou seja, basear os seus testes em requisitos é muito difícil, quase impossível a longo prazo, caso você siga só essa estratégia.

O Rex Black ainda falou sobre as vantagens e desvantagens do testador atuar dentro da sprint:

Vantagens:
- Foca nas tarefas relacionadas com aquela sprint;
- Aloca e realoca o tempo baseado nos objetivos da sprint.
Desvantagens:
- Perde a liberdade, ele passa a ser “liderado” pelo Scrum Master e não pelo Gerente Teste;
- Tem uma visão reduzida do sistema.

Foi comentado durante a apresentação que há expectativas muito altas para o agile, principalmente por parte da gerência, e isso é um grande risco na implantação de agile, pois agile vai trazer benefícios no longo prazo e haverão muitos desafios.

Na conclusão da sua palestra o Rex Black fez as seguintes considerações:

É preciso ser muito cuidadoso na escolha das estratégias de testes;
É necessário manter os testes automatizados e realizar os teste de regressão baseados em riscos;
Testes reativos permitem os testadores explorar áreas que os testes baseados em risco e os automatizados não cobriram;
Tente ficar a frente dos desafios, espere por eles, seja pró-ativo ao lidar com os desafios, além disso seja realista perante a essa nova metodologia e o tempo que levará para ser tornar ágil, isso se você se tornar ágil;
Sempre teremos trabalho a fazer, nada virá pronto.

Ainda houve perguntas bem legais para o Rex Black, que abordaram a resistência de analisar os riscos, teste de performance durante as sprints e tempo da implantação do agile, gerando as seguintes respostas:

A Engenharia de Software é uma das principais atividades do ser humano. Se as pontes, prédios, escritórios quebrassem tanto quanto software seria inaceitável. Desta forma o primeiro passo para analisar os riscos é reconhecer a existência deles;
Problemas de desempenho geralmente são de design, e tem custos caros, portanto não espere até o fim, dessa forma, faça uma boa análise estática e teste em nível de unidade. E durante a sprint o software tem que continuar funcionando (integração contínua);
Nem todo mundo precisa ser ágil e algumas pessoas levam mais tempo, isso até mesmo dentro de uma mesma organização. A implantação precisa ser democrática.

Impressões da palestra

A palestra do Rex Black foi excelente! Conseguiu falar com propriedade sobre uma temática recente, isso graças as experiências e vasto conhecimento em Teste de Software que ele possui. Um único ponto negativo, foi o excesso de texto nos slides (aliás, pelo que eu me lembre, quase todos os palestrantes colocaram muito texto nos slides).

No mais, foi muito interessante ouvir a experiência e opiniões do Rex Black sobre testes ágeis, realmente são uma série de desafios que enfrentamos quando iniciamos a implantação de práticas ágeis, e é muito difícil você encontrar literatura ou pessoas que falam sobre o assunto.

A conclusão que tirei da palestra foi que o Teste de Software pode sim ser ágil, e ele precisa ser ágil, logicamente que não é fácil, mas utilizando estratégias adequadas e pessoas preparadas podemos enfrentar de forma mais efetiva os desafios. E por fim, a realização de testes baseados em risco é fundamental, pois o tempo é bem curto, e não é possível fazer todos os testes, por isso precisamos estar sempre priorizando quais testes precisam ser feitos e os que não precisam, em suma: é preciso ter foco!

Bem pessoal, aqui encerro a primeira parte da cobertura do primeiro dia do CInTeQ 2010, até a segunda parte! 😀

Cobertura CInTeQ 2010 – Dia 1 (parte 2)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Quando automatizar?

A décima Mesa Redonda DFTestes teve como tema “Quando automatizar?”, e foi uma mesa redonda bem agitada, com 32 respostas (até o momento desse post) e a participação de 12 pessoas, sendo elas: eu, Elias Nogueira, Jonathan Rodrigo, Felipe Silva, Ueslei Aquino, Rodrigo Almeida, Milton Vopato, Marcelo Andrade, Shmuel Gershon, Rafael Porfirio, Sarah Pimentel e Jorge Diz.

Segue abaixo, o “resumo” da décima Mesa Redonda DFTestes, mais uma vez lembrando, que se você se interessa pelo assunto, é altamente recomendável a leitura da discussão na íntegra. 😉

Quando automatizar?

Segundo o Elias Nogueira:

Quando automatizar no sentido que não seja testes funcionais:

=> Qualquer tarefa repetitiva que gaste muito tempo no processo de teste
– Quando gastamos muito tempo criando/formatando Casos de Teste
– Quando gastamos muito tempo colhendo e gerando métricas dos testes

Quando automatizar no sentido de testes funcionais:

=> Testes de regressão
=> Smoke Tests
=> Tarefas repetitivas
=> Funcionalidades críticas do software
=> Testes com cálculos matemáticos

O interessante é que existe pelo menos um tipo de teste que somente pode ser feito automatizado (excluindo-se Portugal): o teste de performance. A base do teste de performance não é somente executar um teste e capturar o tempo de resposta, mas medir diversas outras variáveis que vão compor uma série de informações que juntas poderão dar uma visão de performance da aplicação. (Para maiores informações, consultar o Fabio Martinho) 🙂

Se falarmos em linhas ágeis (Jorge, por favor complemente), basicamente 90% dos testes são automatizados, em virtude da agilidade na entrega, conhecimento de negócio da equipe e conhecimento da equipe em ferramentas.

A respeito do comentário do Elias sobre automação em linhas ágeis, eu penso que ela ocorre não em virtude da agilidade na entrega, e sim para garantir a qualidade na entrega, e principalmente, para garantir um desenvolvimento sustentável.

Na minha opinião os testes em nível unitário e integração também, que devem ser feitos pelos desenvolvedores, também são testes que devem ser executados de forma automática.

É bom lembrar que automação dos testes é um sonho de muitos profissionais da nossa área, porém ele pode passar a ser um pesadelo, se não for tratado de forma séria e madura (uma boa literatura sobre isso é o paper do Bret Pettichord – Seven Steps to Test Automation Success).

Pensando em uma equipe de Teste de Software, que realiza testes de sistemas, a automação é muito bem-vinda, quando há um grande volume de re-trabalho/testes de regressão.

Já pensando em uma equipe de Desenvolvimento de Software, os testes automatizados são de extrema necessidade, pois como costumam dizer, se você não escreveu testes para o seu código, você já está produzindo código legado.

Agora falando na linha ágil, a automação dos testes é essencial, olhando para o quadrante, percebemos que apenas os testes do terceiro quadrante são feitos de forma manual.

Dentre as razões citadas no livro Agile Testing, da Lisa Crispin e da Janet Gregory, estão:

Teste manual é demorado;
Reduzir a probabilidade de erros das tarefas de teste; (a tradução tá bem ruim, o original é assim: Reduce Error-Prone Testing Tasks)
Liberar tempo para fazer o trabalho o seu trabalho da melhor forma;
Prover uma rede de segurança, se eu fizer uma mudança no código eu terei os testes, que irão me avisar se eu quebrei algo;
Prover feedback cedo e frequente; (para mim está é a melhor razão) 😀
Os testes que direcionaram a codificação (ex.: TDD e BDD) podem fazer mais do que isso (ex.: se tornam testes de regressão);
Os testes provem documentação, aliás, são uma excelente documentação;
ROI, com o passar do tempo o esforço gasto na automação dos testes se paga.

A respeito do quadrante de Marick o Jorge Diz tem uma opinião diferente:

Não é bem isso, os quadrantes de Marick têm a ver com a ênfase na automação. Mesmo para os testes do quadrante superior direito (crítica do produto / voltados ao negócio) é possível ser auxiliado por ferramentas de automação. Em outros quadrantes, não se descarta o teste manual. Na prática, apenas os testes de unidade (quadrante inferior esquerdo) são inviáveis sem automação.

É bom lembrar que no modelo de teste ágil, testes são pensados não apenas como mecanismo de detecção de defeitos, mas que também é analisado seu papel de especificação do comportamento do sistema e suporte à equipe de desenvolvimento. Requisitos, testes e exemplos são aspectos diferentes das mesmas especificações. De fato, esta semana bloguei sobre isso.

A respeito sobre a automação no contexto ágil , o Jorge Diz falou que:

Você não consegue ciclos curtos de entrega se tiver que orçar um ciclo de teste manual. Você não consegue qualidade se não tiver testes que podem ser rodados à vontade. Você precisa escrever e executar os testes junto com o sistema sendo desenvolvido para encurtar o ciclo de comunicação

com o cliente e não perder tempo e esforço com mal-entendidos.

No entanto, a ênfase em automação chegou a ser exagerada. Hoje, a comunidade ágil começa a valorizar os conceitos da escola context-driven,

que dá mais importância a testes manuais e exploratórios

Para o Jonathan Rodrigo precisamos ter maturidade e precisamos levar em consideração a quantidade de ciclos de testes que teremos, para que a automação possa ocorrer:

E em uma fábrica de teste se automatizarmos um caso de teste ou uma funcionalidade de forma incorreta (com dúvidas referente aos requisitos) iremos produzir evidências erradas com muito mais velocidade gerando assim um grande prejuízos, como por exemplo a desconfiança do trabalho da fábrica pelo cliente causando assim a perca do mesmo.

Porém se for bem planejada a automação e for executada conforme o planejamento o projeto será um sucesso, pois realmente automatizar diminui os custos e aumenta a velocidade da produção, claro se tudo estiver bem definido e sem sobras de dúvidas, pois se não estiver bem definido os custos podem aumentar e trazer grandes prejuízos.

Termino respondendo a pergunta:

Automatizar quando? Quando tiver maturidade, processo para suportar a automação e quando for identificado que iremos executar o teste mais de 4 ciclos, pois em meu ponto de vista não vale o investimento da automação em caso de teste que será executado menos de 4 ciclos.

O Felipe Silva acredita que devemos automatizar os testes quando:

1. Quando autorizado pelo cliente
2. Quando viável (ganhar tempo ou redução de custos/recursos)
3. Quando tiver ferramenta e gente capaz de usá-la (“um tolo com uma ferramenta continua sendo um tolo”)

Creio que essas 3 respostas são a base de todas as outras.

1. Pode parecer estranho, mas no meu caso estamos proibidos pelo cliente de automatizar testes funcionais.

2. O fato ganhar tempo OU reduzir custos é a alma de qualquer automação, pois ganhar tempo significa ganhar dinheiro (“tempo é dinheiro”), reduzir custos e recursos é bom também, nem sempre andam juntos, as vezes vale a pena gastar um pouco mais para ter uma entrega mais rápida. Poder alocar recursos em outras atividades que envolvam qualidade (quando se pensa em automação industrial não tiveram tantas vagas na área de qualidade para o número de operários trabalhando o que gerou desemprego), é aqui que cabe a maturidade.

Automação não substitui teste manual e não encontra um percentual de defeitos maior do que o manual, pelo contrário, gráficos mostram que testes manuais encontram mais defeitos que automatizados, pois quando se está lidando e interagindo diretamente com o sistema você consegue pensar (ver) uma situação que até então não tinha pensado apenas lendo um requisito.

Sabendo disso, diria que automatizar com sabedoria é fazê-lo pensando em um teste que tenha como alvo testar parte do sistema, pois pensar que você irá automatizar 100% dos testes é ilusão (assim como é ilusão dizer que você tem certeza que 100% dos defeitos foram encontrados em qualquer tipo de testes), fazendo assim, após ter o script fazendo uma rotina de testes “óbvios” pode-se então focar em testes melhor elaborados no qual tenha que pensar com malícia para imaginar um caminho que consiga quebrar o sistema, pensar em uma situação ainda não prevista por ninguém. Salvo alguns casos como já citado pelo Elias em que manual não é viável (testes de performance, que envolvam cálculos, etc)

3. Ter ferramenta não significa comprar a mais cara no mercado, significa ter uma ferramenta que te gere resultados. A ferramenta “abc” usada pela maior empresa do mundo “fgh” não faz dela a melhor para você, e a melhor para você neste projeto pode não ser a melhor no outro projeto, não ser a melhor também não significa que não serve, se o resultado final gerado é pósito então vale a pena, o único fato é que se outra ferramenta daria um resultado positivo maior pode-se rever/calcular/viabilizar ou não uma mudança de ferramenta.

Tendo a ferramenta vem o mais o importante – antes de comprar a ferramenta é lógico – que é saber utilizá-la, e sabendo usar! Também não adianta nada ter um time expert no assunto e uma ferramenta excelente para ficar na “prateleira”, infeliz é o “chefe” que pensa que vai comprar uma ferramenta e você vai se virar para colocar ela para funcionar, treinamentos e capacitação são necessários.

Saber fazer um script bom não significa que a pessoa está fazendo da melhor maneira possível, quanta gente já não disse “era só isso? quer dizer que você só colocou essa linha de código e já faz tudo isso? nossa antes eu fazia…..”

Automação é um projeto, não parte de um projeto e deve ser tratada como tal, com líder de projeto, desenvolvedor, pessoas responsáveis pela qualidade do que está sendo criado/mantido, cronograma e orçamento.

Na minha opinião além de analisar se será viável (ganhar tempo ou redução de custos/recursos) automatizar o teste X eu também preciso analisar se o teste X será mais eficaz se automatizado ou não, pois executar ele de forma automatizada precisa, pelo menos, garantir a mesma qualidade da execução manual.

Ou seja automação deve pelo menos, garantir a mesma qualidade que os testes manuais, afinal de nada adianta ter um monte de suítes de testes automatizadas se elas não testam nada. 😉

A respeito da viabilidade da automação dos testes (citada pelo Felipe), é preciso também levar em consideração o sistema sob teste, pois se eu automatizar hoje, o teste X, que testa a funcionalidade Y, e amanhã a funcionalidade Y mudar, essa mudança poderá quebrar o meu teste X.

O Ueslei Aquino compartilhou um pouco da sua experiência, relacionado ao assunto da mesa redonda:

Imaginem o que é assumir um departamento de “testes” com missão de torná-lo um departamento de “Qualidade” (Garantia e Controle de qualidade) com 9 profissionais que nunca tiveram um treinamento em testes. A visão do cliente em relação ao setor era… “este setor não me gera resultados financeiros positivos e eu tenho aqui a ferramenta X que 2 pessoas que passaram por aqui não conseguiram implantar, fique com ela 2 meses estudando e depois me apresente o cadastro Y sendo testado por ela.”

Diante do conhecimento, procurei mostrar que sem ter pessoas treinadas, processo e metodologia de teste definidos, documentação de teste… iniciar automação poderia não ser a solução, mas um tiro no pé. Mas, sem sucesso para minhas colocações… a intenção era automatizar os testes e assim poder vender serviço de teste, ou seja, vender para os clientes do próprio sistema poderem utilizar e testar as aplicações e assim gerar resultados financeiros positivos ao setor.

Parece loucura né… mas é a mais pura verdade. Ou seja, eu estava construindo um legado de teste, com uma aplicação que tive que me virar para colocar para funcionar. O Cliente ficou ciente dos riscos, mas quis arriscar…

Diante disso, o que posso dizer do resultado foi… recebi uma proposta irrecusável…saí da empresa e eles continuaram com o processo e inclusive iam começar a aplicar em um cliente que estava implantando o sistema.

O Rodrigo Almeida também compartilhou uma experiência com automação:

Temos uma ferramenta de automação de testes desde 2000. E só em 2008 é que aprendemos como usá-la corretamente.

Tivemos que trocar toda a equipe, contratar pessoas com perfil técnico e conhecimento de lógica de programação.

Mudamos o nosso processo de testes, para podermos automatizar aquilo que era necessário, crítico e kernel dos nossos produtos. Antes a gente automatizava somente as partes periféricas dos produtos, sem impacto efetivo na detecção de defeitos. E os scripts eram criados por pessoas que não conheciam de programação/lógica. Os resultados eram terríveis.

Então, a decisão de quando automatizar foi baseada nas seguintes premissas: É parte do núcleo do sistema? É usado por vários clientes? Faz parte do processo funcional do cliente? Se sim para uma ou mais de uma pergunta, então automatiza.

Com a mudança radical feita em 2008, saímos de uma média de erros mensal na ordem de 140 erros para uma média de 50 erros/mês em 2009. Não alteramos nada no processo de desenvolvimento. Somente criamos um processo novo de automação de testes funcionais. Não fazemos testes de performance, somente automatizamos testes funcionais e executamos os testes já gravados (teste de regressão).

Com uma equipe correta, ou seja, com conhecimento em programação, conseguimos diminuir nosso ciclo de testes que eram de dois meses, isto mesmo, dois meses, para 12 horas! Somente otimizando os scripts já gravados.

Para o Milton Vopato devemos automatizar quando:

Na minha opinião, a automatização é positiva e é uma tendência para ganho de eficiência. Quando automatizar? acredito que quando você processos mapeáveis, tipo execução em batch, performance, lista de informações padrões, etc. Este tipo de validação economiza tempo para regressões, mas quero chamar atenção a outro ponto de quando automatizar. quando pensamos em quando automatizar, pensamos para que e no processo como um todo, mas acho válido, com uma análise de benefício, criar automatizações parcial do processo de teste funcional também, ex: Hoje validados requisitos funcionais em um XML, então automatizamos a criação do request e agora estamos trabalhando na automatização da leitura de algumas tags na saídas, com isso ganhamos performance e qualidade na execução

O Shmuel lembrou de uma automação que é muito bem-vinda em uma área de Teste de Software:

Me parece que nenhuma resposta comentou em um tipo de automação muito útil: A automação do ambiente.

Em sistemas aonde é necessário configurar a rede o produto e os periféricos de forma específica antes de começar a testar, automatizar o processo de configuração é muito útil.

E além do mais, essa automatização acaba sendo muito apreciada e utilizada por toda a organização, incluindo programadores, pessoal de suporte etc.

Essa automação é legal também porque ela não atrapalha ou influência os testes funcionais.

Já a automação de testes funcionais me da certo medo… 🙂

É muito fácil exagerar na quantidade te testes automatizados, e é mais fácil ainda exagerar na confiança dada a automação.

Com isso, devo colocar que aonde trabalho temos um sistema de automação bem extenso, e tentamos automatizar todos os testes importantes para serem rodados como regressão.

Para o Rafael Porfirio:

A automação também (ao meu ver) é uma opção quando temos uma certa estabilidade na aplicação em que estamos testando assim como o ambiente em que testamos, por isso em muitos casos a primeira coisa a se automatizar são os ciclos de regressão, visto que já foram testados manualmente e de certa forma atingiu uma certa estabilidade por já ter passado por outros ciclos de teste manual.

Outra coisa que devemos levar em consideração, também é o tempo que se leva para criar (scripts de alto, média ou baixa complexidade) e também para se dar manutenção….se você tem uma aplicação onde a cada release seu script deve ser recriado….talvez não seja viável a automação…

Ainda assim, muito é importante ressaltar que um teste automatizado jamais substitui teste manual. Pois assim como desenvolvedores não conseguem fazer todo o codigo 100% correto, como testers podem confiar em sua própria programação para um script?

A Sarah Pimentel fez considerações bem interessantes sobre o tema:

Eu sou bem adepta a processos, não como forma de burocratizar, mas como forma de organizar.

Então pra mim a primeira coisa é ter um processo para decidir isso. E essa decisão se dá em cima de viabilidade de automação.

Trabalhei em uma empresa que tinha uma equipe de automação separada da dos testes funcionais (eles também fazem testes funcionais, mas são especialistas em automação). Quando uma equipe solicitava a automação dos seus testes tinha que responder um questionário inicial para que a equipe de automação avaliasse a viabilidade desse projeto. Por que isso? Porque ao contrário do que muitos pensam nas empresas automatizar ao invés de ser a solução dos seus problemas pode ser mais um gerador de problemas.

Algumas considerações:

Você está automatizando porque você acha que vai encontrar mais erros?

Não vai. O processo automatizado tende a encontrar cada vez menos erros e até mesmo em determinado ponto, não encontrá-los. De tanto rodar os mesmos testes a aplicação fica estável naquele ponto e dificilmente aparecem erros ali.

Você acha que pode automatizar a sua aplicação a qualquer momento e que essa investida é suficiente?

Há dependências de interface gráfica. Se o desenvolvedor mudar “só um negocinho”, pode ser que o teste tenha que sofrer manutenção.
Também vale ressaltar a excelente comunicação do negócio com os desenvolvedores e os testers porque se mudanças no negócio forem discutidas no café e implementadas sem que os testers saibam, o teste também não vai funcionar.

Testes automatizados precisam ser testados?

Obviamente que sim. São programas. Se foram escritos por testers ou desenvolvedores não quer dizer que não possam ter erros. Automatizar precisa passar (rapidamente, claro) pelos mesmos estágios que o desenvolvimento de qualquer outro software. Com base na especificação ele será construído e alguém precisa validá-lo.

Amanhã tá pronto?

😀 Não! 😛

Automatizar requer tempo. Você está disposto a esperar? Quando estiver pronto, você vai ter tempo de utilizar? Por quanto tempo? Compensa?

Dá pra automatizar qualquer coisa?

Bom, não sou expert em automação para dizer que não. Tem um monte de gente na lista que sabe mais que eu pra falar isso, mas sei que tem coisa que é tão complexa que não vale a pena “perder” esse tempo (da forma como foi colocado na observação acima)

O desenvolvedor participa da automação?

Pode ser que seja necessário envolver o time de desenvolvimento para fazer algum ajuste (testability). A equipe de dev dispõe dessa alocação para ajudar?

Enfim. Depois de tudo isso, eu queria dizer que automatizar é legal sim! 😀 Só que é uma coisa que tem que ser planejada com tanto carinho quanto qualquer outro software.

Para o Jorge Diz:

A implantação de testes automatizados cria uma dinâmica diferente, para bem ou para mal. Se dependermos exclusivamente de testes manuais, a cada mudança necessária do sistema há o dilema de incorrer em um custos e prazos significativos para cada ciclo de teste: é extremamente difícil para um gestor avaliar o risco de não testar. A gestão tende a ser mais conservadora em melhorias do sistema (por conta do custo das mudanças), e a manter ciclos longos de entrega de funcionalidades.

Com testes automatizados, o gestor consegue ter informações mais confiáveis. para decidir, e diminuir muito o investimento a cada ciclo. Testes automatizados são uma forma de seguro contra diversos riscos, e ajuda a que as mudanças necessárias ao negócio possam ser implementadas. Oportunidades de negócio deixam de ser perdidas.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Saiba mais

Segue abaixo, algumas publicações que foram referenciadas sobre o assunto, durante a mesa redonda:

Apresentação: 4° Encontro Mensal ALATS: Automação de Testes, Mitos e Verdades

Livro: Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality

Livro: Automated Software Testing: Introduction, Management, and Performance

Livro: Agile Testing

Fórum: SQA Forums – Automated Testing

Artigo: Seven Steps to Test Automation Success – Bret Pettichord

Fique por dentro das novidades, assine o feed do QualidadeBR.

Teste Ágil, como implementar?

A segunda Mesa Redonda DFTestes teve 10 participantes: eu, Wagner Duarte Júnior, Felipe Silva, Cibele, Elias Nogueira, Ralph Montelo, Marcelo Andrade, Aderson Bastos (um dos autores do livro Base de Conhecimento em Teste de Software), Robson Agapito e o José Correia.

Como puderam notar, grandes nomes da comunidade brasileira de Teste e Qualidade de Software participaram da Mesa Redonda, e todos com o mesmo objetivo, discutir sobre “Teste Ágil, como implementar?”. 😀

Vamos então para o resumo dessa discussão que teve 17 respostas.

A discussão teve um desafio a mais dessa vez, pois o tema é bem recente, tanto que há apenas um livro focado nele, o Agile Testing da Lisa Crispin e Janet Gregory. E o no Brasil há pouquíssimo material sobre o assunto. Então, acredito que o grande objetivo da discussão foi tentar desmitificar um pouco o que é Teste Ágil e como podemos implementá-lo na nossa empresa, não trazendo fórmulas mágicas ou receitas de bolo (até porque isso não existe em projetos de software), e sim experiências vivenciadas pela comunidade e conhecimentos adquiridos, que possam orientar como dar os primeiros para a agilidade no Teste de Software.

Afinal o que é Teste Ágil?

Como de praxe em uma discussão sobre agilidade, é bom apresentar os princípios ágeis do Manifesto Ágil, que também norteiam o Teste Ágil:

Indivíduos e interação entre eles mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos;
Responder a mudanças mais que seguir um plano.

Lembrando que os itens da esquerda são mais valorizados do que os da direita, mas isso não que dizer que os da direita sejam ignorados.

O Wagner apresentou de forma muito clara o que se espera quando dizemos que algo é ágil:

Sou um grande apreciador da qualidade. Por isso, acredito que tenhamos realmente que tornar o nosso trabalho cada vez mais ágil, porém, não podemos nos esquecer da qualidade, que é o forte da nossa área. Vejo então, que devemos unir com sabedoria, essas duas vertentes. Um processo relativamente simples, que possa ser executado com grande facilidade e agilidade, cobrindo o maior número de riscos, com uma qualidade que seja apreciada e valorizada pelo usuário final. Um processo sem muitas “firulas” e com a qualidade esperada pelo cliente ou ainda, superando as expectativas do mesmo.

Na minha opinião, Teste Ágil é um conjunto de práticas que proporcionam a diminuição do tempo entre o erro e a sua descoberta, baseada no contexto ágil e nos princípios do manifesto ágil.

Para o Elias Nogueira Teste Ágil:

É uma abordagem de teste que está aderente ás práticas de agilidade descritas no manifesto ágil;

É a área de teste sendo mais pró-ativa do que reativa;

É integrar/relacionar os testes as metodologias de desenvolvimento ágil (TDD, XP, FDD, BDD, etc…).

O que muda do Teste Tradicional para o Teste Ágil?

As considerações feitas pelo Elias Nogueira deixaram claro que o Testador passa a ser um profissional muito mais dinâmico:

Testadores serão mais pró-ativos, tendo participação direta com o cliente;
Testadores terão um foco mais técnico, pois estarão trabalhando como par de desenvolvedores;
Testadores precisam saber automatizar, para poder manter o ciclo de entrega dos testes sempre no mesmo tempo/sprint.

Para mim as mudanças são as seguintes:

Acredito que a principal mudança é em como você exerce o seu papel, as técnicas a serem utilizadas para a criação dos testes e todas as outras teorias provenientes, podem te auxiliar a entender e exercer melhor as suas tarefas de uma forma mais ágil e efetiva;
O que vejo que muda muito, é que os desenvolvedores também testam, e testam pra valer, tanto que devem haver mais testes de unidade e integração do que testes de sistema e aceitação;
O Teste de Software se torna mais preventivo, práticas como o TDD e a Programação em Par, contribuem para melhorar a qualidade do software que está sendo desenvolvido, e evitar a inserção de erros;
O time de teste não precisará focar nos testes que validam se o sistema está sendo de acordo com o cliente solicitou, e não se preocupam em cobrir verificações básicas, como cobertura de desvios;
A automação é essencial para o Teste Ágil, é o ingrediente que fará o teste ser realmente ágil;
Os testes manuais existem, mas são mais para os tipos de testes que realmente não tem como automatizar, como por exemplo: usabilidade;
O time de teste passa a participar de forma mais efetiva e integrada com o time de desenvolvimento, não espaço para rivalidade, pois ambos trabalham focando o mesmo objetivo, entregar um produto com qualidade;
Os testes tornam-se rotina, não é mais uma tarefa feita só no final do desenvolvimento do software.

Como podemos implementar o Teste Ágil no nosso dia-a-dia?

O Aderson Bastos vez uma interessante consideração sobre Teste Ágil em metodologias não ágeis:

É possível testar de forma ágil com qualquer tipo de metodologia de desenvolvimento, obviamente algumas metodologias privilegiam este tipo de abordagem. RUP, XP, Scrum, FDD, etc, são ótimas referências para elaborarmos uma boa metodologia, mas nenhuma delas garantirá agilidade. Não somos ágeis porque utilizamos Scrum e/ou XP, por exemplo, – lembrem-se do manifesto ágil: “indivíduos e interações mais que processos e ferramentas”!!! – somos ágeis porque pensamos e agimos assim; porque quando somos eficazes no uso de todo o conhecimento (técnicas, boas práticas…) que temos.

A Cibele listou importantes fatores que nos ajudam a saber se a implementação de uma metodologia ágil será uma boa ou não:

Onde será aplicada;

Tipo da empresa;

Maturidade de processos e dos profissionais;

Cliente;

Time;

Tipo de sistema a ser desenvolvido e várias outras coisas.

E a Cibele ainda fez importantes considerações, sobre a implementação de metodologias ágeis e Teste Ágil, com base em experiências vivenciadas:

Não basta só implantar o processo ágil, é preciso checar se há ambiente propício para isso. E mais importante, começar devagar, pegar um projeto pequeno como piloto e ter pessoas na equipe que conheçam o processo muito bem. Fica mais fácil de analisar a evolução e corrigir erros.

Não há uma receita de bolo a seguir. É preciso conhecer o processo ágil muito bem, assim como a cultura da empresa e a maturidade dos seus colaboradores e em cima disso, montar uma estratégia de implantação do processo ágil. Pelo que presenciei nesta empresa, o teste ágil está dentro do processo ágil. Mas é possível adotar práticas ágeis em testes em qualquer tipo de processo ou metodologia.

O Elias Nogueira fez as seguintes sugestões para a implementação do Teste Ágil:

Trazendo o cliente para perto e fazendo com que ele entenda as atividades de teste e que ele entenda que ele mesmo é o principal fator de sucesso;
Alterar nossa Cultura Organizacional (todos devem ser ágeis, da tia do café ao presidente da empresa);
Manter a equipe atualiza e ter feedbacks constantes para todos os stakeholders;
Estudar e implantar mais testes caixa-branca junto aos desenvolvedores;
Prover formas automatizadas para a execução de testes em todos os níveis.

O Robson Agapito relatou como ele está começando a implantar Teste Ágil:

O primeiro passo que estamos trabalhando é treinar a equipe de desenvolvimento para estar aptos a realizar testes unitários, após isso implantado e assimilado por toda a equipe creio que será mais fácil de mudar a metodologia para alguns projetos.

Para o José Correia:

O ideal é convencer sua organização a fazer um piloto e a partir dessa experiência ir aperfeiçoando. A primeira vez não vai ser incrível. Não existem metodologias mágicas, é necessário aprender com erros e acertos, acreditar, medir, ajustar e comprovar progressivamente os ganhos.

Na minha opinião, precisamos implementá-lo de uma forma incremental, e de preferência iniciando com os testes no desenvolvimento do software:

Antes de tudo, é preciso estudar e entender o motivo pelo qual o Teste Ágil existe;
Implantar de forma gradativa;
Antes de criar um teste, pensar se ele pode ser automatizado, e se vale a pena automatizá-lo;
Lembre-se que o Teste Ágil, causa uma inversão na pirâmide dos testes, ou seja, ao invés de temos muitos testes de sistema e aceitação, teremos mais testes de unidade e integração. Então, e a responsabilidade da criação de tais testes é em primária instância do desenvolvedor;
Atue perto do cliente, afinal você deverá ter pleno conhecimento sobre o que ele está esperando do sistema;
Querer criar testes de unidade e integração para sistemas legados, é quase impraticável, porém para as novas funcionalidades e manutenções, por que não criar?

Quais são as maiores dificuldades para implementar-lo?

Segundo o José Correia o mercado ainda tem resistência em experimentar as metodologias ágeis:

Nos projetos que acompanho, o uso de práticas ágeis é elegível apenas quando o número de horas totais do projeto é inferior a 1000 horas. Alguns clientes são mais conservadores e estabelecem um teto de 640 à 800 horas. Projetos acima são tocados dentro das práticas do RUP, modelos CMMI/MPS.br e os testes complementados com base no Syllabus/ISTQB, CBOK/QAI, normas ISO e IEEE.

Algumas empresas que antigamente diziam usar “metodologia própria” para disfarçar a falta de um forma de trabalho estruturada, agora passaram a dizer que são “Ágeis” o que é péssimo para as empresas que realmente utilizam as práticas e fazem um trabalho sério. Ou seja, muitas empresas de grande porte, como diversos Bancos têm grandes restrições por experiências ruins com alguns desses fornecedores.

Para o Elias Nogueira podemos enfrentar as seguintes dificuldades:

Cultura organizacional resistente;
Equipe não multidisciplinar;
Cliente não é ou não gosta de ser ágil;
Conhecer agilidade e os conceitos no Manifesto Ágil;
Participar reativamente como área de teste (esperar todos os documentos na mão).

Eu vejo que as maiores dificuldades, tem relação as pessoas, até porque Teste Ágil antes de tudo, é uma questão de atitude:

É uma mudança de cultura, então costuma haver uma grande resistência;
O time de teste é forçado cada vez mais a está pesquisando sobre novas ferramentas e saber programar, pois como disse antes, a automação é essencial;
A mudança também afeta o cliente, ele também deverá ser tornar mais participativo e comprometido com o sucesso do sistema, e passar para o time de desenvolvimento as suas reais necessidades e opiniões do sistema.

Quais as vantagens de sua implementação?

Podemos obter diversas melhorias com a implementação do Teste Ágil, não apenas no processo, mas como também na motivação das pessoas:

O número de bugs a ser encontrados pelo time de teste tende a ser bem menor, principalmente devido ao fato do grande foco na prevenção dos mesmos;
O desenvolvimento do software torna-se sustentável, se for necessário fazer alguma mudança, os desenvolvedores não terão receio, pois poderão executar uma bateria de testes unitários para verificar se a mudança não quebrou nada;
As entregas passam a ser mais rápidas;
A participação do cliente de forma mais efetiva, faz com que o software tenha aquilo que realmente o cliente deseja;
A automação torna a execução do testes mais rápida, ou seja, passar a ser mais econômica;
O retrabalho e manutenção será muito menor, fazendo com o que o custo e o tempo para o desenvolvimento seja menor.

O Elias Nogueira levantou as seguintes vantagens:

Maior velocidade na execução do projeto
Maior rapidez no conhecimento do projeto
Entregas mais focadas na necessidade do cliente
Cliente se sentirá feliz e realizado em ver como estão as atividades e saber realmente o que será entregue
Maior disseminação de conhecimento técnico e de negócio para a equipe

Durante a Mesa Redonda surgiu uma boa discussão, iniciada após o Ralph Montelo compartilhar as seguintes opiniões:

Sinceramente? “Teste Ágil” são duas palavras que (infelizmente!) não combinam. Mesma coisa que dizer “Inteligência Militar”. (!)

Métodos ágeis são ótimos quando o assunto é economia e agilidade na entrega. Quanto à qualidade, prefiro não comentar. Não consigo confiar 100% em uma metodologia que preza a “não-documentação”, pois continuo seguindo minha carreira utilizando a Regra 10 de Myers à risca. E não me arrependi em momento algum.

Em resposta o Wagner disse:

Vejo que o tempo tem se tornado cada vez mais curto, por isso põem-se interessante a idéia de agilidade com qualidade. Pois a partir do momento em que o foco se torna apenas a “agilidade”, não estamos mais falando de “Teste e Qualidade de Software”.

Temos que realmente unir o “útil (qualidade) ao necessário (agilidade)”.

E o Marcelo Andrade lembrou que ser ágil é buscar fazer direito na primeira vez e produzir documentação efetiva e útil:

Ágil combina menos com “pressa” e mais para fazer direito. (Da fábula da
lebre e a tartaruga, sem dúvida, o animal que melhor representa técnicas ágeis
é… a tartaruga). Se alguém acha que desenvolver de forma ágil é fazer com
pressa, com certeza não está fazendo ágil da forma correta.

É falso dizer que métodos ágeis prezam a “não-documentação”. O mito da
documentação é algo que incrivelmente as pessoas não entendem no manifesto
ágil. Ao contrário, se preza muito toda a documentação que seja efetiva e útil.
A propósito, artefatos de testes estão entre os melhores tipos de documentação
que existem. Sugiro a leitura deste artigo:

http://www.infoq.com/br/news/2009/08/agile-documentation

Pra fechar o resumo com chave de ouro, nada melhor, do que apresentar as 7 práticas para tornar o Teste de Software ágil, que nada mais são do que soluções de um profissional que buscou a melhoria contínua e agilidade, não porque está na moda, e sim porque tornaria o seu trabalho mais efetivo, todos os créditos ao Felipe Silva, que compartilhou as seguintes práticas:

Planejar uma sequência de testes a serem executados de forma que em um único fluxo se consiga validar o máximo de cenários possíveis, chamamos isto de “Overlap”, pois unimos o que seria mais de um Test Case em apenas um Test Case contendo os steps de todos;
Automatizar ou simplificar rotinas, por exemplo criando não apenas scripts para testes, mas também scripts, macros e programas que façam coisas que você faria manualmente;
Ter Casos de Testes claros e diretos, se sua equipe de testes não é formada por “um monte de mães” (como na discussão passada) pode-se pensar em escrever Casos de Testes que vão direto ao ponto, o step de validação e nada mais,;
Gerenciar manobras de riscos, para caso o test A pare, então o B já esteja na lista para ser executado, assim não tendo impacto no prazo do delivery e enquanto estiver testando B já estar providenciando a solução para que o A volte a ser testado;
Trabalhar em equipe e tirar uns 20 a 30 minutos para discutir um requisito entre os envolvidos do testes economiza horas de pessoas que tem medo ou vergonha de se expor dizendo que não entenderam ou não sabem e assim sendo sem perceber atrasam a entrega e correm o risco de não fazer um teste com qualidade;
Suporte do cliente é fundamental, na nossa equipe hoje temos uma pessoa alocada no cliente que faz o papel de gerente de testes e revisor de requisitos ao mesmo tempo, esta pessoa é a ponte inicial para todas as dúvidas e quase sempre tem todas as respostas que teriam que sair direto do cliente, é um profissional de testes (modelo indiano de gerencia);
Tornar os profissionais especialistas em partes do projeto, de modo que todo mundo saiba um pouco do projeto como um todo e você sempre terá 1 especialista em qualquer assunto do projeto, tendo assim na soma dos profissionais uma equipe especialista, as vezes sabendo mais que o próprio cliente do assunto, entendimento rápido do negócio gera processos ágeis para o teste, seja na criação ou na execução dos testes.

Se interessou pelo assunto, então confira a discussão na íntegra, acessando o DFTestes. E se quiser participar das próximas Mesas Redondas, é só fazer a sua inscrição no grupo.

Fique por dentro das novidades, assine o feed do QualidadeBR.

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.

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:

FiTNEss+DoFixture;
JBehave (Java);
Easyb (Groovy);
Cucumber (Ruby).

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.

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

Ontem (30/09/09) ocorreu o 6º Encontro Mensal da ALATS SP. Desta vez, sobre um tema bem atual “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, palestrada pelo Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, pela UNICAMP, e instrutor na Globalcode.

A seguir, relato as minhas impressões sobre o encontro.

Primeira parte

Ao chegar (cheguei alguns minutos atrasados) o Jorge estava mostrando uma cena do filme Matrix.

Em seguida, comentou que tentaria dá uma de Morpheus, referindo-se a apresentação de ambas metodologias tradicional (cascata/modelo-V) e a ágil (Lean, Scrum, XP e Context Driven). E ainda disse que seria necessário tomar a pílula vermelha para entender esse novo paradigma.

Um ponto bem interessante levantado pelo Jorge, logo no início, foi que errar faz parte do aprendizado, e como o desenvolvimento de software, acaba sendo um aprendizado constante, exercido durante um período de tempo (projeto), errar faz parte. E o fluxo do erro é o seguinte: erro -> defeito -> falha -> diagnóstico -> correção.

Portanto, precisamos tomar medidas para que o defeito se revele o mais cedo possível. Afinal, quanto mais cedo ele for descoberto, menor será o seu cu$to.

Depois o Jorge apresentou o modelo cascata de desenvolvimento de software e na sequência argumentou sobre as suas características relacionadas com a área de testes e seus resultados, que resumindo:

Como é necessário que os requisitos sejam precisos, precisamos fazer com que o cliente pense tudo antes! Resultando em um detalhamento precoce dos requisitos;
A arquitetura torna-se hipertrofiada, o design especulativo e o desenvolvimento Nostradamus. Pois acabamos tentando atender mais do que as necessidades do cliente, não há muito contato com o mesmo, durante o desenvolvimento. Portanto, pensamos no que achamos que ele gostaria de ter e não no que ele realmente precisa, e além disso o desenvolvedor é orientado ao e se…
Poucos podem conversar com o cliente, e a orientação e de que é melhor nem ouvir, pois ele sempre irá pedir mais, ou mudar algo;
Como há menor feedback do cliente, a chance de desenvolver funcionalidades inúteis é grande;
A fase de teste acaba, geralmente, sendo zipada, ou seja, quando ela é iniciada o prazo está quase no fim, isso quando já não está estourado. Resultando numa entrega com um nível inadequado de testes e as falhas aparecem no pior momento possível, em produção.

Durante essa parte da apresentação o palestrante apresentou dois gráficos interessantes, um bem famoso e o outro nem tanto assim:

O primeiro é o famoso Princípio de Pareto aplicado ao desenvolvimento de software, pelo qual 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

Já o segundo apresenta uma comparação entre metodologias ágeis e tradicionais, onde é possível observar que o retorno do investimento (ROI) ocorre mais cedo e é maior do que utilizando metodologias tradicionais.

Para terminar a primeira parte o Jorge falou sobre inspeções e revisões. Onde ficou claro que é importante realizar inspeções e revisões, porém elas não substituem os testes, até porque encontram outros tipos de defeitos.

Coffee Break

Vinte minutos de um delicioso coffee break, onde o pessoal pode conversar mais e se conhecer melhor, o famoso encontro das ilhas (rsrs).

Segunda parte

Voltando do coffee break o José Correia fez uma breve apresentação sobre a ALATS e o encontro semanal, trazendo novas notícias:

Exame da CBTS será realizado pela 1ª vez em Campinas, na R. Teodoro Langard, 126 – Bonfim, próximo a nova rodoviária de Campinas;
UNIESP abriu o circuito de palestras da ALATS em São Paulo;
Embaixadores da ALATS;
E ainda adiantou o tema do próximo encontro que será sobre Alta Automação, palestrada pelo pessoal do Grupo HDI (que estiveram no BRATESTE desse ano).

Continuando a apresentação, o Jorge Diz comentou sobre o modelo V, analisando os resultados que ele traz para a área de Teste de Software:

O tempo entre o erro e a correção ainda é longo;
Ainda ocorre detalhamento precoce dos testes, sem execução para atestar sua validade.

Finalmente, o palestrante chegou ao tema do encontro, dizendo que era necessário um novo modelo para o desenvolvimento, e que esse novo modelo precisava encurtar os ciclos de desenvolvimento.

O Jorge fez uma boa introdução sobre metodologias ágeis explicando o seu nascimento, o manifesto ágil (espécie de pai-nosso das metodologias ágeis) e citou as principais metodologias ágeis:

Lean: modelo conceitual;
Scrum: gestão;
XP: práticas de engenharia;
Context-Driven: técnicas de testes.

E “lógico” que numa apresentação sobre metodologias ágeis, o pobre RUP tinha que ser criticado, então Jorge fez a comparação entre os papéis existentes no RUP (muitos) e os 3 papéis existentes no Scrum (solicitante – PO, facilitador – Scrum Master e time). Eu particularmente, não acho que o RUP seja o vilão, o que ocorreu/ocorre é que muitas pessoas não souberam interpretar ele (exemplo: os papéis do RUP são “chapéus”, e não cargos!).

Logo após ter feito a comparação entre os papéis do RUP X Scrum, que já tinha gerado uma discussão com o público, o Jorge comentou que a pessoa de teste está dentro do time de Scrum e que também necessita ter conhecimentos de programação, o que gerou mais uma boa discussão com o público.

Após a discussão, o Jorge Diz fez comparações do que é possível fazer em 15 segundos (entender um método), 15 minutos (gerar um build testado), 15 horas úteis (uma funcionalidade), 15 dias (um sprint) e 15 semanas (uma entrega).

E por fim o palestrante falou sobre o novo modelo de testes, no qual há mais testes unitários do que testes de integração e menos testes de sistemas do que de integração, ou seja, o inverso do que ocorre utilizando metodologias tradicionais. E explicou o quadrante de testes ágil, desenvolvido por Brian Marick.

Considerações finais

Na minha opinião, a palestra teve um excelente início, no qual o Jorge Diz contextualizou muito bem e com uma ótima explicação o cenário do Teste de Software, perante as metodologias tradicionais. Porém, essa parte foi muito longa e comprometeu a parte mais importante do encontro, já que o tema foi “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas” e deu tempo só para ver um pouco sobre metodologias ágeis. Sobre as ferramentas, o Jorge apenas citou algumas (autotest, Cucumber, Junit, FitNesse, etc), de forma rápida, no final da apresentação. Ou seja, acabamos sendo atingidos pelo Tsunami, mas morremos na praia, devido ao tempo. Quem sabe o Jorge Diz não pode voltar num próximo encontro, até porque, estava muito interessante e o pessoal estava com várias dúvidas.

Para encerrar o post, gostaria de agradecer a todos que foram, o auditório estava lotado! E parabéns a todos da ALATS-SP, em especial ao José Correia pela iniciativa do encontro e por seguirem firme, que venha o sétimo!

P.S.: Assim que for disponibilizada a apresentação utilizada no encontro, eu atualizo o post com ela. 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte – Imagens

http://improveit.com.br/xp/desenvolvimento_tradicional

http://agile101.net/2009/07/22/self-funding-projects-a-benefit-of-agile-software-development/

6º Encontro Mensal da ALATS-SP

Pessoal,

O tema do 6º encontro mensal, promovido pela ALATS-SP, será “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, apresentado pelo Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP.

Acredito que será uma excelente oportunidade para compreender melhor a influência que as metodologias e práticas ágeis podem ter na nossa área, assim como trocar experiências sobre o assunto.

Segue abaixo, maiores informações sobre o encontro, retiradas da página da ALATS-SP:

Data: 30 de setembro (quarta-feira)
Horário: 18:30 – 22:00
Local: Av. Paulista, 726 – 17º andar conj. 1707D – próximo a estação de metro Brigadeiro

Objetivo:

Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:

Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas.

Conteúdo:

O modelo de desenvolvimento ágil sacode muitas das confortáveis premissas nas quais se baseava o desenvolvimento de sistemas até poucos anos atrás. A gestão da qualidade de software em geral, e as disciplinas de teste em particular, passam a ser afetadas substancialmente por este novo modelo:muda a inserção do profissional de testes dentro do processo, muda a importância relativa das técnicas de teste, muda a forma e o foco da gestão.

Novos focos e novas necessidades inspiram novas ferramentas. Paradoxalmente, coube aos desenvolvedores ágeis investir grande esforço em ferramental específico para testes e qualidade, mas os profissionais de testes e qualidade não têm participado ativamente deste processo.

Na primeira parte desta palestra, serão apresentadas as premissas do teste de software num contexto ágil, discutindo
como as mudanças do modelo afetam o perfil do profissional de testes do ponto de vista da gestão, da adoção da automação, das novas capacidades e habilidades necessárias, e dos papéis dentro da organização de desenvolvimento.

Na segunda parte, serão apresentadas novas ferramentas de teste originadas na comunidade ágil para suportar as necessidades de teste automatizado: bibliotecas para teste unitário, dublês de teste, (acceptance-)test-driven development, behavior-driven development, arquiteturas para favorecer a testabilidade, linguagens específicas de domínio e inserção do teste automatizado na integração contínua.

Agenda:

18:30 Credenciamento e networking entre os participantes
19:00 Início da palestra
20:00 Coffee break e networking
20:30 Continuação da palestra
21:30 Espaço aberto para discussão de temas da ALATS e da comunidade de Qualidade de Software em geral
22:00 Encerramento

Palestrante:
Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP.

Consultor com mais de 25 anos de experiência em tecnologia da informação, abrangendo desenvolvimento, testes, requisitos, liderança de projetos, pesquisa tecnológica e ensino. Atuou principalmente nos setores financeiro e de telecomunicações, em grandes empresas.

Começou a trabalhar com testes em 1994 e a estudar metodologias ágeis em 2000. Apresenta frequentemente palestras sobre tecnologia Java, testes e metodologia em eventos técnicos e acadêmicos, incluindo várias edições do JustJava e XP Brasil. Foi responsável pela trilha de metodologias no TDC (The Developers´ Conference) 2008 em São Paulo.

Atualmente é instrutor na Globalcode, onde se especializou em treinamento de teste de software baseado em ferramentas open source para times ágeis. Possui as certificações CSM, SCJP e SCWCD.

Inscrições:

– Associados ALATS: R$ 25,00
– Não Associados: R$ 30,00

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fique por dentro das novidades, assine o feed do QualidadeBR.

QualidadeBR

Teste & Qualidade de Software

Arquivo da tag: agile

Você precisa de Agile?

BDD – Behavior Driven Development

Surgimento do BDD

Melhorando a comunicação

BDD na prática

Cobertura CInTeQ 2010 – Dia 1 (parte 1)

Abertura do evento – Osmar Higashi – Atuação do BSTQB e Panorama Atual dos Testes no Brasil

Eduardo Habib – Teste de Segurança em Aplicações Web

Rex Black – Dealing with the Testing Challenges of Agile Methodologies

Quando automatizar?

Quando automatizar?

Teste Ágil, como implementar?

Afinal o que é Teste Ágil?

O que muda do Teste Tradicional para o Teste Ágil?

Como podemos implementar o Teste Ágil no nosso dia-a-dia?

Quais são as maiores dificuldades para implementar-lo?

Quais as vantagens de sua implementação?

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

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

Primeira parte

Coffee Break

Segunda parte

Considerações finais

6º Encontro Mensal da ALATS-SP