Transferir como PDF, PPTX
Carregado porAdriano Bertucci
Qualidade de software com Visual Studio ALM
O documento discute a importância da qualidade de software e como alcançá-la. Apresenta os desafios comuns entre testadores e desenvolvedores e como a automação de testes com ferramentas como o Visual Studio podem ajudar a superá-los, melhorando a comunicação, reprodutibilidade de defeitos e agilidade.
Qualidade de software com Visual Studio ALM
- 1. Visual Studio ALM Qualidadede Software Adriano Bertucci @adrianobertucci adriano@bertucci.com.br Especialista em Soluções ALM Microsoft MVP Visual C# adriano.bertucci http://www.adrianobertucci.com
- 2. Qualidade uma necessidade −Considerando que desenvolvimento de software representa 25% dos gastos em software, identificar a causa dos problemas e falhas nos projetos de desenvolvimento se torna uma necessidade.
- 3. Qualidade uma necessidade − O sucesso de um projeto de software pode ser definido por um triângulo: Tempo (Prazo) Funcionalidade Qualidade Orçamento (Custo) Funcionalidades − Nos acostumamos em aceitar 2 dos 3 Consideramos isso sucesso? − Atualmente o triângulo se transformou em um quadrado; Qualidade é a quarta dimensão Prazo Orçamento − Ainda consideraremos 2 das 4 dimensões?
- 4. Caminho para osucesso... Ideia Solução
- 5. Como chegamos atéaqui?
- 6. Passado 1962– Acidente com Veers, $18.5M 1978 – Colapso do Hartford Coliseum, $90M
- 7. Presente − Testador reportaum erro após passar horas coletando evidências de um problema. − Desenvolvedor diz que não tem informações suficientes. − Testador refaz os testes coletando mais evidências. − Desenvolvedor diz que não consegue reproduzir o erro em sua máquina.
- 8. Presente Ei, voce informou Claro! Na minha “Não consigo máquina funciona! reproduzir” no defeito que enviei! Testador Desenvolvedor
- 9. Presente Não, porque você está usando. Pare Você tentou os seus testes que reproduzir no meu eu verifico. ambiente de teste? Testador Desenvolvedor
- 10. Presente Certo, vou parar meus Ainda não consegui testes e aí você reproduzir! Suas assume, olha os logs e informações não refaz os passos. estão claras. Testador Desenvolvedor
- 11. Presente Testador Desenvolvedor
- 12. Futuro − Aplicações emambientes complexos e distribuídos − Software + Serviços − Tecnologia Multi-Touch, Tables, Smarphones, etc.
- 13.
- 14. Índices de sucessoem projetos Taxa de falha aceitável? − Baseado em tempo, orçamento e funcionalidades especificadas entregues, 68% dos projetos nunca foram colocados em produção ou foram cancelados. Extreme Chaos, The Standish Group International, Inc. – 2009 Acima do Custo estimado: 45% Acima do Prazo esperado: 63% Funcionalidades entregues: 67%
- 15. Problemas − “Visibilidade doandamento do projeto” − “Não existe comunicação na equipe” − “Difícil conciliar necessidade do usuário com riscos” − “Modelos de desenvolvimento complexo” − “Soluções não são testadas”
- 16. Causas “testadores gastam “um requisito mudou, muito tempo quais testes precisam ser testando a mesma feitos?” coisa” “desenvolvedores e testadores não falam a mesma língua e trabalham em silos” “ferramentas são “desenvolvedores dizem caras (tempo, licenças, que os defeitos não pessoas)” servem para nada” “quando o software estará pronto?”
- 17. O que fazer? − Padronizar − Arquitetar − Testar − Ter atitude − Capacitar − Organizar − Integrar − Fazer manutenção − Entregar rapidamente
- 18.
- 19. O que dizersobre P.O.G.? − “A culpa é do Hardware!” desenvolvedor de software sobre POG − “A culpa é do Software!“ técnico de manutenção de hardware sobre POG − “A culpa é da rede!” vendedor de PC Retirado do http://desciclo.pedia.ws
- 20. Desenvolvemos a umbom tempo
- 21. POG é inadimisível! − Por isso temos que estudar!
- 22. Desafios comuns paraqualidade
- 23. Testador Desenvolvedor
- 24. Impacto Desenvolvedores sentem-se desmotivados • Bug ping/pong • Falta de acesso a ambientes seguros • Tempo para preparação do ambiente excessivo Testadores não são respeitados • Preparar testes e ambiente consomem 30%-50% do ciclo de testes • Maioria dos defeitos fechados como “não-reproduzíveis”” • Ferramentas não integradas ao ciclo de desenvolvimento Impacto no negócio • Falta de agilidade para responder ameaças ou oportunidades • Alta taxa de falha em projetos • Quem sente “dor” é o usuário final
- 25.
- 26. Segmentação dos testes Generalista Especialista Testes manuais Algumas scripts Scripts Codificação Grande experiência em Scripts para setup AlgumaMaioria das Testes código 70% dos testes do lab, massa experiência em automatizado dados ferramentas de testes código ocorrem aqui foca aqui Caixa Preta Caixa Branca Testes API
- 27. Visual Studio 2010 Generalista Especialista Testes manuais Algumas scripts Scripts Codificação Grande experiência em código Scripts para setup do Alguma experiência Testes automatizado lab, massa dados em código Load Test Web Test Microsoft Test Runner Coded UI Test Unit Testing Gerenciamento de casos de teste Gerenciamento de laboratórios Coletores de dados (IntelliTrace™, Impacto de testes, Metricas…) Team Foundation Server Relatórios
- 28. Analista de Qualidade −Gestão/Planejamento de Testes − Testes manuais − Testes Unitários − Testes Funcionais de UI − WinForms, WPF, IE − Testes de Desempenho − Web sites − Carga / estresse
- 29. Testes Funcionais www.actiongroup.com.br
- 30. Execução e Automação −Ferramenta independente − Permite a execução de casos de teste − Coleta dados de sistema e logs de eventos − Captura imagens de tela e vídeos − Automatiza testes de aplicativos Windows Forms, WPF e Web
- 31. Derrubando as barreiras − Bugs ricos − Passos reproduzidos automaticamente − Vídeos como evidência − Informações de sistema − IntelliTrace™ − Imagens do ambiente de testes completo
- 32. Testes de Cargae Desempenho Com usuários virtuais ilimitados!
- 33. Gestão Laboratórios Integrado − Rapidamente restaura/derruba um ambiente − Bugs podem guardar imagem do ambiente − Integração com processo de build
- 35. O que buscamos? −Qualidade − Evolução − Chega de apagar incêndios
- 36. Perguntas do diaa dia…
- 37. O que temque ser feito? Sistemas novos − UML − Component Diagram − Class Diagram − Sequence Diagram − Activity Diagram − Use Case Diagram
- 38. Mas como fazer? Sistemas existentes − Entendo sistemas existentes − Código pode ser de difícil manutenção. − Identificação via DEBUG − Qual o fluxo atual do sistema? − Quais são suas dependências?
- 39.
- 40.
- 41. Estamos fazendo certo? Garantindo qualidade − Comunicação e Integridade − Informar ao time qual modelo seguir. − O mais importante garanta que eles estão seguindo.
- 42.
- 44. Adriano Bertucci Especialista em Soluções ALM Microsoft MVP Visual C# @adrianobertucci adriano@bertucci.com.br adriano.bertucci http://www.adrianobertucci.com