Por que ser analista de testes em um time ágil é diferente?

Uma das maiores diferenças do desenvolvimento ágil em relação ao desenvolvimento tradicional é a abordagem de time. No desenvolvimento ágil, não são apenas os analistas de testes que se sentem responsáveis pela qualidade, todos os membros do time devem priorizar produzir software de alta qualidade em um período de tempo que maximiza o seu valor para o negócio. Todos os membros de um time ágil ficam infectados pelo teste, e isso inclui desenvolver testes a partir do nível de unidade [Schwaber e Sutherland 2013].

Enquanto no desenvolvimento utilizando uma metodologia tradicional, os testes são realizados por uma equipe de testes independente, no ágil, os analistas de testes devem trabalhar com o time do projeto. Logo, os analistas de testes devem ser membros do time de desenvolvimento e, as tarefas de testes devem ser tratadas com a mesma atenção que outras tarefas.

Times ágeis são geralmente considerados multifuncionais, pois possuem membros de diversas de todas áreas de conhecimento. A diferença entre uma equipe multifuncional tradicional e um time ágil é a abordagem de time. No ágil, os membros não estão apenas representando suas atribuições, mas estão se tornando parte do time durante o tempo que o time existe, conforme o que está sendo demonstrado na imagem a seguir, adaptada de [Crispin e Gregory 2009].

AgilexTrad

Um analista de testes, em um time ágil, pode ajudar o time a resolver problemas, seja fornecendo maneiras de reduzir o tempo de resposta de alterações ou auxiliando na priorização de não conformidades [Crispin e Gregory 2009].

Teoria a parte, como analista de testes de times ágeis (que  utilizam Scrum), eu já participei das seguintes atividades:

  • Realizar testes exploratórios manuais;
  • Escrever testes automatizados;
  • Auxiliar na documentação de negócio;
  • Fazer testes manuais para verificar funcionalidades;
  • Participar das reuniões do time;
  • Escrever documentação funcional.

Isso mostra que em um contexto ágil nós, analistas de testes, temos oportunidades para explorar skills técnicos e de negócio, tirando a monotonia do dia-a-dia 🙂 . Mas, trabalhar em contexto ágil também requer aceitar de mudanças e pensamento coletivo (focando no time). Por isso acredito que bons Agile Testers são aqueles que sabem compreender o que o time precisa e que atuam como promotores da qualidade, incentivando boas práticas, por exemplo.

Se você trabalha em time ágil, sinta-se a vontade para comentar quais são suas atividades no dia-a-dia e o que você considera um bom Agile Testers.

Anúncios

Teste tradicional x Teste ágil: de que lado você está?

A figura a seguir, adaptada do livro “Agile Testing: a practical guide for testers e agile teams”,  ajuda a compreender as diferenças entre testes no desenvolvimento tradicional, usando como exemplo a metodologia Cascata, e testes no desenvolvimento ágil:

Tradicional X Ágil

No diagrama de abordagem gradual, é evidente que o teste acontece no final, antes da publicação. O diagrama é idealista, porque dá a impressão de que há tanto tempo para o teste como existe para a codificação, o que em muitos projetos, não é a realidade. O teste pode ser prejudicado porque a codificação leva mais tempo do que o esperado, e porque as equipes entregam um projeto pronto somente no final. É comum no desenvolvimento tradicional, os testadores receberem uma versão com todas as alterações do projeto e a partir de aí começarem suas verificações.

Por outro lado, o Ágil é iterativo e incremental, portanto os testadores podem testar cada incremento de codificação, assim que é desenvolvido. O time analisa, desenvolve e testa uma funcionalidade ou parte dela apenas, e segue fazendo isso até que a solicitação do cliente seja atendida. O time deve terminar a codificação e testes no mesmo momento, porque uma funcionalidade não é “pronta” até que tenha sido testada (assim espero 😉 ).

É importante ressaltar que independentemente de como um projeto ágil é iniciado, é necessário que todo time , e isso inclui o testador ou Analista de Testes, tenha entendimento:

  • da visão deste projeto
  • das principais funcionalidades
  • do problema que este projeto resolve
  • da necessidade do cliente

No desenvolvimento tradicional, é comum que o Analista de Testes crie um plano de testes e  elabore a estratégias de testes baseando-se em um documento de requisitos que foram criados por analistas de negócios antes sequer de alguém ter pensado em escrever uma linha de código.

Por outro lado, no Ágil, um membro do time terá que pensar nos testes que ilustram os requisitos antes da codificação começar, o que requer colaboração entre o time e o PO ou cliente. Isso não quer dizer que no desenvolvimento Ágil não exista estratégias de testes. A questão é que no ágil pensar em testes passa a ser uma responsabilidade de todos os membros do time. E ainda complemento, um time ágil precisa ter uma estratégia de testes.

