Projeto de caso de teste e responsabilidade de testadores, desenvolvedores, clientes [fechados

Question

Parece que muitas pessoas estão jogando o jogo da culpa onde eu trabalho, e isso traz uma pergunta interessante.

Conhecido:

Requisitos A equipe escreve requisitos para o produto. Os desenvolvedores criam seus próprios testes de unidade de acordo com os requisitos. A equipe de teste cria condições de teste, design e casos de teste de acordo com os requisitos.

Produto lançado se e somente se X% dos casos de teste de testes da equipe passes.

Após a entrega, o cliente faz testes de aceitação -> A equipe de resposta ao cliente recebe bugs do campo e informa a equipe de teste sobre esses problemas.

Pergunta:

Se o cliente acaba arquivando muitos defeitos, quem é o culpado? É a equipe de testes para não cobrir isso? Ou é a equipe de requisitos para não escrever melhores requisitos? E como melhorar o sistema?

Answer 1

O que "não parece funcionar" significa no seu caso?

Verificou que a consulta Ajax Post está sendo enviada (você pode ver isso no console do desenvolvedor do seu navegador).

Answer 2

Os bugs podem inserir o sistema nos requisitos e etapas de desenvolvimento. A equipe de requisitos pode cometer alguns erros ou suposições simplificantes ao criar os requisitos, e os desenvolvedores podem interpretar mal os requisitos ou fazer suas próprias suposições.

Para melhorar as coisas, o cliente deve assinar os requisitos antes do prosseguimento de desenvolvimento e deve estar envolvido, pelo menos até certo ponto, no monitoramento do desenvolvimento para garantir que as coisas estejam no caminho certo.

Answer 3

A primeira pergunta em minha mente seria: "Como os defeitos se comparam aos requisitos?"

Se o requisito disser: "Ok, o botão deve ser azul" e o defeito é "Ok Button Is Green", eu culparia o desenvolvimento e o teste - claramente, nem leiam os requisitos. Por outro lado, se a reclamação é: "O OK Button não é amarelo", claramente, houve um problema na coleta de requisitos ou no seu processo de controle de mudança.

Não há resposta fácil para esta pergunta. Um sistema pode ter um grande número de defeitos, com a responsabilidade entre todos os envolvidos no processo - afinal, um "defeito" é apenas outra maneira de dizer "expectativa não atendida do cliente". As expectativas, por si só, nem sempre estão corretas.

Answer 4

"Produto lançado se e somente se x% dos casos de teste de passes de equipes de teste" - for um dos critérios para liberação. Nesse caso, "cobertura de testes" no TCS escrito é muito importante. Precisa de uma boa revisão do TCS se qualquer funcionalidade ou cenário é perdida ou não. Se alguma coisa for perdida no TCS, poderá encontrar erros, pois parte dos requisitos não é coberta em casos de teste.

Ele também precisa de alguns testes ad-hoc, bem como testes exploratórios para encontrar bugs de descobertas no TCS. E também precisa definir "critérios de saída" para teste.

Se o cliente/cliente encontrar algum bug/defeito, é necessário investigar como: i) Que tipo de bug é encontrado? ii) Existe algum caso de teste escrito sobre isso? iii) Se houver casos de teste sobre o executado corretamente? iv) Se estiver ausente no TCS, por que foi perdida? e assim por diante

Após a decisão de investigação, pode -se tomar uma decisão que deve ser responsabilizada. Se for um inseto/defeito de olhos abertos, definitivamente os testadores devem ser responsabilizados.