Devs, testadores e usuários corporativos devem ter um script de teste unificado?

No desenvolvimento, normalmente eu teria meus próprios scripts de teste que documentariam os dados, cenários e etapas de execução que planejo testar; este é o meu plano de teste para desenvolvedores. Quando a funcionalidade foi implantada no Teste, os testadores a testam usando seu próprio script de teste que eles escreveram. No UAT, o usuário comercial testa usando seu próprio plano de teste.

Em retrospecto, parece que isso fornece uma cobertura melhor, com os testes de desenvolvimento tendo uma mistura de testes em preto e branco, enquanto os testadores e usuários corporativos se concentram nos testes em preto. Mas, por outro lado, isso traz casos de teste distintos que são executados apenas por estágio (ou seja, alguns casos em que os testadores pensam que são executados apenas no estágio de teste) e gostaria que o desenvolvedor o perdesse, o que o torna uma descoberta / bug .

Vale a pena consolidar os scripts de teste desde o início? Assim, usando um script de teste unificado, ou é difícil fazer isso antecipadamente?

Em primeiro lugar, o controle de qualidade não é teste. Se o seu departamento de controle de qualidade não estiver envolvido em todo o processo de desenvolvimento, eles serão teste, não controle de qualidade. O controle de qualidade ao executar seu trabalho fornece garantia de qualidade, na melhor das hipóteses, o Teste mostra a falta de qualidade, mas não pode provar que a qualidade existe - ou seja, o Teste mostra que o controle de qualidade falhou, mas não pode mostrar que foram bem-sucedidos; portanto, o teste e o controle de qualidade não devem ser do mesmo departamento.

Acredito que a melhor maneira é fazer com que cada grupo gerencie seus próprios testes, pois fornece uma melhor cobertura. No entanto, cada equipe deve começar a testar o mais rápido possível. Isso significa que o UAT é iniciado assim que houver algo que os usuários possam usar; o Teste é iniciado assim que uma parte para a qual eles têm um teste estiver pronta etc. Isso impede a descoberta tardia de casos de teste distintos. Isso pode significar alguma rejeição de seus modelos de trabalho, pois muitas vezes o UAT e o Teste esperam estar trabalhando em produtos completos e precisam de treinamento para testar resultados parcialmente completos. Pode ser mais caro, a menos que o fluxo de trabalho seja diferente e um desenvolvedor "Completo" signifique Completo.

O controle de qualidade deve supervisionar isso, juntamente com outras medidas de qualidade, para garantir que o processo não apenas ofereça a saída de qualidade desejada, mas também em um nível de eficiência adequado.

Editar: a referência da pergunta original ao controle de qualidade foi removida; portanto, esta resposta agora aparece OT.

Usamos UATs desde o início.

Funciona como uma referência universal e acho que funciona bem. Embora possa haver scripts de teste que são usados ​​apenas pelos Devs ou Testers para componentes menores, a direção do teste sempre é direcionada para um destino unificado. No final do dia, o UAT é o único que conta, para que você possa fazer dele o foco no início.

Fazer UATs desde o início também tem um benefício adicional. Isso realmente esclarece qualquer ambiguidade entre as expectativas do cliente e a sua.

Eles não precisam de um script de teste unificado, pois as coisas que testam e a maneira como realizam os testes costumam ser diferentes, o que precisam é um requisito unificado do qual todas as partes estão trabalhando. Se o UAT e o QA estão testando coisas que o desenvolvedor nunca pensou, é hora de analisar os requisitos.

Concordo que seria bom ter um script de teste unificado para desenvolvedores, testadores e usuários corporativos, mas acredito que não é possível sem muito esforço, onde o custo ultrapassa o benefício.

O motivo da dificuldade é que o conteúdo do banco de dados em todos os sistemas é diferente e os testes geralmente dependem muito do conteúdo do banco de dados. nossa abordagem para "testes unificados" era que todo sistema também recebe um banco de dados de teste adicional e existem scripts para criar esse banco de dados a partir do zero. os scripts de teste são executados no testdb em que o conteúdo é padronizado.

No mundo perfeito, os desenvolvedores devem ter testes de unidade (xUnit), testadores - testes de integração automatizados (Selenium) e usuários de negócios - testes de aceitação (FIT). Eles podem ter acesso uns aos outros testes.

Realmente depende do projeto. Em alguns casos, uma equipe unificada de Teste, QA e UAT que se reúne para discutir descobertas pode ser altamente benéfica. Isso economiza a duplicação do esforço de teste e garante que todas as partes tenham uma compreensão mais clara das necessidades da empresa por meio de scripts UAT. Por outro lado, dependendo da complexidade do projeto, pode fazer mais sentido fazer o controle de qualidade completo das entradas e saídas antes de testar exemplos de negócios. Para o desenvolvimento de sistemas desenvolvidos em casa, o controle de qualidade inicial seria obrigatório antes da aceitação do usuário. Para implementações prontas para uso, uma equipe de teste unificada faria mais sentido.