Ao criar estimativas de tempo para tickets, o tempo gasto para testadores (QAs) deve ser incluído em uma estimativa de tickets? Anteriormente, sempre estimamos sem o tempo dos testadores, mas estamos falando de sempre incluí-lo. Faz sentido para o nosso sprint atual, o último antes do lançamento, pois precisamos saber o tempo total que os tickets levarão em uma semana.

Eu sempre entendi que a estimativa era apenas para o tempo do desenvolvedor, pois isso tende a ser o recurso limitador nas equipes. Um colega está dizendo que onde quer que tenham trabalhado antes do tempo do testador também foi incluído.

Para deixar claro, isso é para um processo em que os desenvolvedores estão escrevendo testes de unidade, integração e interface do usuário com boa cobertura.

Minha recomendação: você inclui o tempo de teste no ticket ou adiciona um ticket para representar a própria tarefa de teste. Qualquer outra abordagem faz com que você subestime o trabalho real necessário.

Embora o tempo do desenvolvedor geralmente seja um gargalo, na minha experiência, há muitas equipes restritas a teste. Supondo que o recurso limitador seja um ou outro sem evidência, você pode mordê-lo.

Como seu colega, eu não vi uma organização de sucesso que não leva em consideração o tempo de teste.

Adendo por seu esclarecimento: Mesmo que os desenvolvedores escrevam testes automatizados, principalmente testes de unidade (os testes de integração se saem melhor), eles são insuficientes para testar adequadamente.

Se houver pessoal de controle de qualidade envolvido, seu tempo precisará ser estimado, de uma maneira ou de outra. Somente se você decidir remover pessoas de controle de qualidade da folha de pagamento, o tempo de trabalho delas desaparecerá efetivamente e você poderá removê-lo da estimativa. Mas isso teria efeitos colaterais fáceis de ignorar. E você ainda pode estar perdendo testes de desempenho, estresse, segurança e aceitação.

Enfaticamente, Sim

O teste faz parte do processo de desenvolvimento. Se sua equipe realmente gasta tempo testando o software, o tempo gasto no teste precisa fazer parte da estimativa.

Se isso for ágil, eu incluiria o esforço de teste como parte do total de pontos da história. Por exemplo, o esforço do desenvolvedor talvez 1 dia e o teste 1 dia, o que seria uma história de 2 pontos.

Depende de qual é sua definição de concluído, mas geralmente seu desenvolvimento completo, aceitação comercial e teste são finalizados na iteração. Se o DoD é apenas aceitação comercial, o esforço de teste não precisa ser incluído nos pontos da história, mas ainda deve ser rastreado.

A estimativa deve contabilizar todo o trabalho necessário para concluir o ticket. Se o teste for uma parte necessária do ticket, ele deverá ser incluído na estimativa. Se o teste for um ticket separado, não deve.

É claro que isso pode ficar confuso quando você começar a usar pontos da história, já que a diferença entre um dev-5 e um dev-8 será bastante proporcional a um dev-e-QA 5 versus um dev-e-QA 8.

Eu já vi incluindo o tempo de trabalho do testador. Vi histórias separadas funcionar. Eu já vi tarefas separadas, cada uma estimada pelo grupo que as faz funcionar. Faça o que faz sentido para você, depois de todo o processo para atendê-lo, não vice-versa.

O fato de você não poder responder isso fortemente sugere que você não sabe por que está escrevendo estimativas (ou pelo menos discorda do seu colega por que está escrevendo estimativas). Esse é um problema maior do que se as estimativas devem ou não incluir testes.

Descubra, ou chegue a um acordo, por que você está escrevendo estimativas. Se é para prever o que uma equipe em particular alcançará em um determinado momento, a resposta simplesmente depende se essa equipe, a que você está estimando, faz o teste ou não. Se sua equipe de controle de qualidade for separada e tiver seu próprio agendamento, talvez eles estejam interessados ​​em saber quanto tempo de teste você (os desenvolvedores) acha necessário deles em um determinado ticket. Eles podem ignorar seus números e colocar os seus próprios. De qualquer maneira, eles podem acompanhar isso separadamente das estimativas de tempo de desenvolvimento.

Por outro lado, se uma equipe está realizando todo o desenvolvimento, teste e controle de qualidade, e o objetivo das estimativas de tempo é prever e planejar o que essa equipe está fazendo em um determinado período de tempo, é claro que as estimativas de tempo devem incluir Controle de qualidade, juntamente com outras tarefas necessárias para que a equipe execute, a fim de atingir a meta declarada. Nesse caso, se você precisar ter uma reunião inicial para cada ticket ou preencher alguma papelada após a conclusão, o tempo para o administrador precisará estar em algum lugar . Você não pode simplesmente ignorá-lo.

