Aula06-estratégias do Processo de Teste de Software

Qualidade e teste de software\nAula 6: Estratégias do processo de Teste de Software\nApresentação\nSem estratégia, até a nossa vida pode não ser como esperávamos. Assim também acontece com os softwares.\nPor isso, aqui vamos conhecer as estratégias de teste e de desenvolvimento de software. Saberemos como definir as estratégias entre as atividades de desenvolvimento e teste.\nComo um dos pontos importantes, vamos identificar onde e quando utilizar, diferenciar e reconhecer testes caixa branca e caixa preta, além das abordagens de teste.\nObjetivos\n• Definir estratégias de teste de software;\n• Demonstrar as estratégias de teste;\n• Contrastar caixa branca de caixa preta.\nEstratégias de teste de software O planejamento e a realização das atividades de teste definem a estratégia de testes de software.\nUma estratégia de teste de software:\nDefine, para cada etapa do processo de engenharia de software, técnicas de projeto de casos de teste e métodos de teste específicos.\nIntegra, em uma série bem planejada de passos que resultam na construção bem-sucedida do software, métodos de projeto de caso de teste.\nAcomoda testes de baixo e de alto nível.\nOferece orientação ao profissional.\nDeve ser mensurável.\nIntegra métodos de projetos de casos de teste em uma série bem planejada de passos, objetivando a construção bem-sucedida do software.\nAtenção\nEm um primeiro momento, você pode não entender, mas o software é testado para promover erros que foram feitos inadvertidamente no momento em que foi construído.\nLeia o texto para conhecer quem faz a estratégia e a atividade de teste. Estratégia e atividade de teste\nQuem faz a estratégia e a atividade de teste?\nEstratégia de teste de software: desenvolvida pelo gerente de projeto, o engenheiro de software ou o analista de teste.\nAtividade de teste: a equipe de desenvolvimento de software e, para grandes projetos, um grupo de teste independente.\nAtenção: Atividades de teste e de depuração são atividades diferentes, mas a depuração deve acontecer em qualquer estratégia de teste.\nPor que é importante?\nO teste responde (e é responsável) por mais esforço que qualquer outra atividade de engenharia de software. Caso seja feito ao acaso, teremos tempo e esforço desperdiçados.\nQuais são os passos?\nVejamos por uma visão bem simplista: o teste começa no \"varejo\" e acaba no \"atacado\". Mas o que seria isso?\nO varejo são os testes unitários, e o atacado são os testes de integração, depuração na satisfação dos requisitos do cliente.\nCaracterísticas genéricas e estratégias de teste:\n• Teste efetivo - A equipe deve conduzir revisões técnicas formais (erros serão eliminados antes do teste);\n• Início do teste - O teste começa no nível de componente e segue \"para fora\", em direção à integração de todo o sistema;\n• Atividade de teste - Inicia-se no nível de módulos e prossegue para fora, na direção da integração de todo o sistema;\n• Diferentes técnicas de teste são apropriadas a diferentes pontos de tempo;\n• Fornecem roteiro - Descrevem os passos a serem conduzidos como parte do teste, como:\n - Quando os passos são planejados e executados?\n - Quanto de esforço, tempo e recursos são necessários?\nO que deve incorporar uma estratégia?\n • O planejamento de teste;\n • O projeto de casos de teste;\n • A execução e o teste;\n • A coleta e a avaliação de dados (resultado).\nImportante: A estratégia deve ser flexível, para promover um planejamento razoável e acompanhamento gerencial ao projeto.\nVeja, a seguir, um exemplo de uma estratégia (workflow) para sistemas bancários multicanais. Testador\n\nPlanilha Excel com casos de teste do canal website\n\nWebsite\n\nPlanilha Excel com casos de teste do canal dispositivo móvel\n\nDispositivos móveis\n\nPlanilha Excel com casos de teste do canal caixa eletrônico\n\nCaixa eletrônico\n\nPlanilha Excel com casos de teste do URA\n\nURA\n\nPlanilha Excel com casos de teste do canal central de atendimento\n\nCentral de atendimento\n\nVejamos o que acontece nessa estratégia de teste: como não foi realizado por outros canais, ficou evidente que não foram realizados testes multicanais, e nesse caso, todos os participantes (em separado) têm a percepção de que os testes realizados pelo canal foram satisfatórios. Algumas estratégias de teste\n\nTeste de unidade\n\nÉ caracterizado por concentrar-se em cada unidade do software, de acordo com o que é implementado no código fonte.\n\nCada módulo é testado individualmente, garantindo que ele funcione adequadamente.\n\nUtiliza as técnicas de teste de caixa branca.\n\nTeste de integração\n\nÉ caracterizado por concentrar-se no projeto e na construção da arquitetura de software.\n\nOs módulos são montados ou integrados para formar um pacote de software.\n\nUtiliza principalmente as técnicas de teste de caixa preta.\n\nTeste de validação\n\nOs requisitos estabelecidos como parte da análise de requisitos de software são validados em relação ao software que foi construído.\n\nAo término da atividade de teste de integração, o software está completamente montado como um pacote.\n\nOs erros de interface foram descobertos e corrigidos, e uma série final de testes de software – os testes de validação – pode iniciar-se.\n\nTeste de sistema\n\nCaracteriza-se por testar, como um todo, o software e outros elementos do sistema.\n\nEnvolve uma série de diferentes testes, cujo propósito primordial é pôr completamente à prova o sistema baseado em computador. Alinhamento estratégico\n\nComo fazer para que a busca pela melhoria do desenvolvimento de software seja realmente efetiva?\n\nPodemos alinhar a engenharia de software aos objetivos de negócio da empresa.\n\nAtenção\n\nAs decisões e rumos tomados pelas áreas que utilizam a Engenharia de Software devem sempre estar alinhados à estratégia da empresa, fazendo com que a área de desenvolvimento se torne uma ferramenta para aumentar o valor do negócio da organização.\n\nNesse caso, é necessário que as empresas associem a Engenharia de Software às melhores técnicas a serem adotadas pelos profissionais relacionados com a produção de software. Será que todas as empresas têm essa visão ou apenas uma visão limitada?\n\nTemos basicamente três níveis na empresa. A Engenharia de Software não deve apenas ficar no nível operacional, pois este cobre apenas parte das dificuldades, sendo que os problemas de maior impacto na organização aparecem nos níveis tático e estratégico.\n\nExemplo\n\nAs empresas frequentemente apontam que sua área de desenvolvimento de software não conhece ou entende seu próprio negócio;\n\nQue utiliza indiscriminadamente tecnologias e ferramentas em seus produtos sem se preocupar se haverá ganho ou se o cliente está preparado para absorvê-las;\n\nQue se preocupa tanto com as próprias atividades que cria obstáculos, burocracia ou dificuldades para ser acionada por outras áreas;\n\nEmpresas que, por exemplo, atuam desenvolvendo produtos de software personalizados para outras organizações têm por estratégia minimizar seus custos.\n\nAssim, as práticas adotadas devem favorecer essa estratégia, tais como:\n\nImplantar processos e ferramentas que tornem o desenvolvimento mais barato, já incluídos os custos da execução do processo e das licenças (no nível operacional).\n\nGerenciar e reduzir a ociosidade da equipe no período entre-projetos (no nível tático).\n\nEstabelecer um programa corporativo de premiação de produtividade (no nível estratégico).\n\nAgora que entendemos que a Engenharia deve atuar nos três níveis (Estratégico, Tático e Operacional), seus princípios de melhoria cíclica (processo de melhoria contínua) podem ser aplicados com sucesso.\n\nExemplo de um ciclo de melhoria:\n\nPrimeiro é feito um diagnóstico sobre como o desenvolvimento de software na empresa precisa melhorar, em todos os níveis;\n\nDepois, os itens diagnosticados são priorizados com base no impacto no negócio, e os mais críticos são escolhidos;\n\nAções para resolver os itens selecionados são então definidas e implementadas, observando o que precisa ser feito para que a ação se exerça resultados efetivos em todos os níveis;\n\nFinalmente, avalia-se o resultado da solução e o impacto positivo nos negócios. As soluções de Engenharia de Software sempre contribuirão para agregar valor ao negócio com esses ciclos de melhoria adequadamente aplicados, e o software será efetivamente uma peça fundamental na estratégia da empresa.\n\nTeste caixa branca e teste caixa preta\n\nExistem duas estratégias utilizadas para conduzir o processo de validação de software.\n\nCaixa branca\nCaixa preta\n\nEstas estratégias não são excludentes; muito pelo contrário, elas são complementares.\n\nConhecendo os detalhes internos de um produto, os testes são executados para assegurar que 'todas as engenharias estejam articuladas', assim:\n\n- Operação interna de acordo com a especificação;\n- Todos os componentes internos foram adequadamente exercitados (teste caixa branca [aberta], white-box testing, teste estrutural).\n\nConhecendo-se a função que um produto deve realizar, os testes são executados para demonstrar que cada função está completamente operacional (teste caixa preta [fechada], black-box testing, teste funcional).\n\nCaixa branca\n\nArquitetura interna do software\n\nEstrutura de controle (programa)\n\nCaso de teste\n\nTécnicas empregadas no teste caixa branca\n\nAvaliação das estruturas de sequência, decisão e repetição, através da simulação de situações que exercitem todas as estruturas utilizadas na codificação adequadamente.\n\nVamos entender o que é um caso de teste, utilizado em teste caixa branca e preta.\n\nÉ o documento que registra todo o planejamento dos testes e o que será testado. Deve identificar o maior número de cenários e variações possíveis, assim como os resultados esperados. Normalmente o desenho de um cenário de teste é mental. Leia o texto para entender melhor sobre o Teste caixa branca e Teste caixa preta.\n\nTeste caixa branca e Teste caixa preta\n\nClique no botão acima. Teste caixa branca\n\nO teste caixa branca é feito a partir das estruturas de controle do programa, através do maior número possível de cenários de testes que atendam ao maior número possível de situações.\n\nExemplo:\n\nCaminho A\n\nInício do processamento\n\nCaminho B\n\nTérmino do processamento\n\nNota(s) para grafo de fluxo (de programa) (Fonte: AUTOR / Shutterstock).\n\nNó(s) do grafo de fluxo\n\nArestas do grafo de fluxo\n\nSequence\n\nIf-then-else\n\nDo while\n\nRepeat until\n\nCase\n\nExemplo:\n\nProcedimento média(valor[])\n\ni=1;\n\nsoma=0;\n\ntotal.entrada=0;\n\ntotal.válidas=0;\n\nFaça-Enquanto (valor[i] \u003c= 999 e total.entrada\u003c 100)\n\nincremente total.entrada de i;\n\nSe (valor[i] \u003c= valor[i_max])\nEntão\n\nincremente total.válidas de i;\nsoma = soma + valor[i]\n\nFim-Se\n\nincremente i de 1;\n\nFim-Enquanto\n\nSe total.válidas\u003c= 0\nEntão média = soma/total.válidas;\nSenão média = -999;\n\nFim média O teste caixa branca é considerado um teste procedural. Então, quais são os exames de detalhes desses testes procedurais?\n\nTeste de caminhos lógicos - Casos de teste para exercitar conjuntos específicos de condições e/ou laços;\nO estado do programa - Examinando em vários pontos para determinar se o estado esperado ou declarado corresponde ao estado real.\n\nImportante: Não é possível testar todos os caminhos lógicos de um programa grande.\n\nA abordagem deste tipo de teste tem as seguintes peculiaridades:\n\n• Seleção de um número limitado de caminhos a serem exercitados;\n• Estruturas de dados importantes podem ser investigadas para validação;\n• Pode haver combinação dos dois tipos de teste, funcional e estrutural, para validar a interface do software e assegurar (seletivamente) que as operações internas do software estejam corretas.\n\nA estrutura de controle do próprio procedimental deve ter casos de teste que:\n\n• Garantam que todos os caminhos independentes dentro de um módulo tenham sido percorridos pelo menos uma vez;\n• Exercitem todas as decisões lógicas em todos os seus ramos de saída;\n• Executem todos os laços nos seus limites e dentro de suas fronteiras operacionais;\n• Examinem estruturas de dados internas para assegurar sua validade.\n\nModelo de caso de teste de RUP\n\nDescrição do caso de teste\nUma descrição da condição, caminho do programa ou objetivo que este conjunto de dados implementa / executa.\n\nEntradas de teste\nOs objetos ou campos que os atores interagem e os valores dos dados de entrada pelo ator quando executa este caso de teste.\n\nResultados esperados\nEstado resultante ou dado recebido após completa execução do caso de teste.\n\nExemplo de caso de teste\nId\nCenário / Condição\nDados de entrada\nResultados esperados\n1112\nEfetuar login - Operação com sucesso\nLogin - Válido\nPassword - Válido\nUsuário logado, página principal exibida\n\nTeste caixa preta\nOs testes caixa preta, também conhecidos como testes comportamentais, destacam os requisitos funcionais do software e utilizam técnicas para garantir que os requisitos do sistema sejam amplamente atendidos pelo software construído.\n\nEsses testes não requerem o conhecimento da tecnologia empregada e dos conceitos de implementação do software, o que os diferencia dos testes caixa branca.