Agilidade em Testes de Software – O que é ser Ágil? Parte 03 de 03

166098897

Olá Pessoal, concluindo esse tema Agilidade em Testes de Software, escrevo o último post deixando alguns links de materiais, artigos e ferramentas que podem auxiliar nesse processo de testes ágeis.

Quero evitar ficar entrando em teorias, opiniões e conceitos e ir diretamente para a prática que acredito ser mais produtivo.

Mas antes, apenas relembrando e provocando:

Perguntas para refletir

– Seu problema na entrega de um produto é realmente seu processo de desenvolvimento?

– Será que o retrabalho, bugs constantes, prazos estourados, não estão vinculados a falta de conhecimento técnico?

– Será que o retrabalho, bugs constantes, prazos estourados, não estão vinculados a falta de entendimento e comunicação?

– Será que a mudança para uma metodologia ágil irá resolver seus problemas de comunicação, conhecimento de negócio, compromisso do time e conhecimento técnico (usar o melhor das ferramentas disponíveis)?

– Ser ágil é se ter um processo de desenvolvimento SCRUM ou similar?

– Posso ser ágil usando CMMI para desenvolvimento ou outro processo que não SCRUM, XP ou similar?

– Eu ter um Gerente de Projeto tira meu status de ágil?

– Se eu não usar cartas de baralho para pontuar meu esforço, não sou ágil?

– O que é ser ágil? É um processo, é um conceito é uma ferramenta?

– ALM é sinônimo de ágil? Se minha metodologia de desenvolvimento não for AGIL, não estou praticando ALM?

– Se ALM é sinônimo de ágil, por que o TFS tem template CMMI para Desenvolvimento?

– Se eu diminuir uma entrega de um Plano de Testes de 10 dias para 04 dias, usando o mesmo processo, porém agregando ferramentas e técnicas de apoio, estou sendo ágil?

– Se eu tenho um processo baseado em CMMI onde a entrega é um Plano de Testes é de 10 dias, e substituo para um processo SCRUM que leva 10 dias também, estou ágil por que mudei de processo?

– Se eu adaptar meu SCRUM ele ainda é SCRUM?

– Ser ágil é só SCRUM?

– Se eu seguir um processo, não sou ágil?

Acabando com a provocação e definindo o conceito de Ágil para Desenvolvimento e consequentemente para o Teste Ágil

Se quando falamos de métodos ágeis, partimos do pré-suposto que estamos falando nos principios do Manifesto Ágil, não importa a metodologia, ferramenta, e sim que você tenha em mente e siga esses pilares abaixo tirados do Manifesto:

– Nossa maior prioridade é satisfazer o cliente, através da entrega contínua de software de valor;

– Aceitar mudanças de requisitos (processos ágeis se adaptam a mudanças, para que o cliente possa tirar vantagens competitivas);

– Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos;

– Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto;

– Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho;

– O método mais eficiente e eficaz de transmitir informações para um time de desenvolvimento é através de uma conversa cara a cara;

– Software funcional é a medida primária de progresso;

– Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e clientes, devem ser capazes de manter indefinidamente, passos constantes;

– Contínua atenção à excelência técnica e bom design, aumenta a agilidade;

– Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito;

As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis, motivados e confiantes;

Em intervalos regulares, a equipe reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Importante salientar que seu time deverá estar bem alinhado com os seguintes pontos também:

– Possuir muito bem definido o critério de pronto;

– Executar periodicamente refactory de seu código, inclusive dos seus testes, buscando diminuir a complexidade, melhorando o desempenho e qualidade;

– Realizar as reuniões de retrospectiva;

– Casos de Testes de Aceitação;

– Importante que sempre se trabalhe com teste unitário;

– É necessário se avaliar e sempre que possível e que valha a pena ter teste funcional automatizado, principalmente quando se entrar na esfera de regressão;

– Sair um pouco da esfera do processo e do time de desenvolvimento (programadores, testadores, analistas, etc.) e entrar no conceito DevOps e trazer agilidade tanto no momento do desenvolvimento bem como na implantação e manutenção desse aplicativo em produção.

– Integração contínua (Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente).

Artigos Conceituais sobre Testes Ágeis e seus Conceitos

No conceito de teste ágil, o foco muda de:

“Encontrar os erros, garantir o a implementação dos requisitos e quebrar o software

Para

“Incluir a qualidade no software no processo de desenvolvimento”

O conceito dos testes ágeis está muito além de processos e ferramentas, pois você poderá usar qualquer processo que desejar e ferramenta que melhor lhe servir ao propósito. Mas é importante salientar que os Testes Ágeis e baseiam em alguns pilares indo ao encontro do Manifesto Ágil:

– Testes fazem parte desde o início do desenvolvimento, não mais como uma fase após a conclusão da programação;

– É uma atividade colaborativa, não há mais silos “time de programadores” e “time de testadores” os programadores também testam, como outros membros do time;

– No teste o papel do cliente é fundamental no processo, pois ele irá testar o produto também, sob perspectiva de funcionalidade. Aí pode vir a pergunta: – Alan, mas meu desenvolvimento não é exclusivo para um cliente como um e-Commerce e sim para o mercado, como testar dessa forma?

Há diversas formas, nesse caso, normalmente o demandante é o time de Produtos (Analistas) ou seja, eles são seu cliente e devem participar do processo. Deverão escrever os Testes de Aceitação e participar da execução (lembra que perguntei sobre o conhecimento técnico, pois é…).

