Aula08-teste de Aceitação

Qualidade e teste de software\nAula 8: Teste de Aceitação\nApresentação\nNesta aula, vamos saber como desenvolver rotinas de teste com base no framework Cucumber e automação com o Selenium WebDriver. Vamos definir uma elaboração de testes de aceitação com o usuário final, identificar o relacionamento de requisitos e as expectativas de teste, conhecer as metodologias utilizadas para testes de aceitação. Por fim, vamos conhecer a técnica de BDD - Behavior Driven Development (Desenvolvimento Orientado por Comportamento).\nObjetivos\n• Investigar o desenvolvimento de rotinas de teste com base no framework Cucumber e automação com o Selenium WebDriver;\n• Elaborar testes de aceitação com o usuário final, relacionando requisitos e expectativas de teste às metodologias utilizadas para testes de aceitação;\n• Reconhecer as metodologias utilizadas para testes de aceitação e conhecer a técnica de BDD - Behavior Driven Development (Desenvolvimento Orientado por Comportamento).\nO que é um teste de aceitação? O teste de aceitação é aquele feito para aproximar o cliente final do resultado esperado pelo sistema. Já um teste de software é um processo sistemático que tem por objetivo identificar prováveis defeitos.\nPara isso, verifica-se se o software realiza suas tarefas de forma correta, conforme os requisitos fornecidos pelas partes interessadas do sistema e também se faz o que não deveria fazer.\nAlguns conceitos que devem ser entendidos:\n• Defeito Contêm um ato inconsistente realizado por um indivíduo ao tentar compreender uma informação. Pode ser uma instrução ou um comando incorreto.\n• Erro É um defeito encontrado em um artefato de software. Exemplo: diferença entre um valor obtido e um valor esperado.\n• Falha É o comportamento do software diferente do esperado pelo usuário final.\nExemplo de falhas: um bug gerado por um programador pode ocasionar um erro que irá gerar uma situação de inconsistência em uma determinada funcionalidade. Lembrar a regra de 10 de Myers.\nDesenvolvimento de rotinas de teste com base no framework Cucumber e automação com Selenium WebDriver\nFerramentas de teste automatizado de software\nUm projeto de automação de software é um investimento alto e de longa duração. Os dirigentes das organizações têm expectativas em relação a custos e aos benefícios trazidos pela sua implementação.\nCuidados a serem tomados:\n• Infraestrutura\n• Metodologia\n• Ferramenta É a disponibilidade de máquina e seus recursos. O projeto em desenvolvimento (em fase de testes) deve ser dedicado para o projeto de automação de testes.\nÉ a existência de metodologias de desenvolvimento e testes consolidadas e usadas, que possam se integrar com a ferramenta escolhida.\nSelecionar a ferramenta certa, adequada à tecnologia usada e que possa se integrar com as metodologias de desenvolvimento e teste.\nQuais casos de testes são candidatos a automatização?\n• A cada nova versão de um software, será necessário realizar um novo conjunto de testes, ampliando as melhorias que foram implementadas.\n• É necessário reexecutar um conjunto de casos de testes (todos ou partes), de forma a avaliar se as mudanças realizadas danificaram ou modificaram outras partes de software que já funcionava.\nPara isso, precisamos ter a seguinte situação:\nPreparação do ambiente Execution de testes Conferência dos testes\nOs testes automatizados não podem substituir os testes manuais; eles são complementares.\nAtenção\nTodo caso de teste é naturalmente candidato à automação, mas com toda a certeza nem todos são recomendados para a automação.\nAutomação com ferramenta Cucumber\nA automação de testes é o processo da escrita de um programa para executar esses testes funcionais.\nVantagem:\n• Economia de tempo e recursos durante a execução dos testes;\n• Possibilidade de executar os mesmos testes repetidas vezes.\nPor que automatizar os testes?\nPor causa da qualidade final do produto, pois a execução de todos os testes funcionais que existem no sistema garante uma. Cucumber\nO Cucumber é um framework BDD (Behavior-Driven Development ou Desenvolvimento Orientado a Comportamentos), de código fonte aberto, baseado em RSpec.\nO programa executa testes de aceitação automatizado escrito em estilo de BDD. Tem um analisador de linguagem simples chamado Gherkin, que permite que os comportamentos esperados sejam especificados em um idioma lógico, para que os clientes possam entender.\nTrês passos para tratarmos o Cucumber:\nEscrever uma estória e executá-la (feature); Criar o arquivo de passos a partir dos snippets; Dar implementação aos passos.\nExemplo: o objetivo de negociar de câmbio que contém um banco e conta bancária.\nNesses exemplos, vamos ver as funcionalidades que devemos assegurar que operem:\nPrimeira: consiste em possibilitar que o usuário realize as operações de câmbio utilizando sua conta, como:\n1.1. Fazer saque e depósito, considerando as seguintes restrições:\n1.1.1. Só liberar o saque se o valor deste for menor ou igual ao valor do saldo disponível na conta;\n1.2. Só liberar o depósito se o valor deste for menor ou igual ao limite disponível na conta.\nSegunda: possibilitar o usuário a realizar operações básicas de câmbio no banco, que são:\n2.1. Obter o total de dinheiro no banco; 2.2. Obter o total de contas criadas no banco.\nPara utilizar o Cucumber em nossos testes, precisamos instalar a Gem, a fim de que o programa em Ruby possa entender o contexto e ter seus comandos reconhecidos.\nComo conseguir isso? Digitando o comando 'gem install cucumber' no Cmder e pressionar [Enter].\nAo final da instalação, use o teste, e confira os passos são executados com sucesso. Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online\nSaiba mais\nVeja mais no vídeo: Cucumber\nClique aqui para visualizar todos os passos e o resultado da instalação, teste e uso do Cucumber e automação com Selenium.\nAtenção! Aqui existe uma videoaula, acesso pelo conteúdo online\nElaborando testes de aceitação com usuário final\nOs testes de aceitação fazem parte do teste de validação de alto nível. Nesses testes, os mecanismos estão segmentados em dois níveis:\nCaracterizam-se por exigirem dos profissionais de testes um profundo conhecimento da estrutura interna do produto.\nBAIXO NÍVEL\nTeste de unidade\nTeste de integração\nCaracterizam-se por não requerem esse conhecimento da estrutura interna, possibilitando testes com maior grau de abstração.\nALTO NÍVEL\nTeste de sistema\nTeste de aceitação\nQuando terminamos a atividade de teste de integração, o software já está completamente montado. Os erros de interface foram descobertos e corrigidos, e precisamos iniciar mais alguns testes finais de software (que são os testes de validação).\nSe pensarmos apenas no teste de alto nível, encontramos o teste de aceitação.\nALTO NÍVEL\nTeste de sistema\nTeste de aceitação\nNo teste de aceitação, é impossível prever como o cliente realmente usará um programa. As instruções de uso podem ser mal interpretadas, e combinações anômalas de dados acabam sendo usadas. O teste de aceitação é de responsabilidade do cliente\nDependendo da abrangência dos usuários, podem ser aplicados de duas maneiras:\nSoftware customizado para um cliente.\nSoftware desenvolvido como produto para muitos clientes.\nSão utilizados testes alfa e teste beta.\nTestes de aceitação devem ser definidos pelo cliente e conduzidos pelo usuário final, a fim de validar todos os requisitos do cliente.\nEstratégias comuns para implementar um teste de aceitação:\nAceitação formal. Aceitação informal ou teste alfa. Teste beta.\nTeste de aceitação formal\nÉ um processo que necessita ser bem gerenciado e costuma ser uma extensão do teste do sistema. Pode ser totalmente automatizado.\nImportante: Não se distanciar de nenhuma forma dos casos de teste escolhidos.\nPode ser executado inteiramente pela coordenação do usuário final.\nVantagens:\nAs funções e os recursos a serem testados são conhecidos;\nOs testes podem ser automatizados, o que permite o teste de regressão;\nO progresso dos testes pode ser medido e monitorado;\nOs critérios de aceitação são conhecidos.\nDesvantagens:\nSão necessários recursos e planejamento significativos;\nOs testes podem ser uma nova implementação dos testes do sistema;\nOs testes podem não revelar defeitos subjetivos no software, já que são procurados apenas os defeitos esperados. Teste de aceitação informal\nOs procedimentos para executar o teste não são definidos com tanto rigor como no teste de aceitação formal. Nessa abordagem, o controle não é tão rigoroso como no teste formal.\nAtenção: Quem realiza esse teste é o usuário final.\nSe o software é desenvolvido como um produto a ser usado por vários clientes, é difícil realizar testes de aceitação com cada um. Nesse caso, usam-se os testes alfa e beta.\n\nTeste alfa\n- É conduzido na instalação do desenvolvedor com os usuários finais;\n- É realizado com base no envolvimento de um cliente ou numa amostra de clientes;\n- O software é utilizado num ambiente natural, sendo que o desenvolvedor observa o comportamento do cliente e vai registrando as anomalias detectadas durante a utilização.\n\nAmbiente de teste e homologação\n- Esse ambiente é o mais semelhante possível ao ambiente de produção;\n- Fornece toda a infraestrutura necessária de hardware e software para a execução dos testes de requisitos do software e garante o ambiente ideal de simulação.\n\nQuem utiliza este ambiente?\nQuais testes normalmente são aplicados neste ambiente?\n\nSistema e aceitação\nEsses testes são realizados através da técnica da caixa-preta, porque não requerem um conhecimento interno do software.\n\nTestes de aceitação\nÉ a última etapa de teste antes da implantação do software. Seu objetivo é verificar se o software está pronto e se pode ser utilizado pelos usuários finais executando as tarefas e funções para as quais foi criado.\nO software é disponibilizado para clientes e usuários com o objetivo de validar todas as funcionalidades requisitadas no início do projeto.\n\nAmbiente de produção\nTem que fornecer toda a infraestrutura necessária de hardware e software para que o produto desempenhe totalmente as funcionalidades para as quais foi projetado.\n\nQuem utiliza este ambiente?\nNesse ambiente também são realizados testes de aceite, que neste caso será o beta-teste.\nApenas um grupo de usuários selecionados terá acesso a uma “nova versão” do produto (que ainda estará sob o acompanhamento da equipe de testes de software).\n\nQuais testes normalmente são aplicados neste ambiente? Teste beta\nConduzido nas instalações dos usuários finais. Algumas considerações sobre esse teste:\n- O desenvolvedor não está presente;\n- O cliente registra todos os problemas (reais ou imaginários) e os relata ao desenvolvedor em intervalos regulares;\n- Depois que os problemas são corrigidos, o produto é liberado para toda a base de clientes;\n- São conduzidos em uma ou mais instalações do cliente pelo usuário final do software.\n\nNo caso do teste beta, é praticamente impossível haver um controle da parte do desenvolvedor sobre os erros encontrados.\n\nRelacionando requisitos a expectativas de teste\nEstratégia de teste\nAtenção\nConhecer e aplicar as técnicas de testes não é suficiente para garantir que bons testes sejam realizados. Também é necessário definir uma estratégia de teste para cada projeto de software.\n\nUma estratégia deve definir:\n- Quais as atividades.\n- Quem serão os envolvidos.\n- Quando e por quanto tempo serão realizadas estas atividades. O que é necessário para que uma estratégia de testes tenha sucesso?\nObservar alguns aspectos como: os requisitos não funcionais devem ser especificados de forma mensurável.\n\nNão se deve dizer que o sistema deve ter um bom desempenho.\nNo plano de teste, devemos enumerar explicitamente os objetivos do teste.\n\nO que deve conter um plano de teste?\n- Quem serão os responsáveis pelo teste.\n- Que tipos de testes serão realizados.\n- Quantos ciclos de testes estão previstos.\n- A cobertura esperada.\n\nO teste deve se concentrar no uso real do produto. Vale lembrar que o software é feito para satisfazer as necessidades dos usuários, e não dos desenvolvedores.\n\nComo obter sucesso numa estratégia de testes?\n- Buscar sempre assegurar a qualidade e a estabilidade por construção, evitando falhas e minimizando os testes necessários;\n- Pensar na possibilidade de construir um software que “perceba” quando uma falha está ocorrendo e tome alguma atitude.\n\nExemplo\nEm um sistema de saques em um banco, podem ser inseridas linhas de código para verificar que, caso o saque seja maior que o dobro do saldo da conta, suspende o procedimento, pois seria quase impossível um resgate tão grande.\n\nAtenção\nNão se pode esperar ter sistemas com qualidade realizando apenas testes para aferir sua qualidade.\n\nTestes baseados em requisitos\nA MTS (Metodologia de Teste de Sistema) define cada um deles assim:\n- Requisitos de negócio\nSão escritos na linguagem da área de negócios e podem conter gráficos, tabelas e diagramas. Correspondem a objetivos, metas ou “desejos” da área de negócios. Requisitos de usuário\n\nProvêm dos requisitos de negócio e servem como base para os requisitos funcionais e não funcionais. Descreve o que o usuário estará habilitado a realizar com o sistema ou produto.\n\nRequisitos funcionais\n\nSão a base para os requisitos não funcionais e detalhados. Definem quais funcionalidades serão disponibilizadas pelo sistema ou produto.\n\nExemplo: Especifica as ações, processamentos, respostas, cálculos e relatórios.\n\nRequisitos não funcionais\n\nSão a base para os requisitos não detalhados. Fazem referência às qualidades, características e restrições dos requisitos funcionais e podem referir-se também aos requisitos de negócio ou de usuário.\n\nExemplos de tipos de requisitos não funcionais:\n\n- Operacionalidade;\n- Desempenho;\n- Recuperação;\n- Disponibilidade;\n- Segurança;\n- Testabilidade;\n- Portabilidade.\n\nRequisitos detalhados\n\nServem de base para o projeto físico e a programação. Informam como os requisitos funcionais e não funcionais serão implementados.\n\nRequisito de teste\n\nInforma em algumas linhas como o requisito será testado. A partir do requisito de teste, podemos especificar os casos de teste, que são detalhamentos do requisito de teste.\n\nExemplo: Continuando com o exemplo de saques na conta, para uma aplicação que permita saques entre R$100,00 e R$ 500,00 múltiplos de 20, um requisito de teste poderia ser “realizar saques superiores a R$ 500,00”.\n\nEsse requisito de teste poderia gerar um caso de teste com o valor de R$520,00, cujo resultado esperado é “saque inválido”.\n\nMetodologias utilizadas para testes de aceitação\n\nFases da Metodologia MTS