Codificação e teste no mesmo sprint

Como o teste é realizado dentro do mesmo sprint que a codificação, se toda ou a maior parte da codificação não é feita até o final do sprint? (Estou me referindo ao desenvolvimento e teste "de sopa para nozes" de um único PBI em um sprint.)

A maioria das respostas que eu vi on-line envolve automação de controle de qualidade, mas mesmo isso não é possível, pois geralmente você precisa de uma interface de usuário funcional para registrar ou criar testes automatizados. Só tenho storyboards que continuam a evoluir à medida que desenvolvo recursos e descubro novos requisitos.

No meu caso, estou desenvolvendo um novo aplicativo de desktop. Geralmente, os aplicativos de desktop não se prestam muito bem a testes automatizados. Tenho alguns testes de unidade automatizados, mas eles não são os testes funcionais / de integração manuais que um profissional de controle de qualidade executaria.

Então, onde eu estou agora é que meu sprint termina amanhã, ainda tenho a codificação para terminar, e meu pessoal de controle de qualidade ainda não tem nada para testar e não tem idéia de como testar o que eu daria a eles sem eu segurar suas mãos.

Tenho certeza de que não sou a primeira pessoa a ter esse dilema.

No passado, eu fiz um pipeline: no sprint atual, a equipe de teste testa os recursos implementados durante o sprint anterior. No meu trabalho atual, o PM refere-se a essa abordagem como "cascata" e, como tal, inaceitável.

Se você não testar uma história do usuário (EUA) e verificar se os critérios de aceitação foram atendidos, essa história não foi concluída. Se isso não for feito, os EUA vão para o próximo sprint, é claro. E se todos os seus EUA estiverem nesse estado, o seu sprint terminou sem nenhum valor agregado ao projeto. Do ponto de vista do cliente, não consigo distinguir isso de toda a equipe de desenvolvimento que sai de férias.

Um dos princípios enxutos (o ágil não termina com o scrum) diz que "a qualidade está embutida". Algo é feito apenas se atender aos critérios de qualidade definidos por você. É crucial ter um processo ágil real, terminar a primavera com valor zero ou separar os testes do desenvolvimento são sintomas de um grande problema.

Há muitas coisas que você pode fazer:

• a automação é a chave do sucesso. Pelo menos no nível do teste de unidade, e algumas outras práticas como o IC também são importantes. Isso não é suficiente, mas se bem feito, esses tipos de teste resultam em poucos ou nenhum erro descoberto em testes manuais (geralmente pequenas coisas da interface do usuário). Se você dedicou pessoal de controle de qualidade, eles podem automatizar o teste de aceitação, e parte dessa automação pode começar antes de você terminar um sprint.

• Veja o tamanho das suas histórias de usuário. Se você tem um EUA que terminou os dois primeiros dias do sprint no terceiro dia, uma pessoa de controle de qualidade pode testá-lo. Na minha opinião, ter um histórico pequeno de usuários (SMART) é uma das coisas mais importantes para o sucesso no desenvolvimento ágil, e muitas pessoas parecem não perceber isso.

• A colaboração entre testador e desenvolvedores é outra parte essencial do sucesso. No meu projeto anterior, quando os EUA são finalizados por um desenvolvedor, uma pessoa de controle de qualidade faz um "teste de pares" com o desenvolvedor (pode ser manual, pode ser através do lançamento de alguns automatizados, ou melhor, ambos), isso funciona muito bem.

O problema essencial é que você tem programadores que codificam, mas não testam, e testadores que testam, mas não codificam.

Resolva esse problema e você não o terá, e uma equipe sem dúvida mais eficiente.

Uma maneira que funcionou para mim no passado foi sugerir codificadores e testadores para parear histórias com a tarefa explícita de fornecer uma história totalmente testada. Junto com isso, eu apaguei todas as formas de pensamento "dev complete": nenhuma coluna "dev complete" no quadro scrum / kanban / trello, nenhuma atitude "dev done" dos programadores.

O que aconteceu foi:

• Os pares eram responsáveis ​​pela entrega de histórias e ambos fracassariam se uma história não fosse concluída. Eles foram tratados como profissionais responsáveis ​​encarregados de fornecer software e, na maioria dos casos, o fizeram.

• Houve muito menos trabalho de teste porque os testadores foram expostos aos testes de unidade e integração, portanto, eles não repetiram o mesmo teste manualmente.

