Resumo Slides Paulo Borba com Resoluções de Questões

Introdução - Relevância da qualidade do SW - Disponibilidade de serviços importantes - Sequência dos processos - Impacto Prático - Competitividade das empresas - Atração de empresas novas p/ ecossistemas locais - Problemas no desenvolvimento de SW: - Taxa de cancelamento de proj. de 18-40% - Desenvolvimento c/ custo muito acima da estimativa em 33-53% dos projetos analisados. - 75% dos proj não funcionam da maneira planejada. - Difícil reutilizo e manutenção. - Causas principais dos problemas com SW - Aumento da complexidade do sistema. - Dificuldades na personalização e custos. - Causas adicionais: - Falta de educação apropriada. - Má qualidade de linguagem, documentos, técnicas e processos. - Problemas de organização e conflitos e expectativas / conflitos. - Qualidade do SW, foco em valores éticos e de negócios: - Correto - Robusto - Extensibilidade - Reusabilidade - Compatibilidade - Confiabilidade - Fatores internos e externos - Performance - Escalabilidade - Integridade, privacidade e segurança. - Usabilidade - Flexibilidade - Tolerância a falhas - Não somente qualidade, mas produtividade também: - Custo de desenvolvimento reduzido - Empresa produtora diz que faz a “SW barata”. - Tempo de desenvolvimento reduzido = Rápido superação as necessidades do mercado.\n- “SW barato”: não é somente resultado de menores custos de desenvolvimento, mas também da capacidade de servir melhor a cliente. - Imerso entre qualidade e produtividade. - Investir muito em qualidade pode reduzir produtividade a custo prazo. - Negligência qualidade pode impactar a produtividade até no curto prazo. - Ética profissional não deve fazer parte da troca. Requisitos - Inicialmente responder essas perguntas: - Quem usa o SW? - O que são os requisitos do sistema? - Requisitos funcionais - Quais funcionalidades do SW seguem o sistema? - Requisitos funcionais - Quais fatores de qualidade do SW seguem dessas funcionalidades? - Requisitos não-funcionais - Entendendo prioridades - Quais requisitos são mais importantes? - 2 atitudes principais - Elítica os requisitos - Especificação de requisitos - Elaticação de requisitos - Interagindo c/ ST e entrevistados. - Obs: baseando-se nos fidelidade do GUI e storyboards - ST ceme o tema de, de uma vez. - Foco inicial: entender as necessidades do ST - O que se espera desse sistema? - Funcionalidades principais? - Fatores de qualidade específicos? - Refinamento - Fazer + requisitos p/ que cenários fiquem + detalhados e novas features auxiliares sejam identificadas - Desenhar e discutir lo-fi GUI abordáveis e storyboards. - Confirmar expectativas - Especificação de requisitos - Documento de requisitos - Feature (user story) - Feature: [<nome>] - Asa, <kind of ST>] - I want to [do some task] - so that [I can achieve some goal] - Cenários de feature -> Scenarios: - Given - When - Then - Foco em caminhos de execução concretos - Viés de teste, outros caminhos serão usados com testes. - Especificando melhor o comportamento do sistema - Necessidades de complementar exceções /falto - Excepções falhas e outros estados do GUI minados e o que acontece quando - títulos elementos não usados. - Cenários de exceção ou de comportamento não mencionados ou não usados em navegadores. - Foco em caminhos mais relevantes e complicados: requisitos, regras, restrições, sequencia de eventos e casos etc. - Evitar redundância. - Caminhos de GUI - repro e.g. diretamente o elementos do GUI, eventos e navegação da forma abstrata. - Evitar baixa abstração de ações em cenários - Comandos declarativos, não imperativos! - Mais sobre cenários de GUI: foco nos comportamentos do sistema no geral e visual, foco nos usuários e estado da navegação. - Complementam cenarios de controlador. - Quentes e quais casos? Mirnar na cobertura de cenários - relevantes, poucos cenários há. - Comportamentos de sistema verificar: minar em consistencia p/ simplicidade é imperissivel. - C focos na: Specific, Measurable, Achievable, Relevant, and Timeboxed. - Foco em requisitos funcionais - Requisitos pode ser difícil (when there’s a connection error) - Correção fl: when 2 pessoas... - Positivo ou negativo. - Check List / Quesões - Deve reflectar as necessidades do SW - Demonice deve correspondente constantemente à semantic da cenarios - Preciso, p.ex’espace para pequenos números de poses do scenario (use. And good proces.) - Não duplicque partes do cenarios. - Nãos duplicque cenarios. - Não deve ficar vaga ou incompleta. - Parametrige dos passos dos cenarios. - Especificar ações, mas não ações nor ações orgãos. - Evitar base de llenguaçem - Use active da alto colon. - Enxugar cenários indepentes de plataforma (forr message confirmation message any page) - Foco na situação de teste, direte ao ponte - Proposta diferentes - e não requisitos de geral. - Resposta di questrões - Os poses não ferom suficientemente mencionados, no When restricted ação do alto nivel e fase age ao valor da percepção duriente. Principla problema pa apresentagão! - Given estou logged com “lancez”. - And aces no “pagina: disciplinado do semestre. - When selectiço first linha. - And preencho am neta do “for com" g - O principal problema è que qualquer modo null ação do baixo nivel (de estranegão)} des focando da situacão de teste é em for dueate ao peso ponto. - Given estou na pagina inicial - With addicaoe i filme “Zorro” boxing campo de's - And acessice: “Apocalypse wow” com 1000 - Then keeps. “Apocalypse bow” antes da “Zorro” na lista ordenada. 3) testado mais posteriormente talm bem essenciais qualidade. 4) Essão 4: escopo, tempo, qualidade e custo. Uma consequência e: quando se precisa qualidade. de escopo os danos do seu projeto negativo e tempo e ter custos altíssimos e péronomica. Outra consequência e: se projeta-se tempo e qualidade e seu escopo tera que diminuir considerevelmente pil poder respected código com qualidade alta decendido em tem po custo. Testes - Testes de aceitação - Caracterizam diretamente requisitos (cenários) e testes. - Executa o sistema através de sua GUI. - Quando cenários baseados na GUI com passos da testes baseados na GUI. - Pense executam o sistema em teste simulando ações do usuário no browser. - Aplicação como uma máquina de estados - Grafo representando estados e possíveis transição. - Comportamento operado pela transição deve aparecem como caminhos nesse grafo, comportamento não-aparece não deve aparecem. - Quando deserv verifica que caminhos desejados possam ser observados testando o app. - Execução e sistema através de servidor - Caminho baseado em serviços são conectados a passos de testes baseado em serviço. - Execução sistema e sistema em teste incoming serviço. - Testes da execução (unidade, integração. sistema) - Testes e execução não têm ligação com cenários, mas descrição e it. - Aplica-se em métodos num nunca: aleatório,41/,//All/al/l é a ever-de-escreva/ que reque/envio serviço - Código executa e sustentam incoming serviço. - Testes do alunos (unidade, integração) - Caminhos de execução, nenhum ligação com cenários: - Interface API. - Código executa e sustentam incoming metodos. - Princípios para todo teste: - Rode teste com diferentes argumentos e conteúdo de estado. - De cases limite/dá/cenÃrios, foco na cobertura. - Cases positivos e negativos. - Teste de regressão – e ver se nova commit quebrou alguma funcionalidade. - Balanceamento entre – Leads, Atacasce “service, class e asftacão”. - Se unidade e integração - Práticas para todo teste: - Automaticação - Cada teste pode rodar independentemente dos outros, assumindo uma nova instancia de app. - Pense estados entre possos - Antes de dev push (ao ver ao commit), tenha c/q que todos testes passam (regressivas). - BDD: behavior driven design. - Implementação de testes e feita antes da implementacão dos fechores. - Criação da interface quanto pouco funcionalidade está disponível. - Checkout - Comportamento do teste deve corresponder estritamente à semântica de codi enário. - Evi te ambiguidades duvida de passos (setenccos) comi/flows. - Não dupique cédigo de teste Tests devem ser independentos de plataforma - Os ambientes limpas e ambiente no limn (incluindo browser e de linguagem). Refatoração - Problemas de reúso - Problemas de manutenibilidade - Débito Técnico - Manutenção custa caro - 1ª lei de Lehman Programas que nunca ou já ficam num processo de mudança contínua ou se tornam progressivamente raramente funcional. - Processo de mudança continua até que seja julgado não ser efetivo (em relação aos custos) substituir o sistema por uma versão reescrita - 2ª lei de Lehman Enquanto um grande programa e continuamente mudado, sua complexidade, a qual reflete na deterioração da estrutura, aumenta a não ser que trabalho seja feito p/ manter ou reduzir a 2ª lei. - Como reverter os problemas e reduzir o débito? Redesenhando os comportamentos (reescrita do texto) - Refatoração: precisa complementado p/ oferecerem p/ “source-to-source” que melhoram fatores de qualidade internos (como legibilidade, reuso, etc) - To Revaiser quartos são - Extract method refatoração - Para resolver problemas de reúso e manutenibilidade - Crie nos métodos com trechos de código anterior p/ evitar repetição de varias linhas - Reduz dívida e elimina-le - Refatoração automatizada - Esses rearranjos não dão nenhuma garantia de preservação de comportamento (estes devem ser aplicados tal qual como antes). - Extract class - Quando a classe está fazendo trabalho que deveria ser feito por 2. - Cria-se uma nova classe e transfere os campos relevantes e métodos da classe antiga p/ a na - Métodos são monomentu e necessários de que não entes abstrato. Pl/reclrs po. - Como escolher os outros da refatoração? - Mou chutes baseados em valores, princípios e padrões. - Estabeleça: 1) Identifique o problema,2) Há algum padrão p/ o problema aonde tentou? 3) Ní. c solução baseada em valores e princípios? 4) aplique refatoração apropriada, 5) Testa - Questões 1) teste de regressão e aquele que verifica se a alteração feita no código quebrou algo que antes do mudança estava funcionando. Benefício para a refatoração seu teste validando ela que preserva função, o comportamento do código, e que o teste ao regressão verifica. 2)Questão uma classe está fazendo um trabalho que deveria ser de 2, por exemplo uma classe que implementa um preço fornecedor possui muitas características, atributos, especificas eu felz feice old). 1) cria-se uma nova classe e distribua os campos e métodos relevantes a cada classe (antiga e nova).