Julho 2016 - Microsoft Test Manager
•Transferir como PPTX, PDF•
0 gostou•393 visualizações
Palestra apresentada no encontro de julho pelo Ramilo Neves
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Destaque (20)
Semelhante a Julho 2016 - Microsoft Test Manager
Semelhante a Julho 2016 - Microsoft Test Manager (20)
Julho 2016 - Microsoft Test Manager
- 2. Agenda Objetivo Custo do Bug MicrosoftTest Manager Tipos deTestes no MTM Tipos deTeste de Software –Visual Studio 2015 Perguntas
- 3. Objetivo Apresentar o MicrosoftTest Manager e demonstrar sua capacidade de armazenar, organizar e auxiliar osTestes.
- 4. Custo do Bug Development Test Release Fase do Desenvolvimento CustodoBugs
- 5. MicrosoftTest Manager O MicrosoftTest Manager (MTM) permite o gerenciamento de testes de software. Ele é baseado em Planos deTeste e Casos de Testes, através da criação destes é possível a executar os testes.
- 6. Tipos deTestes no MTM Testes Funcionais (Manual e Automatizado); Testes Exploratórios (Manual); Testes de Regressão (Manual e Automatizado).
- 7. DEMO
- 8. DEMO
- 9. DEMO
- 10. DEMO
- 11. DEMO
- 12. DEMO
- 13. DEMO
- 14. DEMO
- 15. DEMO
- 16. DEMO
- 17. DEMO
- 18. DEMO
- 19. DEMO
- 20. Perguntas ???
- 21. Referências http://blogs.msdn.com/b/briankel/ http://www.mstesters.net/ http://blog.alancmorais.net/ http://blog.andredias.net/ http://www.anselmeit.com/
Notas do Editor
- Cenário 1 : Bug encontrado durante o desenvolvimento Este cenário é o ideal. O desenvolvedor escreve o código, cria os testes unitários, verifica que alguns métodos estão com erros, os corrige e pronto. Desde que ele termine dentro do prazo, o meu custo adicional é zero. Cenário 2 : Bug encontrado durante a fase de homologação Desta vez o desenvolvedor também foi cuidadoso, no entanto, ele não testou uma integração do código que ele acabou de desenvolver com outro código já existente. Isso vai gerar erro de integração. O testador vai identificar o erro, registrá-lo, colocar os passos para reprodução e outras informações necessárias, esse bug será triado por um team leader, que encaminhará para um programador que precisará entender o que é esse bug, tentará reproduzi-lo para depois corrigir e só então gerar uma nova build para ser publicada. Ah, o testador terá que verificar se o bug foi realmente corrigido. Bom, estimando isso em horas, podemos colocar 2 horas para o testador, mais 3 horas do desenvolvedor e do team leader. Se assumirmos uma valor médio de R$ 40,00 por hora, já temos um prejuízo de R$ 200,00 com apenas um bug. Você deve estar pensando naquela sua planilha lotada deles né? Acertei? Que coisa! Cenário 3 : Bug encontrado em produção Dessa vez vamos falar do pior cenário, o cliente achou o bug. Primeiro que você vai ouvir um monte de abobrinha do cliente, e com razão. Você vai ter que dar um suporte telefônico pra ele, tentar entender o que ele está dizendo, dificilmente você terá um cenário igual ao dele, você perderá tempo montando o cenário, depois que conseguir reproduzir o bug irá registrá-lo, o programador terá que entender, corrigir, gerar uma build, ir pra teste, publicar no cliente, testar novamente. Ufa!!! Nessa brincadeira, você perdeu tempo do gerente do projeto, analista de negócio, team leader, programador, testador e do implantador. Assumindo duas horas pra cada recurso, que ainda é pouco, e um valor médio, dessa vez ,de R$ 50,00 por hora, afinal gerente e analista ganham bem A brincadeira ficou R$ 600,00. Bugzinho caro né? Vamos fazer uma continha simples agora. 15 bugs por mês no cenário 2, mais 2 bugs do cenário 3 e no final de um ano temos um gasto com bugs em apenas um projeto de R$ 50.400,00.