Agile Testing 1: Conceito

Em projetos que utilizam métodos ágeis é preciso ter um ambiente de desenvolvimento que favoreça o feedback contínuo, ou seja, que o impacto de cada alteração seja percebido instantaneamente por toda equipe.

Para que isso seja possível é recomendado que este ambiente possuísse integração contínua, onde serão executados todos os testes desenvolvidos do projeto. Com os resultados destes testes o time pode detectar em pouco tempo se a funcionalidade desenvolvida ainda precisa ser corrigida ou se gerou não conformidades em outras funcionalidades [Duval 2007].

Para que garantir que os testes sejam realizados da forma e na proporAgileTestingBookção corretas, foi criado o conceito Agile Testing:

Agile Testing consiste na aplicação de um conjunto de tipos e técnicas de testes, jáconhecidas pelo mercado, combinadas de forma que possam se complementar ao máximo, visando atender ao manifesto ágil.

O principal objetivo é combinar as técnicas de testes de software para que seja possível aperfeiçoar o tempo de execução de testes e garantir a maior cobertura de testes [Crispin e Gregory 2009].


Referências:

  • Crispin, L. (2009) “Using the Agile Testing Quadrants” http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/, Março.
  • Crispin, L. e Gregory, J. (2009), Agile Testing: a practical guide for testers e agile teams, 1ª Edição.
  • Duval, P. M. (2007), Continuous Integration: Improving Software Quality e Reducing Risk, 7ª Edição.

 

Por que devemos testar software?

Imagem

A regra 10 de Mayers defende que: “o custo de correção dos defeitos cresce e exponencialmente à medida que o processo de desenvolvimento avança dentro do ciclo de vida do sistema”. Isto mostra o quanto é importante aplicar técnicas de testes e validação de software desde a fase de requisitos, pois um requisito mal definido, por exemplo, se for identificado antes da codificação não causará retrabalho na fase de codificação, mas poderá causar na fase de análise. Se for identificado ainda na análise, não causará retrabalho na fase de codificação, e assim por diante. Quanto antes um defeito for identificado e corrigido menor será o tamanho da correção, seu tempo de realização e o impacto das alterações, assim como a  probabilidade da alteração ocasionar novos erros.

Além de Myers que projeta um crescimento exponencial do custo de correção de defeitos, numa proporção de 10x um estudo de Rex Black, baseado nas suas experiências pessoais como consultor, afirma que o custo do defeito seria 10 quando identificado nos testes de desenvolvimento, 100 quando identificados pela equipe de teste e 1000 quando em produção. Além disso Barry Boehm, no seu livro Software Engineering publicado em 1976, afirma que o custo de um erro encontrado nos requisitos é X, caso seja encontrado na fase de teste 10X e se encontrado em produção 100X.

Análise comparativa JUnit vs TestNG

O teste de software é uma das principais atividades realizadas para melhorar a qualidade de um produto em desenvolvimento. Seu principal objetivo é revelar a presença de erros no software o mais cedo possível no ciclo de desenvolvimento de software, buscando minimizar o custo da correção dos mesmos. Esta atividade tem apresentado progressivamente um maior grau de abrangência e de complexidade dentro do processo de desenvolvimento.

Embora o teste de software seja uma atividade bastante complexa, geralmente ela não é realizada de forma sistemática devido a uma série de fatores como limitações de tempo, recursos e qualificação técnica dos envolvidos. Outros agravantes para a realização dessa atividade são a alta complexidade dos sistemas sendo atualmente desenvolvidos e a constante necessidade de sua rápida evolução.

A automação de parte do teste de software tem sido vista como a principal medida para melhorar a eficiência dessa atividade, e várias soluções têm sido propostas para esta finalidade. Têm-se disponíveis hoje frameworks e ferramentas com diferentes funções e nível de abrangência, que visam facilitar desde o desenvolvimento de testes unitários ate simulações de carga e stress.

Sem duvida um dos frameworks de maior popularidade no momento com suporte a testes unitários para aplicativos escritos na linguagem de programação Java é o JUnit, desenvolvido por Kent Beck e Erich Gamma; Sendo que, em sua grande parte, é fácil de ser utilizado, razão a qual de sua popularidade.

Esse framework facilita a criação de código para a automação de testes com apresentação dos resultados (testes unitários). Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão.

