Entrar Ainda não tem acesso?
Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

Grau excessivo de detalhes

Referente ao curso Value Stream Mapping (VSM): conheça o mapeamento de Fluxo de Valor, no capítulo SIPOC e VSM e atividade Mapear processos vs requisitos

por Alex Aguiar
| 38.5k xp | 33 posts

Nessa aula foi mencionado sobre alguns motivos para desatualização do processo e um deles me chamou atenção, pois, é algo que acredito ser muito comum em alguns projetos de desenvolvimento de software. "O grau excessivo de detalhes".

Imagine que estamos em uma primeira sprint de um projeto e atuando com foco em entregar com valor um MVP. Porém, a sprint foi "startada" sem termos a fase inicial (prototipação, requisitos e as validações de ambos) completamente finalizada.

Nesse cenário, temos um QA que precisa descrever um plano de testes e para isso deve ser usado as histórias e protótipos construídas ate o momento. Mas, como estão sendo construídas ao mesmo tempo em que o plano vem sendo elaborado o mesmo adota a estratégia da "cobertura máxima" aumentando o detalhamento dos passos, cenários e casos de testes escritos. Usando, principalmente, BDD para escrever os cenários e casos de testes.

Pergunta: Ate que ponto essa "estratégia" pode ser bom ou ruim?

1 resposta
solução!
por Yasmin Cunha
| 448.3k xp | 1039 posts
Alura Scuba Team Monitora

Olá Alex :)

Vou tentar te ajudar. Essa estratégia pode ser tanto boa quanto ruim, dependendo do contexto e da qualidade do trabalho realizado. Por um lado, um grau elevado de detalhes nos casos de testes pode garantir que a equipe de desenvolvimento construa o produto com mais qualidade e ajude a identificar falhas e problemas no processo de desenvolvimento mais cedo. Além disso, o uso de BDD pode ajudar a garantir que todos na equipe estejam alinhados quanto aos requisitos e expectativas do produto.

Por outro lado, se a equipe está trabalhando em um MVP e ainda está descobrindo os requisitos e validando protótipos, um grau excessivo de detalhes pode ser prejudicial. Isso porque, durante o processo de validação, pode-se descobrir que algumas funcionalidades não são necessárias ou que outras precisam ser adicionadas. Se o plano de testes é muito detalhado, a equipe pode perder tempo criando testes para funcionalidades que serão descartadas ou ter que refazer os testes quando novos requisitos são adicionados.

Portanto, é importante encontrar um equilíbrio entre um grau adequado de detalhes nos casos de testes e a flexibilidade para adaptar-se a mudanças durante o processo de desenvolvimento. A colaboração e comunicação entre a equipe de desenvolvimento e de testes é fundamental para que essa adaptação aconteça de forma eficiente e sem comprometer a qualidade do produto final.