Olá, tenho uma dúvida e gostaria de opiniões de como as empresas de vocẽs resolvem esse problema.
Imaginando uma situação de desenvolvimento ágil (SCRUM)
1 - Gostaria de saber quem define o escopo de testes ? É um pessoal mais técnico ou um pessoal de negocio ?
Pois de um lado um pessoal técnico tem o conhecimento de qual a melhor forma de testar uma determinada.
Por outro lado o pessoal de negocio consegue pensar como o usuário.
Para exemplificar o que me faz ter dúvida quanto de quem seria a responsabilidade.
Imagina a situação em que precisamos testar uma venda em uma loja de roupas.
Pessoal técnico definindo escopo .
Vantagens - O pessoal tem como melhor definir o escopo até pq eles estão fazendo a tarefa e sabe quais funções tem que ser testadas.
Desvantagens - Como no exemplo citado acima, precisaríamos de regras anteriores previamente cadastradas (como produtos ou roupas e clientes previamente cadastrados) e imaginando uma situação em que essas informações previas dependem de uma complexa regra de negocio o pessoal tecnico não tem conhecimento para saber como esses produtos/clientes devem ser cadastrados.
Pessoal de negocio Definindo escopo.
Vantagens - Eles vão garantir um cenário mais confiavel pois eles sabem como os itens anteriores devem ser cadastrato.
Desvantagens - Eles não fazem idéia (e realmente é NÃO FAZER IDÉIA) do que precisa ser testado em um sistema, ou seja, eles não sabem como é feito um teste, eles não sabem o que tem que testar, não fazem idéia do que é um teste unitário ou funcional.
Por isso tenho problemas em identificar de quem é esse papel, pois atualmente onde trabalho a definição de escopo de teste é um processo extremamente burocrático e complexo.
Gostaria de saber como é feito isso na empresa que vocês trabalham.
Ora, e porque os dois perfis não podem trabalhar juntos para definir o que deve ser testado ? De maneira geral, quem detém o conhecimento sobre o negócio ajuda na construção de testes de aceitação. Já o pessoal mais técnico, com base nos testes de aceitação pode elaborar testes unitários e testes de integração.
Além disso, algumas coisas deve ficar claras:
desenvolvimento ágil não é só Scrum
Scrum trata apenas do ciclo de vida do projeto. Para conhecer sobre técnicas de construção de software você pode procurar outras fontes, como XP e até em “metodologias não-ágeis” se for o caso.
Quando disse scrum na verdade eu queria dizer toda e qualquer pratica agil, juntamente com seus valores. (SCRUM, XP, Kanban etc…)
E imaginando um cenário SCRUM, com várias estórias, um cenário que tenha um sprint/release planning, PO, Scrum master etc…
Gostaria de saber se alguem tem experiência, pois nesse cenário eu não vi onde é e nem quem faz a definição de escopo de teste de cada estória, ou seja, é em alguma reunião entre time técnico e time negocio ? É em algum sprint meeting ? É feita alguma documentação disso ?
Concordo com a sugestão acima, juntar tecnico com negócio para testar. Negocio pode não saber o que testar, mas sabe como a coisa funcionada como um todo, ou seja regra de negócio…em cima desse conhecimento o técnico monta os testes.
Melhor seria definir a regra com o negocio em alguma reunião. Depois equipe técnica desenvolve os testes.
Na teoria do scrum não sei onde isso é definido. Sempre que trabalhei tinha equipe de teste que conversava direto com negocio para elaborar os testes.
[quote=cbaldin]Quando disse scrum na verdade eu queria dizer toda e qualquer pratica agil, juntamente com seus valores. (SCRUM, XP, Kanban etc…)
E imaginando um cenário SCRUM, com várias estórias, um cenário que tenha um sprint/release planning, PO, Scrum master etc…
Gostaria de saber se alguem tem experiência, pois nesse cenário eu não vi onde é e nem quem faz a definição de escopo de teste de cada estória, ou seja, é em alguma reunião entre time técnico e time negocio ? É em algum sprint meeting ? É feita alguma documentação disso ? [/quote]
Falando especificamente do Scrum, ele determina que esta pessoa seja o Product Owner (o cara de negocios), porque é ele, e somente ele, que ao definir uma estoria, deixa explicita a definição de pronto. Ou seja, ele diz: esta estoria estará pronta quando atender tal, tal e tal requisito de tal, tal e tal forma.