Entre as vantagens do JUnit pode-se citar:

  • Permite a criação rápida de código de teste possibilitando um aumento na qualidade do desenvolvimento e teste;
  • Amplamente utilizado pelos desenvolvedores da comunidade código-aberto, possuindo um grande número de exemplos;
  • Uma vez escritos, os testes são executados rapidamente sem que, para isso, seja interrompido o processo de desenvolvimento;
  • JUnit checa os resultados dos testes e fornece uma resposta imediata;

Em contrapartida, surgiu há algum tempo um framework inspirado no JUnit, mas introduzindo algumas funcionalidades novas – o TestNG. Prometendo mais flexibilidade na escrita de testes de aplicativos escritos na linguagem de programação Java, o TestNG além de ser projetado para testes unitários, também cobre testes de integração e testes funcionais.

Algumas características relevantes do TestNG são:

  • Configuração flexível do teste.
  • Apresenta-se melhor para um grande número de testes.
  • Sustentação para testar data-driven (com @DataProvider).
  • Sustentação para parâmetros.
  • Permite a distribuição dos testes em máquinas slave.

Além disso, TestNG tem um diferencial elegante onde você pode marcar testes como um grupo específico e, em seguida, facilmente executar todos os testes de um grupo específico ou excluir testes de um determinado grupo. Assim, você pode marcar testes executados lentamente como no grupo “slow” e, em seguida, ignorá-los quando quiser resultados rápidos. Uma sugestão de sua documentação é marcar alguns subconjuntos como “check-in” de testes que devem ser executados sempre que você verificar novos arquivos. Isso não existe no JUnit.

Outra funcionalidade disponibilizada pelo TestNG é a migração de testes escritos no JUnit através de classes específicas sem demandar esforços muito dispendiosos.

Falando sobre FISL 12

Durante o período de  29 de junho à 02 de julho estive participando do FISL (Fórum Internacional de Software Livre) que ocorreu no centro de eventos da PUC em Porto Alegre. Neste artigo, bem informal diga-se de passagem,  gostaria de destacar minha opinião sobre o evento.

Primeiramente, o FISL é o maior evento de Software Livre.  Sua proposta é a  tecnologia, inovação, inclusão, novas idéias, novos paradigmas que podem ser construídas a partir de SW livres, e isso vai desde Sistemas Operacionais a Frameworks de desenvolvimento, SW leitores de telas , entre outros.

Quem acompanhou a grade de palestras deste ano notou um número significativo de palestras referentes a inclusão digital e informática na educação, gradativamente maior que ademais anos. Comprovando assim que o evento aborda muito mais do que temas técnicos e especifico de TI,  mas também se preocupa com a educação, a sociedade de forma geral além de estar seguindo a tendência de preocupação com temas de inclusão digital.

Acho indispensável para profissionais que buscam conhecimento a participação neste tipo de evento, não só pessoas relacionadas à TI , mas sim de outras áreas que se envolvem e/ou são envolvidas pela tecnologia, exemplo disso na caravana que participei, várias pessoas eram da área de educação – ligada diretamente com tecnologia.

Agora falando do meu aproveitamento em relação ao evento, vou destacar aqui algumas palestras das quais participei que achei excelentes:

– A palestra que fechou o evento,” Happy Birthday, Linux!” de Jon MadDog Hall, sem dúvida inesquecível, foi divertida, e fez um relato sobre a história do SW livre, com algumas previsões maquiavélicas sobre o futuro mas, no fim das contas “Software livre trará a paz mundial”.

– A palestra “A Estratégia Nacional da Ciência, Tecnologia e Inovação: Desafios e Perspectivas” do ministro da Ciência e Tecnologia, Aloizio Mercadante que defendeu a criação de uma empresa pública de inovação e P&D para a indústria, a qual chamou de Embrapi fazendo alusão à Embrapa – vinculada ao Ministério da Agricultura. A realização de Olimpíadas de TI, possivelmente em 2012, e a nova política do Ministério para inclusão digital e ensino profissional também foram abordados. (Promessas ou não, ainda há esperança 🙂 )

– “Refatoração de Código com Capitão Nascimento” ministrada por Eduardo Bregaida, que mostrou como refazer seu código de maneira clara utilizando práticas TDD além de divertir com comparações do personagem Capitão Nascimento. “Não vai subir ninguém! Vai ficar todo mundo ai testando, não vai subir ninguém!”

No geral, destaco todas as de Android e as Refactoring aplicando práticas TDD.

Entretanto o que mais me motiva a participar do FISL, que levei de melhor pra minha bagagem profissional são as novas idéias e sim, sai de lá cheia delas, acho que esse é o ponto principal do evento, estimular a inovação.