• Alguns testes foram automatizados quando os desenvolvedores entenderam melhor o que os testadores precisavam.

• Algumas pessoas ficaram chateadas.

• As histórias foram entregues mais rapidamente, em média, porque o ciclo de código-confirmação-puxar-teste se tornou quase instantâneo

Claro, essa é apenas a minha experiência anedótica, mas você pode tentar fazer isso sozinho, se puder.

No seu caso, dado o seu comentário de que testadores e desenvolvedores são separados por autoridade na sua empresa, a mensagem parece clara para mim. Há uma barreira óbvia à comunicação e colaboração colocada pelas regras da empresa.

Este é um problema de comunicação , não um problema ágil . Adotar uma metodologia ágil é simplesmente torná-la evidente. As equipes silo'd são um anti-padrão de gerenciamento conhecido ; portanto, adote a não adaptabilidade do ágil neste caso!

O papel real do seu controle de qualidade está próximo do teste de aceitação. Eu imagino que isso seja feito por uma equipe separada, que atua mais como proprietária do produto do que como parte da equipe de desenvolvimento.

Exemplo: durante um sprint, você precisa adicionar um recurso que permita filtrar os resultados da pesquisa por diferentes critérios. Você já tem seu mecanismo de pesquisa implementado, mas os resultados são ordenados alfabeticamente.

• Durante o sprint:

  1. A equipe esboça o design do novo recurso e o impacto na base de código real.

  2. Os desenvolvedores escrevem testes de unidade que garantem que o pedido esteja funcionando conforme o esperado e, ao mesmo tempo, escrevem o código real.

  3. O novo recurso é cuidadosamente testado para garantir que não quebre nada (teste de regressão) e que esteja funcionando conforme o esperado (testes de unidade).

  4. Se possível e apropriado , o que não é o caso na maioria dos projetos , o proprietário de um produto (e, portanto, sua equipe de controle de qualidade) pode avaliar constantemente o novo recurso para impedir que a equipe vá na direção errada. Isso requer integração contínua com dezenas de compilações todos os dias.

• Após o sprint, o proprietário do produto avalia o novo recurso para verificar se ele corresponde às necessidades do cliente. Sua equipe de controle de qualidade está aqui, depois que o sprint terminou.

Acredito que seus problemas reais sejam os seguintes:

• Âmbito . Um sprint diz respeito à sua equipe e apenas à sua equipe, não ao seu controle de qualidade real, que atua mais como proprietário de um produto.

• Teste . O fato de você ter uma equipe de controle de qualidade não significa que tudo o que você precisa fazer é escrever código. O trabalho da sua equipe é fornecer um recurso que funcione conforme o esperado, não jogar fora o código para os outros testarem. Se você contar com a equipe de controle de qualidade para fazer o teste, isso aumentará o custo geral, pois os bugs serão corrigidos uma a duas semanas depois, em vez de serem corrigidos quase instantaneamente.

se toda ou a maior parte da codificação não for feita até o final do sprint?

Por que não está terminando mais cedo? Essa limitação chave é a fonte dos seus problemas e vi duas abordagens serem bem-sucedidas. Um se encaixa bem na abordagem ágil (mas não em outras práticas comuns) e o outro tende a se agilizar um pouco (mas é mais comum).

A primeira é que você não codifica até o final do sprint. Na verdade, escrever código é uma parte relativamente pequena do desenvolvimento. Se você terminar na metade do sprint, isso fornecerá bastante tempo para o controle de qualidade executar seu trabalho. Também lhe dá tempo de sobra para escrever documentação, limpar dívidas técnicas, projetar itens de lista de pendências ... Todas as outras coisas que você precisa fazer para obter um produto de qualidade. A única desvantagem disso é que é quase impossível obter a funcionalidade e os testes de unidade rapidamente. Pessoalmente, acho que é completamente bom fazer testes de unidade depois de deixar o controle de qualidade começar a analisar a funcionalidade, mas os defensores do TDD (e outros) discordam.

A segunda opção é fazer com que o controle de qualidade opere um sprint atrás da equipe de desenvolvimento, como seu gerente de desenvolvimento odeia. Eu também tendem a não gostar disso. Ele elimina o conceito de "produto liberável" no final do sprint, mesmo se você tiver um processo de escalação para seus lançamentos. Pior, os desenvolvedores se concentrarão em coisas "novas" quando o controle de qualidade chegar a elas com perguntas ou bugs dos testes. É mais improvável que os desenvolvedores consertem bugs nesse arranjo. Mas já vi produzir software de qualidade a tempo.

