O teste baseado em risco melhora a qualidade das histórias entregues e ajuda os testadores a se tornarem parte da equipe Scrum, explicou Csaba Szökőcs, especialista em produtos da Evosoft Hungary Kft. durante a TestCon Moscou 2019, ele também explicou como adaptaram os testes clássicos baseados em riscos para se adequarem à sua implementação ágil, tornando-os parte do planejamento da sprint e da definição de pronto.
Szökőcs apresentou como apoiou as equipes para mover as atividades de teste do final das iterações para o início. Quando mudaram para o Scrum há alguns anos, a equipe de desenvolvedores não sabia exatamente como criar histórias de usuários que fossem totalmente testadas, e não sabiam o que "potencialmente entregável" significava. Estavam acostumados a lançar um ou dois releases por ano antes das alterações, junto com uma fase de "testes de sistema", também conhecido como "conserto de bugs", um processo que levava vários meses. Agora com o Scrum, as equipes tentam entregar histórias sem bugs, desta forma introduziram mais atividades de teste com as equipes recém-formadas do Scrum.
Como a equipe tinha menos experiência em testes, tentaram usar os métodos já conhecidos, como criar um design pequeno no início do sprint, implementá-lo e, quando concluído, testá-lo. Era um modelo de mini cascata dentro do sprint e tinha os mesmos problemas que o modelo cascata normal, como Szökőcs explicou:
Se encontramos um problema grande durante o teste, geralmente já era tarde demais para corrigi-lo da maneira correta, e tínhamos que conviver com as conseqüências: aceitar o bug e consertá-lo mais tarde, reduzindo o escopo da história ou introduzindo uma solução rápida com o problema de custo técnico. Nenhum destes resultados era minimamente satisfatório.
Szökőcs comentou que havia aprendido sobre testes baseados em risco em um workshop de arquitetura e pensou que poderia ser útil implantar nas equipes Scrum. Os times tentaram coletar os riscos de cada história do usuário antes de planejá-los em um sprint. Isso ajudou-os a pensar em como testar as atividades antes que a história fosse implementada e a evitar muitos problemas no lugar de serem apenas reativos aos bugs. Também envolveram os colegas testadores muito mais cedo para se beneficiar das experiências de todos os envolvidos.
Os testes baseados em riscos mudaram radicalmente como as histórias foram montadas durante o sprint, melhorando a qualidade das histórias entregues. Além disso, a mudança foi um motivador para os testadores, já que foram capazes de influenciar como as histórias foram finalmente realizadas. Muitos desses testadores agora fazem parte das equipes Scrum, disse Szökőcs.
"Estamos fazendo testes baseados em risco em algumas das equipes Scrum, não em todas; algumas equipes já testam e usam há bastante tempo, outras não estão utilizando", disse Szökőcs. Também mencionou que os times adaptaram os testes clássicos baseados em risco ao processo Scrum para que se encaixassem melhor a implementação ágil.
Szökőcs disse que normalmente testes baseados em risco são feitos por equipes de teste para encontrar os mais valiosos testes que precisam ser executados quando se tem um curto espaço de tempo para testar. Nas equipes Scrum, os testadores estão realizando um teste separado e independente, baseado em risco para quase todas as histórias de usuários; faz parte da definição de "pronto" que os riscos para a história sejam coletados e priorizados. Os times estão coletando os riscos como parte do refinamento, envolvendo alguns especialistas específicos, como por exemplo, testadores, arquitetos e proprietários dos produtos. Às vezes, os testadores também encontram alguns bugs já existentes no sistema e, às vezes, precisam alterar a história dos usuários, estendendo os critérios de aceitação com alguns cenários especiais ou dividindo cenários que são muito complicados.
Depois de coletar os riscos, dois colegas os priorizam de acordo com a probabilidade e o dano do risco, atribuindo a cada um deles um número entre 1 e 5. A multiplicação dessas notas fornecerá a exposição dos riscos. Todos os riscos com uma alta exposição devem ser tratados de alguma forma, disse Szökőcs.
Szökőcs mencionou que, um testador experiente estima a eficácia do teste de cada risco, respondendo a pergunta, "Como é fácil lidar com esse risco no escopo do teste?" Isso também é especificado com uma nota que vai de 1 a 5, em que 1 é impossível de testar e 5 é algo óbvio. Multiplicar esses números pela exposição resultará no Número de Prioridade de Teste. Uma nota mais alta indica um risco que tem um impacto maior e é fácil de testar, portanto, começamos por estes. Um número baixo indica um risco de baixo impacto que é difícil de testar, neste caso, é melhor ignorá-lo, pois não tem valor real.
A priorização ajuda a equipe a criar uma estratégia com testes valiosos visando os riscos com maior impacto, em vez de testar apenas os cenários felizes. O time pode usar as prioridades para decidir em que nível testarão um risco específico, disse Szökőcs.
InfoQ conversou com Csaba Szökőcs depois da palestra na TestCon Moscou 2019.
InfoQ: O que você aprendeu em relação a maneira como prioriza os riscos na Evosoft?
Csaba Szökőcs: Primeiro, a priorização é opcional. Se pularmos esta etapa, e simplesmente coletarmos os riscos ainda é muito valioso. Algumas equipes estão trabalhando dessa maneira e estão felizes com o resultado.
Em segundo lugar, não superestime a priorização. Geralmente, fazemos isso da seguinte maneira: encontre o menor risco e dê a nota 1, depois o maior risco e dê a nota 5. Todos os outros riscos podem ser rapidamente priorizados no meio, quando não houver tempo.
Terceiro, a prioridade do teste realmente ajuda as equipes a encontrar os testes mais valiosos para a história, e isso melhora a qualidade geral das histórias de usuários entregues.
InfoQ: Como podemos coletar os riscos?
Szökőcs: Coletamos os riscos no contexto da história do usuário respondendo à pergunta: "O que pode dar errado nesta história?".
Além disso, tentamos imaginar que o novo recurso já em funcionamento e pensamos em diferentes cenários, como será usado da maneira correta e como será mal utilizado. Nós tentamos combinar o novo recurso com outros recursos existentes, respondendo à pergunta: "Pode dar errado de alguma forma?".
Diferentes requisitos não funcionais, como desempenho, usabilidade e segurança, também podem ser verificados, "São afetados? Podem dar errado nesta história? O que pode dar errado se o sistema estiver sobrecarregado? E se o sistema de alguma forma se tornar inconsistente?".
Para encontrar riscos valiosos, não apenas cenários impossíveis, normalmente convidamos especialistas nesse domínio específico: um testador de sistema ou um arquiteto ou proprietário de produto de outras equipes. Além de ajudar nos riscos é motivacional para estes membros, porque também podem ter uma influência sobre a história antes que a equipe implemente qualquer coisa.
É importante mencionar que não estamos coletando riscos de projeto, como acontece quando alguém do time fica enfermo ou quando ficamos sem orçamento. Além disso, não estamos coletando casos de teste. É possível que possamos cobrir vários riscos com apenas um caso de teste ou precisamos de vários testes para cobrir apenas um risco. Os casos de teste são derivados dos riscos mais importantes.
InfoQ: Quais são as dicas para fazer testes baseados em riscos?
Szökőcs: Experimente. Comece simples e melhore passo a passo.
No começo, basta coletar alguns riscos para cada história de usuário como parte do processo de refinamento e documentá-los em uma lista simples. Isso ajudará a equipe a sentir os pontos de dor da história e se concentrar neles.
Depois, tente convidar alguns colegas experientes para essa reunião, enquanto você coleta os riscos.
Se já estiver se acostumando com o processo, tente incluir a priorização. Veja se isso ajuda a equipe a definir casos de teste melhores ou até mesmo, mais valiosos.
Não torne a reunião de coleta de risco obrigatória ou muito longa, a equipe pode estar sobrecarregada com reuniões, então menos reuniões, é melhor. Faça isso somente com os membros da equipe que estão interessados e deixe os outros pularem essa parte, afinal poderão verificar os resultados mais tarde.
E finalmente, mantenha tudo muito simples. O maior valor está na discussão sobre os riscos, nunca se esqueça disso.