Scrum menos plano de teste é igual a POC com esteróides.
Atualmente, a maioria dos projetos bem-sucedidos começa com uma Prova de Conceito (POC), uma avaliação relativamente pequena de uma ideia, na qual a tecnologia e o pacote de recursos escolhidos serão verificados primeiro, avaliados quanto ao impacto potencial nos usuários de negócios e, depois de comprovados digno de investimento, uma equipe de projeto de tamanho completo é designada para projetar e entregar o produto com todos os recursos e implantá-lo na produção.
Este é o caso perfeito para uma equipe Scrum. A equipe pode desenvolver rapidamente o protótipo, adicionando novos recursos substanciais a cada sprint, enquanto os usuários de negócios podem observar em tempo real o progresso rápido e como a ideia é construída do zero em apenas 10 sprints. Deixa uma forte impressão (que é o principal objetivo do POC de qualquer maneira), mas também tem uma propriedade significativa – atividades de teste mínimas ou nenhuma, e até mesmo pensar sobre o processo de teste seria uma piada.
Não é uma atividade divertida dentro de um time Scrum, e as pessoas vão gostar mais da ideia de desenvolver sem processos por perto para atrasá-los. Isso é basicamente o que qualquer atividade de teste fará implicitamente. E quem quer lentidão desnecessária durante o tempo que precisamos para impressionar mais o usuário final?
O estado que acontece se a equipe do projeto continuar da mesma maneira após o término do período POC é algo que costumo chamar de POC on steroids – um sistema de produção crescendo em tamanho e recursos, mas ainda se comportando como um POC – um aspirante a produto completo com defeitos ocultos e casos de canto inexplorados, esperando apenas por um acidente sério.
Mas antes de se converter lá, a equipe terá mais dificuldade de sprint a sprint para acompanhar os lançamentos estáveis, pois corrigir os problemas contínuos se tornará apenas mais complexo.
Aqui estão algumas técnicas que provaram funcionar quando eu estava lidando com problemas semelhantes e que acredito que podem ser nomeadas como melhores práticas para implementar processos de teste sólidos, ainda sem sobrecarregar muito o progresso do desenvolvimento – porque é para isso que todos queremos ser uma equipe Scrum.
últimas postagens
Distribua a dor
Onde mais devemos começar ao lidar com incômodos desnecessários do que dividir a dor :).
E o que quero dizer com isso é criar um plano que exigirá uma pequena atividade adicional dos desenvolvedores aqui e ali, mas que contribuirá muito para o objetivo comum ao longo do tempo, de forma incremental, mas consistente.
#1. Desenvolva código de teste de unidade para cada parte criada do novo código
Se você conseguir convencer suas equipes scrum a adicionar em sua cláusula Definição de Feito o desenvolvimento de testes de unidade para cada novo código criado dentro do sprint, então, de uma perspectiva de longo prazo, isso será uma grande conquista.
As razões são bastante óbvias:
Isso forçará os desenvolvedores a pensar em vários caminhos não padrão do código. –
- Esses testes de unidade podem ser conectados a pipelines DevOps automatizados e executados com cada implantação no ambiente de desenvolvimento ou teste. Além disso, as métricas do pipeline podem ser facilmente exportadas e usadas para demonstração aos usuários de negócios da cobertura percentual de casos de teste diretamente vinculados ao código-fonte.
O mais importante é começar muito em breve. Quanto mais tarde os testes de unidade começarem a ser desenvolvidos, mais distraído será para os desenvolvedores adicioná-los em um sprint.
- Levará um esforço significativo para desenvolver testes de unidade para código já existente. Algumas partes do código podem ser criadas por outro desenvolvedor e o conhecimento exato de como deve funcionar em cada parte do código não é exatamente claro para o desenvolvedor atual. Em alguns casos, pode chegar tão longe que adicionar um teste de unidade ao código modificado levará mais tempo do que desenvolver a mudança de recurso para o sprint (que é um estado que ninguém calculou durante o planejamento do sprint com certeza).
#2. Faça uma rotina de execução de todas as partes dos Testes de Unidade no ambiente de Desenvolvimento
Mesmo antes de criar uma solicitação de pull para mesclar o novo código na ramificação Master, deve ser uma atividade padrão testar o código de recurso e o código de teste de unidade no ambiente dev. Ao fazer isso, será garantido que:
- O código de teste de unidade está realmente funcionando para cada parte (no final, é apenas outro código que deve ser verificado). Esta etapa é muitas vezes totalmente ignorada. Supõe-se de alguma forma que, se o teste de unidade estiver conectado ao pipeline DevOps, ele será eventualmente executado e testado em algum lugar por padrão. No entanto, isso nada mais é do que empurrar os problemas para os níveis superiores das atividades do sprint, onde a equipe geralmente tem menos tempo e mais estresse para terminar cada história comprometida.
- O novo código de recurso é testado pelo desenvolvedor quanto à funcionalidade básica. Obviamente, não se pode esperar deste teste que a funcionalidade de negócios seja totalmente verificada, mas pelo menos este teste confirmará que o código se comporta da maneira que o desenvolvedor pretendia (ignorando, por enquanto, o fato de que a lógica de negócios poderia ser entendido incorretamente durante o desenvolvimento).
#3. Espere a execução do teste de unidade após a fusão do código na ramificação mestre
Uma coisa é ter um código funcional na ramificação local (onde ninguém, exceto o proprietário da filial, está desenvolvendo um novo recurso), mas é algo completamente diferente ter o mesmo código funcionando após a solicitação pull e mesclar na ramificação principal.
A ramificação master contém alterações de outros membros da equipe Scrum e, mesmo que os conflitos sejam resolvidos e tudo pareça bem, o código após a fusão e a resolução de conflitos ainda é basicamente um código não testado e é arriscado enviá-lo adiante sem verificar primeiro ainda está funcionando bem.
Então, o que provou ser eficaz aqui é simplesmente pedir para executar o mesmo teste de unidade – já feito anteriormente no ambiente dev – também no ambiente, que é construído a partir da versão do código do branch master.
Para os desenvolvedores, pode ser mais uma etapa que eles precisam incluir em sua vida, mas não é um grande esforço, pois, nesse caso, nada de novo deve ser inventado – basta reexecutar o que já foi feito uma vez.
Agora, esta etapa pode ser ignorada em um caso particular:
- Os testes de unidade automatizados nos pipelines de DevOps são tão abrangentes que já cobrem todo o teste manual executado em cima disso.
Embora alcançar esse estado seja definitivamente viável, nunca experimentei tal estado na vida real. Provavelmente seria muito demorado para os desenvolvedores criar testes de unidade automatizados tão profundamente detalhados. Pode ser facilmente inaceitável para o proprietário do produto permitir que a equipe dedique tanto tempo a essa atividade, pois isso teria um impacto explícito no número de histórias entregues em um sprint.
Porém, a preferência pelo conteúdo do sprint nunca deve ser desculpa para não fazer os testes unitários, ou mesmo minimizá-los. Ao fazer isso, a equipe converterá novamente para um estado em que o código está sem cobertura de teste de unidade demais e, para recuperar o atraso, pode ser tarde demais (novamente, o maior esforço para a conclusão do teste de unidade do que o real mudança de código para um sprint).
Por todas essas razões, eu recomendaria a reexecução dos testes de unidade na versão do código mestre sem hesitações. É um esforço tão baixo em comparação com o valor que trará.
Ele fará a verificação final da prontidão da ramificação master para a fase de teste de lançamento. Além disso, ajudará a encontrar a maioria dos bugs técnicos (por exemplo, bugs que impedem que o código-fonte seja executado com sucesso até o final bem-sucedido), deixando para a próxima fase concentrar-se apenas na verificação da funcionalidade do negócio.
Prepare-se para o teste funcional
Todas as atividades de teste anteriores devem levar a uma conclusão específica – o código da ramificação mestre está livre de bugs técnicos e executável sem problemas para fluxos funcionais de ponta a ponta.
Essa é uma fase que pode ser facilmente percorrida por apenas uma pessoa, e essa pessoa inclusive não precisa ter formação técnica.
Na verdade, é muito melhor se isso for executado por alguém desconectado dos desenvolvedores, mas com consciência funcional de como os usuários de negócios esperam que o código se comporte. Existem duas atividades principais a serem concluídas:
#1. Novas histórias de sprint direcionadas ao teste funcional
Cada sprint deve, idealmente, trazer alguma nova funcionalidade (incremento da meta do sprint) que antes não existia e, portanto, deve ser verificada. É importante garantir que o novo software funcione de tal forma que os usuários de negócios fiquem felizes em tê-lo agora, pois obviamente estavam ansiosos por ele durante todo o último sprint, no mínimo :).
É uma experiência tão triste quando a (longa) funcionalidade prometida é finalmente anunciada para ser lançada, apenas para descobrir no outro dia que ela realmente não funciona bem.
Portanto, testar adequadamente a nova funcionalidade do sprint é crucial. Para tornar isso um sucesso, é uma boa prática reunir casos de teste importantes com antecedência e das partes interessadas relevantes (do proprietário do produto ou até mesmo dos usuários finais) e fazer uma lista de todos os casos de teste necessários para o conteúdo dentro o sprint.
Isso pode parecer esmagador à primeira vista, mas, pela minha experiência, é novamente totalmente administrável por uma única pessoa. Como os sprints são em sua maioria bastante curtos (como um período curto de duas semanas), quase nunca há muito conteúdo novo, pois o sprint também contém atividades adicionais, como histórias de dívidas técnicas, documentação, histórias de design/spike, etc.
Os casos de teste são executados com o objetivo de verificar principalmente a funcionalidade desejada. Se ocorrer algum problema com os resultados, apenas o desenvolvedor relevante será abordado (aquele que possui as alterações relacionadas a esse defeito específico) para resolver o problema rapidamente.
Dessa forma, os desenvolvedores passarão um tempo mínimo conectado com os testes funcionais e ainda poderão se concentrar nas atividades que mais gostam.
#2. Execução de casos de teste de regressão
A outra parte do teste funcional deve ser garantir que tudo o que funcionou até agora também funcionará após o próximo lançamento. É para isso que servem os testes de regressão.
Os casos de teste para testes de regressão são melhores se forem mantidos regularmente e revisitados antes de cada lançamento. Com base nas especificidades concretas do projeto, é melhor mantê-las simples, mas abranger a maioria das funcionalidades básicas e importantes fluxos de ponta a ponta que percorrem todo o sistema.
Normalmente, cada sistema tem tais processos que estão tocando em muitas áreas diferentes, esses são os melhores candidatos para casos de teste de regressão.
Em alguns casos, os testes de regressão cobrem implicitamente também novos recursos no sprint, por exemplo, se a nova história no sprint estiver alterando alguma parte específica do fluxo existente.
Portanto, na maioria dos casos, não é muito complexo concluir testes de regressão junto com novos testes de funcionalidade de histórias de sprint, especialmente se isso for feito regularmente antes de cada lançamento de produção e a periodicidade dos lançamentos de produção não for muito pequena.
Insista na execução de testes de garantia de qualidade antes de cada lançamento de produção
O teste de Garantia de Qualidade (QA) é a etapa final antes de liberar para produção e, muitas vezes, esse teste é ignorado por não ser importante. Especialmente se a equipe scrum for gerenciada agressivamente para novos conteúdos.
Mesmo os usuários corporativos dirão que estão interessados em novos recursos e não tanto em preservar a funcionalidade ou manter baixo o número de defeitos. Mas, novamente – com o tempo, esta é a principal razão pela qual a equipe de desenvolvimento terá que desacelerar eventualmente, e então os usuários de negócios não receberão o que pedem de qualquer maneira.
O teste QA deve ser executado exclusivamente por pessoas fora da equipe Scrum, idealmente pelos próprios usuários de negócios em um ambiente dedicado, que seja o mais próximo possível da produção futura. Como alternativa, o proprietário do produto pode substituir aqui os usuários finais.
Em qualquer caso, este deve ser um teste limpo e funcional da perspectiva do usuário final, sem qualquer conexão com a equipe de desenvolvimento Scrum. Ele apresentará uma visão final do produto e será usado de uma forma que possivelmente ninguém da equipe scrum antecipou (não é um caso ideal, mas definitivamente pode acontecer). Ainda há tempo para correções de última hora.
Como alternativa, pode ficar claro que as expectativas não foram bem compreendidas pela equipe scrum e, nesse caso, pelo menos podemos concordar com um plano de acompanhamento, ainda muito antes do lançamento da produção real. Novamente, este não é um caso ideal, mas ainda é muito melhor, como admitir a falha logo após relatar um lançamento de produção bem-sucedido.
Para onde ir daqui?
A aplicação dessas práticas ao trabalho diário do Scrum pode levar você a hábitos de lançamento de sprint mais estáveis e previsíveis, sem atrasar os lançamentos de produção ou gastar o sprint inteiro apenas se preparando para o próximo lançamento, ou mesmo sem forçar todos na equipe scrum a fazer algo que não fazem. realmente não gosto ou não sei como fazer de forma eficaz na maior parte do sprint, ou seja.
Mas com certeza você não precisa parar por aqui.
A inclusão do teste de desempenho é um tópico para citar aqui. Esses são frequentemente ignorados ou considerados desnecessários, raspando na primeira rodada de “otimização das atividades do Scrum”. No entanto, sempre tive dúvidas sobre como esperar que o sistema de produção evolua com o tempo se não for verificado regularmente quanto ao desempenho.
Subir um nível também significa a introdução de testes automatizados.
Já cobri um grupo de testes automatizados (testes de unidade em andamento). No entanto, você pode desenvolver testes completos de regressão de ponta a ponta totalmente automatizados e executados por eles mesmos após cada implantação no ambiente de teste. Isso liberaria ainda mais a equipe de scrum de desenvolvimento, mas requer uma equipe dedicada para desenvolver e manter esses testes automatizados. Isso se tornaria um trabalho constante, pois sempre que o código de produção muda, alguns testes automatizados existentes podem se tornar inválidos e, portanto, devem ser atualizados para continuar trabalhando nos pipelines. É um esforço pelo qual apenas alguns estão dispostos a pagar, mas os benefícios para a equipe dev scrum seriam ótimos.
Esses são tópicos que vão muito além do escopo deste artigo e descobrem o cronograma e o tempo certos para cada tipo de teste mencionado aqui – para que você possa fazê-lo dentro de uma janela de sprint. Ficarei feliz em mergulhar na próxima vez!