Carregado porAdriano Bertucci
Qualidade - Porque testar seu software?
O documento discute a importância dos testes de software para garantir a qualidade e evitar falhas caras e potencialmente catastróficas. Ele fornece dez exemplos históricos de desastres causados por bugs de software que poderiam ter sido evitados com testes adequados, e argumenta que a automação e integração dos testes no ciclo de desenvolvimento de software pode melhorar a qualidade e reduzir os riscos.
Mais conteúdo relacionado
![[UNIP2015] Testando a Performance de Aplicações Web com JMeter](https://cdn.slidesharecdn.com/ss_thumbnails/palestraunip-151006101948-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Semelhante a Qualidade - Porque testar seu software?
![[GUTS-RS] GUTS Universitário - UNISINOS Campus POA](https://cdn.slidesharecdn.com/ss_thumbnails/guts-rsuniversitrio2016-160501151417-thumbnail.jpg?width=640&height=640&fit=bounds)
Qualidade - Porque testar seu software?
- 1. Qualidade Por que testarseu software? Adriano Bertucci Microsoft Visual Studio ALM MVP adriano.bertucci@konia.com.br Twitter: @adrianobertucci Charles Santana Consultor ALM e EPM Charles.santana@konia.com.br Twitter: @charlessantana0
- 2. Quem sou eu? •Sócio/Diretor Konia Tecnologia; • Microsoft Visual Studio ALM MVP; • Palestrante Microsoft; • Adora jogar FIFA no XBOX; • Torcedor do SC Corinthians Paulista! adriano.bertucci@konia.com.br Twitter: @adrianobertucci
- 3. Qualidade uma necessidade Considerandoque desenvolvimento de software representa 25% dos gastos em software, identificar a causa dos problemas e falhas nos projetos de desenvolvimento se torna uma necessidade.
- 4. Qualidade uma necessidade − Osucesso de um projeto de software pode ser definido por um triângulo: Tempo (Prazo) Orçamento (Custo) Funcionalidades − Funcionalidade Qualidade 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
- 5. Caminho para osucesso... Ideia Solução
- 6. Como chegamos atéaqui?
- 7. 1 Em 1983, umaIII Guerra Mundial, quase teve início, devido a um bug no software de alerta Soviético. A falha fez com que o software mostrasse que os E.U.A. tinha lançado cinco mísseis. A nosso sorte, foi que o Tenente Coronel Stanislav Petrov, considerou que a informação estava errada e não ordenou o contra-ataque, evitando assim o inicio da III Grande Guerra.
- 8. 2 Em 1990, umbug numa central telefônica da AT&T deixou milhões de pessoas nos EUA sem comunicação de longa distância. O erro ocorreu num break do código C, que não foi testado corretamente. “IF YOU CANNOT TEST IT, DO NOT DO IT.”
- 9. 3 No primeiro lançamentoda série Ariane 5, em 4 de junho de 1996, menos de um minuto após o lançamento, o foguete francês Ariane 501 se autodestruiu. A falha ocorreu devido a uma anomalia interna de software, que ocorreu durante a execução de uma conversão de dados de um número de 64 bits em ponto flutuante para um inteiro de 16 bits com sinal. O valor do número em ponto flutuante era maior do que poderia ser representado pelo inteiro de 16 bits com sinal. O resultado foi um operando inválido, que acabou gerando a falha.
- 10. 4 Alguns dos problemase atrasos no lançamento do maior avião do mundo, o Airbus A380, foram as incompatibilidades das diferentes versões usadas do software de projeto e desenho mecânicos CATIA. Enquanto os sócios franceses utilizavam a última versão, a fábrica alemã não tinha ainda atualizado a mesma.
- 11. 5 Em 1998, umerro na navegação da nave espacial Mars Polar Lander fez com que ela voasse muito baixo e se espatifasse contra o solo. A falha foi devido a uma empresa terceirizada que confundiu o sistema de medidas americano e europeu.
- 12. 6 Uma falha naatualização do software empregado no Ministério do Trabalho e Pensões britânico, realizada pela empresa EDS, custou aos contribuintes mais de 1 bilhão de libras em 2004.
- 13. 7 O efeito dofamoso bug do milênio e os bilhões gastos para evitar o temido desastre que felizmente não sucedeu.
- 14. 8 Explosão de umlaptop da Dell em uma feira de negócios no Japão em 2006, diante da imprensa e da câmeras, registrando ao vivo, os relatos de consumidores da marca sobre acidentes do mesmo tipo ocorridos anteriormente.
- 15. 9 Um novo sistemade informática da poderosa Siemens para controlar a emissão de passaportes implantado em 1999 sem testes suficientes e sem pessoal qualificado para seu manejo, amargurou as férias de meio milhão de britânicos.
- 16. 10 Em 2007, umasimples placa de rede defeituosa não permitiu que parte dos 17.000 aviões do aeroporto de Los Angeles levantasse vôo.
- 17. “Rigorosos testes emsistemas e documentações podem reduzir os riscos de ocorrência de problemas no ambiente operacional, e contribui para a qualidade dos sistemas de software se os defeitos encontrados forem corrigidos antes de implantados em produção.” (Syllabus BSTQB, 2007) Os dez maiores desastres envolvendo TI, poderiam ter sido evitados com o teste de software.
- 18. 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.
- 19. Futuro • Aplicações emambientes complexos e distribuídos • Software + Serviços • Tecnologia Multi-Touch, Tables, Smarphones, etc.
- 20.
- 21. Í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%
- 22. Impacto no desenvolvimento Desenvolvedoressentem-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
- 23.
- 24. 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
- 25. POG é inadmissível! •Por isso temos que estudar!
- 26. O que fazer? •Padronizar • Arquitetar • Testar • Ter atitude • Capacitar • Organizar • Integrar • Fazer manutenção • Entregar rapidamente
- 27. Solução? ALM! • ALM(Application Lifecycle Management, Gerenciamento do Ciclo de Vida de Aplicações): • É a coordenação das atividades do ciclo de vida de desenvolvimento, incluindo requisitos, modelagem, desenvolvimento, construção, testes, manutenção e operações
- 28. Desenvolvedor Designer Profissional de Banco deDados Arquiteto Testador Gerente de TI ou de Projetos Analistas de Negócios Relatório em Tempo Real Defeitos – Bug Tracking Controle de Tarefas Requisitos de Negócios Controle de Versão Avançado Metodologia & Processo de Desenvolvimento Automação de Compilação (build) Testes Web Teste de Carga Testes Unitários Análise de Código Documentação de Projeto Ferramentas de Arquitetura Ferramentas para Banco de Dados
- 30. Por que testar? Testede Software
- 45. Conceitos Básicos Teste deSoftware
- 46.
- 47. Testes - Conceitos •Caso de Teste • Procedimento de Teste • Critério de Teste
- 48. Segmentação dos testes Generalista Testesmanuais Especialista Algumas scripts Scripts Scripts para setup do lab, massa dados Alguma experiência em código 70% dos testes ocorrem aqui Codificação Testes Maioria das automatizado ferramentas de testes foca aqui Grande experiência em código Caixa Preta Caixa Branca Testes API
- 49. Visual Studio 2012 Generalista Testesmanuais Especialista Algumas scripts Scripts Codificação Grande experiência em código Scripts para setup do lab, massa dados Alguma experiência em código Testes automatizado Load Test Web Test Coded UI Test Unit Testing Microsoft Test Runner Gerenciamento de casos de teste Gerenciamento de laboratórios Coletores de dados (IntelliTrace™, Impacto de testes, Metricas…) Team Foundation Server Relatórios
- 50. Ciclo de Vidados Testes Cenário Automação Planejamento Validação Especificação Execução
- 51. 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
- 52.
- 53. Testes de Cargae Desempenho Com usuários virtuais ilimitados!
- 54. 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
- 55. Derrubando as barreiras •Bugs ricos • Passos reproduzidos automaticamente • Vídeos como evidência • Informações de sistema • IntelliTrace™ • Imagens do ambiente de testes completo
- 56. Gestão Laboratórios Integrado •Rapidamente restaura/derruba um ambiente • Bugs podem guardar imagem do ambiente • Integração com processo de build
- 58. Science to Business Copyright– Direitos autorais Copyright © 2011-2013 Konia Tecnologia. Este documento é inédito e a advertência precedente é fixada para proteger Konia Tecnologia. no caso de publicação não autorizada. Todos os direitos reservados. Nenhuma parte deste documento pode ser reproduzida em qualquer forma, inclusive fotocópia ou transmissão eletrônica para qualquer computador, sem autorização prévia por escrito de Konia Tecnologia. As informações contidas neste documento são confidenciais e propriedade da Konia Tecnologia. e não podem ser usadas ou reveladas exceto quando expressamente autorizado por escrito por Konia Tecnologia.
Notas do Editor
- #51 Caso de Teste: descreveumacondição particular a sertestadae é compost porvalores de entrada, restrições para suaexecução e um resultadooucomportamentoesperadoProcedimento de Teste: é a descrição dos passosnecessários para executar um ouvárioscasos;Critério de Teste: serve para selecionar e avaliarcasos de teste de forma a aumentar as possibilidades de provocarfalhasou, quandoissonãoocorre, estabelecer um nivel de confiançanacorreção; Ex: Cobertura dos Testes
- #53 We have release a significant set of capabilities in the 2010 release around testing and more specifically around integration of testing and development. Testers don’t often like to spend time in Visual Studio, so we build a rich WPF application ground up for the testers and non-technical users so they can use it easily and not have to interact with development tools. However the ALM integration ensures that developers benefit from the work the testers are doing while working in their IDE.All of the capabilities are based on Team Foundation Server which provides the single unified view of a teams effort across a software project. We have introduced several data collectors that provide key insights that developers often need to resolve bugs. These include the IntelliTrace data collector which provides developers the ability to move back in time to find out how a bug was encountered. Notably present is also the Test Impact collector which provides testers visibility into what new test cases need to be tested when code is changed by the developers. Lab Management is a set of integrated capabilities that can be used across the developer and testers that eliminates wasted cycles in setting up & tearing down machines, proving access to environment snapshots so developers can connect to test environments to debug issues and more. Test case management allows teams to better manage their testing effort, get traceability across requirements and also help teams adapt testing efforts to agile, water fall or other processes. Coded UI is a new test type that allows specialist testers to do UI automation and integrate that into the TFS build workflow.Web & Load Testing continue to be improved from our previous releases and provide teams that ability to do performance, load and stress testing and makes these tools more affordable so more people in the team can do such testing. Microsoft Test Runner allows generalist testers to execute their planned or exploratory tests and allows them log rich bugs with rich data that developers need. Lets take a quick peek at specific capabilities that help break the walls between dev & test and how lab management integration into ALM eliminates waste across build hand off
- #59 Breaking Silo’s is possible because a the Rich Bug which includes information that is very valuable to a developers but at the same time is captured and attached to a bug with little to no effort on the testers part. Capturing information such as test steps, IntelliTrace and environment snap shot allows developers and testers to help eliminate the “no repro” situation.
- #60 Integrated lab management democratizes virtualization into the application lifecycle by allowing quick set up and tear down of complex multi machine environments allowing developers and testers to test in production like environments. Integrated snap shot on bug empowers the testers to auto attach a link to the environment they are testing on allowing developers to easily recreate problems. Integration to the build work flow and extending the build activities allows teams to automate their builds such that they 1) Build their application, 2) Create or restore their environment to a clean known state 3) deploy the bits on clean state environment 4) execute automated unit and automation tests such that the entire build work flow is automated eliminating a lot of wasted cycles for teams while waiting for a build and understanding the quality of the build.