Se é tudo uma equipe, mas com papéis separados "desenvolvedores" e "testadores", isso pode significar que você tem muitos tickets em que apenas um lado da divisão é capaz de trabalhar, e seu gráfico de Gantt (talvez inteiramente hipotético) parece exatamente como seria o gráfico para duas equipes separadas. Esse fato perturba algumas metodologias mais do que outras, e é melhor dividir o planejamento por causa disso, mas se você não o dividir, precisará multar e estimar tudo o que a equipe precisa fazer ou suas previsões serão inúteis. .

Se o objetivo das estimativas for algo diferente de previsão e planejamento, por exemplo "porque seguimos sem pensar em um ritual vazio que os inclua", ou "porque a gerência os usa como um bastão para nos bater e conseguir horas extras fora de nós", ou "porque temos que fazer um lance de preço fixo e os números entrarem em uma fórmula enorme" (obrigado John Wu), então pode ser mais difícil descobrir o que eles devem incluir ;-)

Sempre estime todo o trabalho que precisa ser feito para tornar realmente uma história / recurso / ticket do usuário. Chamamos isso de Concluído .

Terminamos quando estamos prontos para produção .

Isso inclui qualquer teste manual e exploratório, mas também testes de aceitação do usuário.

Uma equipe Ágil deve poder liberar uma nova parte do trabalho concluído a qualquer momento. Como:

O software de trabalho é a principal medida de progresso.

Como você sabe se funciona, se não o testou? Agora você escreve que o tempo de desenvolvimento é o gargalo do seu tempo. Como engenheiro de controle de qualidade, acho que a maioria das equipes tem um gargalo na capacidade de teste ou está apenas tomando atalhos.

Para resumir uma longa história, também estime o esforço de teste. Lembre-se de que isso pode influenciar sua velocidade . Se você estiver fazendo estimativas relativas em histórias, o teste já poderá ser incorporado à sua velocidade média.

Aqui está algo muito importante: todas as estimativas devem ser acompanhadas de suposições e exclusões .

Isso inclui especificar o que está incluído: apenas desenvolvimento, design e desenvolvimento, teste de desenvolvimento e unidade, cobertura para teste de aceitação, construção de infraestrutura etc.

Se você estiver fornecendo um documento de estimativa a um gerente de projeto, ele converterá esse documento em uma ordem de serviço ou declaração de trabalho para um cliente ou (se um projeto interno) para o PMO . Eles podem ter definido fórmulas para adicionar custos indiretos (por exemplo, alguns projetos podem adicionar X% para cobrir o controle de qualidade e, em seguida, Y% para cobrir governança e gerenciamento de projetos) definidos por contrato ou por experiência. E você não quer dobrar a contagem. Por outro lado, eles podem não adicioná-los automaticamente.

Práticas diferem. Quem estiver usando esses números precisará saber o que os números significam e você deve ser explícito sobre se está incluindo o tempo do teste ou não.

O tempo deve ser incluído na estimativa, mas você não deve estimar o tempo dos testadores. Em vez disso, os testadores devem estimar seu tempo .

Não incluir o tempo de teste é uma estimativa falsa do tempo total que levará, mas o tempo do desenvolvedor e o tempo do testador não são intercambiáveis ​​(principalmente porque você presumivelmente trabalha em paralelo, com os testadores uma iteração atrás), portanto, você deve estimar separadamente. Além disso, você não está em posição de estimar o tempo que os testadores precisarão para testar as alterações, apenas a equipe de teste deve fazer isso.

Encapsulamento

Vou abordar isso do ponto de vista e da linguagem de desenvolvimento de software.

• Você é uma pequena engrenagem em uma máquina grande.
• Do lado de fora da sua equipe, seu sistema de emissão de bilhetes funciona como uma interface / API para sua equipe
• Os usuários corporativos que usam o sistema de emissão de bilhetes não são desenvolvedores

Com um bom design de software, você deve simplificar e encapsular o máximo possível.

Portanto, para analisar o processo do ponto de vista dos usuários corporativos, eles realmente se preocupam apenas com duas coisas.

1. Quanto vai custar?
2. Já terminamos?

Permitir que o usuário comercial saiba sobre o processo interno de sua equipe é um mau gerenciamento; semelhante a dar publicacesso ao estado interno.

A falha em proteger o estado interno de sua equipe está convidando outras equipes para gerenciar seus recursos e mexer com seu estado interno.