Cada dia mais ouvimos falar sobre a agilidade e vemos que as metodologias ágeis estão sendo aplicadas nas mais diversas áreas além do desenvolvimento de software hoje vemos áreas como RH, Marketing e até no mercado de publicidade entrando na onda ágil. E diante deste contexto diversos profissionais precisaram se adaptar e os testadores não foram uma exceção.
O Agile Testing é uma forma de atuar em contextos ágeis que começou a se difundir pela comunidade de testes por volta de 2002 com publicações de Bret Pettichord, mas só se consolidou em 2009 com a publicação do livro Agile Testing de LisaCrispin e da Janete Gregory.
A evolução do QA
Antes de começar a falar sobre testes ágeis, apresento um que modelo que mostra como o trabalho de um QA tem evoluído ao longo do tempo, esse modelo foi proposto pelo Julio de Lima em uma palestra no Scrum Day 2020 e explica o passado presente e o possível futuro de uma pessoa que atua como QA. O intuito deste conteúdo é proporcionar o entendimento do modelo que se está atuando para saber o que é esperado de você como pessoa QA.
1.0 - Cascata: nesse modelo temos um time de pessoas que atuam nesse modelo em geral são chamadas de testadores ou analista de testes. Nesse contexto de trabalho, as pessoas testadoras são responsáveis por testar o software quando o time de desenvolvimento finaliza a fase de codificação. Neste modelo o testador tem como principais atividades: revisar o plano de testes, criar e executar casos de teste, reportar inconsistências e gerar relatórios com métricas de teste no projeto.
1.5 - Ágil Imaturo: neste modelo de atuação temos já temos um time multifuncional, o que é característica de times ágeis, porém nesse caso o testador acaba atuando como se estivesse em uma metodologia cascata onde de maneira reativa o QA espera que os desenvolvedores concluam a codificação para que eles finalmente atuem com testes.
2.0 - Ágil em maturação: já no modelo ágil em maturação o QA auxilia em todo o desenvolvimento do produto compartilhando boas práticas, fazendo a mentoria do time com relação a testes e claro executando testes específicos e até implementando uma estratégia de testes.
3.0 - Ágil: após mentorar o time com relação ao a testes como é feito no modelo 2.0 é ideal que com o tempo os desenvolvedores ganhem experiência com testes e que eles passem a mentorar o QA a desenvolver, assim todas as pessoas do time acabam ganhando experiência tanto em desenvolvimento quanto em testes. Muitas empresas já buscam profissionais de QA com perfil em desenvolvimento, esse perfil tem sido chamado de Software Engineer in Test.
O mindset do Agile Testing
Como já deve ter sido possível perceber quando estamos em um ambiente ágil atuamos de maneira diferente de quando atuamos em um modelo tradicional. E existem características que devemos considerar ao atuar neste contexto sendo essas elas:
Trabalhe além das competências técnicas: soft-skills são ao habilidades requisitadas em diversas áreas atualmente, mas em especial quando trabalhamos em um contexto ágil seja QA ou não devemos trabalhar algumas competências como:
Resiliência: como o próprio manifesto ágil diz "responder a mudanças, mais que seguir um plano", quando atuamos em um contexto ágil nosso projeto pode sofrer diversas mudanças e elas podem ser relacionadas ao produto ou as tecnologias usadas, mas independente da mudança é preciso saber se adaptar.
Comunicação: o manifesto ágil também cita a importância da colaboração e das interações. Sendo uma pessoa QA, frequentemente interagimos com nossos pares, steakeholders, clientes e etc. E para que essas interações fluam bem é importante saber se comunicar da maneira mais assertiva possível, pois falhas de comunicação podem ter grandes impactos negativos.
Inteligência emocional: trabalhar com tecnologia em geral, exige muito essa competência, pois frequentemente podemos nos encontrar em momentos críticos onde há a necessidade de tomada de decisão, portanto saber administrar suas emoções, mesmo em meio a problemas e encontrar equilíbrio entre área pessoal e profissional é importante.
Resolução de problemas: por fim e não menos importante conseguir entender um problema, para avaliar e propor uma solução adequada. Constantemente, somos expostos a problemas complexos que exigem uma tomada de decisão e saber como fazer as melhores escolhas ou até saber a quem recorrer para nos auxiliar é uma habilidade muito importante atualmente.
Busca por feedbacks frequentes: a melhoria continua pode ser obtida através de feedbacks que podem acontecer em três áreas distintas, sendo elas:
- Pessoal: dar e receber feedback a respeito do seu trabalho e de características pessoais podem ajudar na evolução pessoal.
- Time: nesse caso já temos métricas sobre a atuação do time que podemos usar como base para avaliar pontos fortes e a melhorar
- Aplicação: aqui os testes marcam forte presença, pois eles podem gerar feedback rápido da saúde da aplicação, porém eles não são as únicas formas de se obter feedback da aplicação, também podemos usar diversas ferramentas de monitoramento e até o bom feedback do usuário.
Protagonismo em fases todas da especificação a entrega: Quando atuamos em um ambiente ágil o QA deixa de ser reativo como em metodologias sequenciais e passa a ser uma pessoa ativa que ao invés de atuar em uma única fase do projeto, participa desde o inicio das do projeto tentando entender melhor o produto ou cliente, pois assim fica mais fácil de saber o que é esperado com para que o produto seja entregue com qualidade.
Abordagem do time todo: em geral uma squad trata-se de um time multifuncional, composto por pessoas com diferentes habilidades. Embora dentro desse time encontramos diferentes perfis de profissionais todos esses profissionais acabam sendo responsáveis por entregar o produto final e essa entrega deve ter qualidade e todos do time devem se responsabilizar por isso, e isso inclui os testes de software que deve ter sua responsabilidade compartilhada com todo o time.
Foco na solução: desenvolvimento de software é uma atividade complexa e para que essas atividades complexas não se tornem um mostro de sete cabeças, o ideal é que antes de partir para a solução entendêssemos o problema, pois assim fica muito mais fácil focar na solução e desenvolver algo que será útil ao nosso usuário. Sendo mais especifico com pessoas de QA, antes de sair desenvolvendo automações entenda seu produto e conheça seu usuário.
Mitigar e prevenir riscos: em metodologias ágeis geralmente temos um curto espaço de tempo entre entre o planejamento e as entregas. Com isso muitas vezes um QA pode desempenhar muito bem levantando riscos junto ao time para poder mitigar ou os prevenir para minimizar os impactos que o produto pode sofrer.
O manifesto do teste
Por volta de 2014, Sam Laing e Karen Greaves inspirados pelo manifesto ágil criaram o manifesto do teste, que é uma forma de resumir de maneira rápida como deve ser a mentalidade quando atuamos com testes ágeis. O manifesto segue os seguintes valores:
- Testar todas as etapas versus testar no final
- Previnir bugs versus encontrar bugs
- Testar o entendimento versus testar a funcionalidade
- Construir o melhor sistema versus quebrar o sistema
- Time Responsável pela qualidade versus responsabilidade dos testadores
Princípios de teste
Por volta dos anos 2000 Elizabeth Hendrickson, fez uma palestra que acabou servindo de base para a consolidação dos testes ágeis, onde ela descrevia nove princípios de teste de software que formam a base de como os testes devem acontecer em times ágeis.
1. Testes movem o projeto
Atualmente, o termo Shift-Left tem sido muito comentado e ele reflete justamente esse principio, pois esse termo se refere que ao invés dos testes ocorrerem só nos estágios finais, as atividades de testes passam a ocorrer mais cedo, e perduram durante todo o ciclo de vida, por isso do nome shift-left, pois dá a ideia que testando desde o inicio acabamos testando da esquerda para a direita.
2. Testes não são só uma fase
Os testes não devem ser só uma fase como em metodologias sequenciais. Em contextos ágeis os testes devem ser executados continuamente, pois é necessário adotar uma estratégia de testes que permita testar desde o inicio, e isso foi pode ser feito por exemplo adotando técnicas de para executar bons testes unitários ou testando a aplicação em camadas.
3. Todos testam
Em contextos ágeis, todas as pessoas do time são responsáveis por entregar um produto de qualidade e consequentemente por testar esse produto. Nesse momento, você pode acabar questionando "E o QA faz o que se todos são responsáveis pela qualidade?". Nesse caso o QA passa a ser a pessoa que é guardiã a da qualidade e que compartilha conhecimento de testes com o time e executa testes pontuais ou mais complexos.
4. Ciclos curtos de feedback
Quando aplicamos testes continuamente no nosso projeto e principalmente quando os testes são automatizados, frequentemente devemos executar esses testes e essas execuções são uma forma de prover feedback a rápido a respeito da aplicação e a partir desses feedbacks é possível agir de maneira rápida e assertiva, caso algum problema seja detectado.
5. Mantenha o código limpo
Usar boas práticas de programação, refatorar código sempre que necessário, fazer code review, usar linters, definir um padrão de programação ou até parear com alguma outro desenvolvedor são formas de garantir que o time esteja desenvolvendo um bom código.
6. Documente o necessário
Muitas empresas que iniciam no uso de metodologias ágeis acabam deixando de lado a escrita de documentações acreditando que elas não sejam mais necessárias, porém isso é um grande equivoco, pois a documentação ainda é importante, no entanto devemos documentar apenas o que for mais relevante para o time se localizar nas tarefas a desenvolver, e também o que for importante para o cliente após a entrega da aplicação.
E com relação a testes, use apenas os artefatos que julgar necessário de acordo com o momento que está no projeto alguns exemplos de documentações a ser usadas pode ser:
- Chapter de testes exploratórios
- Mapas mentais com as funcionalidades em testes
- Evidencias de teste em vídeo, gif o fotos
- Read me de como executar as automações
- Relatórios de execução de automação
7. Testes são exemplos
Sabe quando você não entende algo e acaba pedindo um exemplo? É esse exemplo serve para que você entenda a expectativa da outra pessoa com relação a algo. Quando pensamos em testes estamos fazendo justamente isso, avaliando se o produto que estamos desenvolvendo está atendendo a expectativa do nosso cliente e uma das formas de conseguir esse alinhamento é através do uso de técnicas como: BDD, ATDD, ou SBE que são formas de entender a necessidade do cliente já fazendo o alinhamento com o que deve ser desenvolvido e testado.
8. Testes fazem parte do DoD
Na definição de pronto devemos listar, todos os testes que deverão ser contemplados nos stories a serem desenvolvidos. Esses testes devem ser definidos pelo time e podem ser definidos no momento que o time faz a sua estratégia de testes.
Algo que pode ocorrer é a necessidades de testes específicos, por exemplo um teste de acessibilidade em alguma área da aplicação, nesses casos o ideal é que esses cenários sejam descritos no critério de aceite.
9. Desenvolvimento orientado a testes
Este nono principio pode facilmente nos lembrar do TDD, onde o desenvolvimento começa a partir dos testes e não o contrário como ainda ocorre bastante. No entanto o desenvolvimento orientado a testes vai muito além disso, pois quando definimos os requisitos já pensando nos testes como sugere o principio sete acabamos sendo mais assertivos no que estamos construindo e realizando uma entrega de maior qualidade.
Referencias:
http://www.althority.com/agile_testing_overview/
https://medium.com/revista-tspi/descubra-o-que-%C3%A9-shift-left-testing-b67116b79a0c
Top comments (0)