– Os programadores deverão testar sob a perspectiva de código-fonte, avaliando método por método. Ai entra o famoso e tão “temido” Teste Unitário.

– Os testes podem sim ser manuais, mas sempre que possível, observar o custo de tempo de um teste e a possibilidade de transformá-lo em um teste automatizado (novamente, conhecimento) e gerir esse testes como parte integrante do seu código. Lembrando que essa automação, pode partir do time de programadores bem como do time de testadores.

– Como estamos trabalhando em um formato mais Ágil, devemos sempre estar envolvendo todo o time na definição do escopo. No caso de um Planejamento de Sprint, o Testador (pode ser o programador, analista de produtos, cliente final, etc.) deve sempre estar participando para definir itens como:

– Entender as histórias de usuários e critérios de aceitação para a formulação dos casos de testes;

– Alinhar a estimativa de trabalho com o time, de forma geral, não apenas estimativa de testes mas sim de entrega. Cuidado com as famosas “gorduras” na entrega, somar BUGs ainda não pegos, etc.;

– Discutir o design de desenvolvimento do aplicativo;

– Alinhar a definição de pronto (Done) em conjunto com todo o time;

Dos artigos que já li destaco:

Testes Ágeis – pelo Cristiano Caetano

Artigos Técnicos sobre Testes Ágeis

Tecnicamente falando, em times ágeis, o testador sai um pouco da “zona de testes” e entra mais a fundo desde o início do projeto, começando a trabalhar forte em análise, testes de aceitação, conhecimento do negócio, automação dos testes, etc.

Bem como o teste propriamente dito, passa a fazer parte da programação, onde programadores começam a utilizar de técnicas de testes unitários como até a utilização de técnicas de desenvolvimento chamadas TDD e BDD, quando possível. Tanto os testes unitários, como o uso de técnicas de TDD e BDD são um pouco complexos, pois adicionam mais tempo no inicio da programação, bem como fica um pouco complicado em códigos legados e as vezes com uma estrutura complexa.

O ideal inicialmente no meu ponto de vista é trabalhar para que o time seja treinado tecnicamente em testes unitários, TDD e BDD e aplique sempre que possível em novos desenvolvimentos, e também trabalhe forte em técnicas alternativas para a questão dos códigos legados.

Para mim, o que mais irá valer nesse período é a dedicação do time em aprender, se esforçar em utilizar e apoio da empresa dando ferramentas, cursos e incentivos.

O que acho complicado é o time esperar que esse apoio também venha do cliente ou mercado que está esperando o produto, nova versão, correção, etc. Será uma ilusão achar que os prazos, que normalmente são estabelecidos pelo mercado, sejam alterados por que o time está apredendo uma nova técnica. Você e sua empresa até pode trabalhar assim, mas enquanto isso, seu concorrente tomando seu espaço.

Uso eu mesmo como exemplo em um projeto. Quando precisei implantar um novo sistema, tinha um prazo já determinado pelo mercado, inclusive conforme o tempo passava a empresa tinha prejuízo mensal.

Eu tinha um conhecimento para implantar tal solução, porém sabia que no futuro aquilo teria uma manutenção maior, e havia como eu executar esse projeto de uma melhor forma com novas tecnologias, mas isso teria um preço de estudo da minha parte muito grande e minhas horas de trabalho iriam se estender, porém sabia que se eu fizesse isso nesse dado momento, colheria os frutos durante anos, pois a tecnologia iria se manter sozinha.

Então apostei e acabei tendo resultados extremamente satisfatórios, onde até hoje colho os frutos dessa decisão de me sacrificar estudando, usando as melhores práticas, além do meu horário de trabalho durante alguns meses, sem sacrificar o prazo de entrega.

O que eu quero dizer é que para que uma nova etapa funcione, além do apoio da empresa, o principal será a dedicação e compromisso dos envolvidos muito além das quatro paredes da empresa. São estudos, tentativa e erro e assertividade.

Dentre os artigos técnicos disponíveis para a execução de Testes Ágeis, eu destaco os temas:

DevOps

Testes Unitários

Automação de Testes Funcionais

Ferramentas para Testes Ágeis

Também há diversas ferramentas para auxiliar seus testes ágeis. Eu particularmente gosto de utilizar as ferramentas da Microsoft, que são as tecnologias que trabalho atualmente e também são bem acessíveis, indo de planos gratuitos até os pagos pelo uso com valores bem atraentes. Há diversas outras, algumas que conheço e outras que são dicas de experts.

– Suites Microsoft

Test Tools

Essa suíte de ferramentas, possui diversas features muito úteis como o Application Insights, Test Manager, entre

Microsoft Visual Studio Online

– Automação de Testes

Fitnesse: (http://fitnesse.org/);
Green Pepper: (http://www.greenpeppersoftware.com);
StoryTestIQ: (http://storytestiq.solutionsiq.com);
Robot Framework: (http://code.google.com/p/robotframework/);

– Testes Unitários

JUnit: (http://www.junit.org/);
NUnit: (http://www.nunit.org/);
DUnit: (http://dunit.sourceforge.net/);
CPPTest: (http://cpptest.sourceforge.net/);

Deixe um comentário

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

Logotipo do WordPress.com

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

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s