O Guia Scrum exige que as equipes sejam multifuncionais. Todos os membros da equipe são considerados desenvolvedores, independentemente de sua especialização individual. Indivíduos silo'd (codificador, testador, qa, ux, etc) são inúteis no Scrum. Os membros da equipe se ajudam sempre que podem. Não há conceito de 'passar o item para qa'.

Na sua situação, parece que você pode ter um problema de estimativa. Ao estimar os itens de lista de pendências do produto, é necessário considerar todas as atividades, como: Codificação, Teste, Revisão por Pares, Implantação, Integração - qualquer que seja sua definição de demanda realizada.

Como regra geral, espere trazer entre 5 e 15 itens de backlog do produto para um sprint. Isso dá uma idéia do tamanho de cada item da lista de pendências do produto. Também oferece uma excelente chance de realizar o trabalho dentro do sprint.

Por fim, a tarefa da equipe é mover um item da lista de pendências de produtos para 'concluído' e depois passar para o próximo. Às vezes, fazer isso significa que as pessoas estão pisando umas nas outras e, portanto, faz sentido aumentar mais de um estoque de produtos por vez. Sua orientação, porém, deve ser reduzir o trabalho em andamento (WIP) e mover os itens da lista de pendências do produto para concluídos.

Teste e codificação andam de mãos dadas. Você pode agendá-lo módulo por módulo. Quando o módulo estiver concluído, você poderá fornecê-lo aos testadores. Todo esse cenário também depende da fase de teste em que você está trabalhando. O modelo espiral SDLC parece bom. Nesse sentido, o teste e a codificação simultâneos são convenientes. Outra abordagem poderia ser o modelo V .

Minha resposta, que provavelmente é bem estranha no começo, seria: você não encontra tempo para testar porque acha que o teste deve ser feito com os efeitos colaterais do código. E com efeito colateral, quero dizer o termo ciência da computação :

é dito que uma função (...) tem um efeito colateral se, além de retornar um valor, também (...) tem uma interação observável com (...) o mundo exterior.

Eu criei a citação para enfatizar a parte "interação com o mundo exterior": você deseja que os testes ocorram na interface do usuário conforme impressa na tela ("[iniciar o teste] não é realmente possível, pois geralmente você precisa de um UI para registrar ou criar testes automatizados a partir de ").

Outras respostas disseram para você automatizar esse "teste de aceitação", para que isso ocorra rapidamente. Isso está certo, mas não resolve completamente o seu problema original: e se não houver tempo suficiente para escrever esses testes de aceitação?

Você deve deixar de lado sua visão de teste depois que o código interagir com o mundo exterior, ou seja, ele imprimiu algo e espera alguma entrada. O problema dos efeitos colaterais é que eles são, na verdade, não testáveis. Isso me ocorreu ao ler uma entrevista com Guido van Rossum, onde ele disse que uma declaração que desliga o computador só pode ser comprovada como sendo executada.

A solução para essa "falta de testabilidade" é entender que, se você tiver provado uma vez que a declaração funciona, poderá usá-la em qualquer lugar e confiar nela para fazer seu trabalho. Isole-o em uma função e teste tudo o resto .

Aproximando esse exemplo da sua pergunta, a função agora é provavelmente uma biblioteca ou estrutura inteira e, em vez de desligar o computador, imprime algo: uma interface do usuário. Mantenha as chamadas o mais burras e o mais estável possível , porque depois de entrar nessa parte do seu aplicativo, você só pode testar através de testes de aceitação caros, ou seja, algum tipo de observação externa.

Considerar a interface do usuário como "território estrangeiro" é na verdade um ponto de vista correto, pois você não precisa testar a lógica de uma biblioteca que não é fornecida por você e, talvez surpreendentemente, é um ponto de vista realista: você realmente espera testar essa chamada, por exemplo MyWidget.draw(), o que você espera, no nível de um único pixel?

Isso não quer dizer que o teste de aceitação não seja importante ou que possa ser ignorado. Está aí para ficar e automatizá-lo, como sugerem outras respostas, traz enormes benefícios. Mas se você quiser encontrar tempo para testar e codificar no mesmo sprint, tente manter seu código o mais livre de efeitos colaterais possível.