Planejamento e Projeto de Testes Taíse Dias

Roteiro Processo de Desenvolvimento: Problema Solução Plano de Testes Projeto de Testes Teste baseado em Caso de Uso Conclusão

Problema no Processo de Desenvolvimento Omissão de etapas de testes Inconsistência entre documentos Falta de comprometimento com a qualidade dos sistemas Conseqüências: produtos de baixa confiabilidade e gastos desnecessários por causa de descobertas de erros tardias. Definição de Requisitos Projeto do Sistema e do Software Implementação e Testes Unitários Integração e Teste do Sistema Operação e Manutenção

Solução Iniciar ciclo de vida do teste em paralelo ao de desenvolvimento Elaborar Plano de Teste previamente ajuda quem pretende melhorar o seu processo de desenvolvimento e produzir com maior qualidade

Solução

Solução Poderia haver um responsável por testes desde o início do projeto O plano pode ser elaborado por alguém, antes do desenvolvimento do sistema Vantagens: exige o estudo de toda regra de negócio incentiva à imaginação e criação de cenários de testes, não visualizados pelo analista do sistema. Exemplo: Tela de Login

Ex.: Tela de Login Casos de testes construídos sem análise prévia: Login do Usuário Casos de Teste Informar login correto O sistema valida as informações e carrega na tela principal Informar login incorreto É exibido o alerta “Login e/ou senha inválido(s). Verifique por favor.” Informar senha incorreta

Ex.: Tela de Login Maior domínio das regras de negócios -> maior cobertura dos casos de testes Login do Usuário Casos de Teste Não informar o login É exibido o alerta “O campo login deve ser preenchido. Verifique, por favor.” Não informar senha É exibido o alerta “O campo de senha deve ser preenchido. Verifique por favor.” Verificar sintaxe A sintaxe do texto deve estar correta. Verificar as atribuições do usuário (teste de segurança) No momento em que ocorrer o login, apenas as funcionalidades com permissões atribuídas devem ser exibidas ao usuário. Logar com o mesmo usuário em dois browsers É exibido um alertas notificando a duplicidade, e é notificada por e-mail a ocorrência desta redundância ao usuário.

Teste baseado em Caso de Uso Responsável pelo Plano de Testes: Analista de Testes Elabora Projeto de testes durante e/ou após elaboração de casos de uso Comunicação com o analista de sistemas tirar dúvidas sobre os casos de uso Exemplo de Caso de uso: O usuário informa a data início e data fim que deseja procurar. O sistema retorna todos os registros cadastrados entre as datas informadas. Neste momento, o analista de testes constrói os seguintes casos de teste:

Teste baseado em Caso de Uso Pesquisa por período Casos de Teste Informar data início e fim em uma seqüência cronológica O sistema retorna todos os registros cadastrados entre as datas informadas Informar apenas a data de início O sistema pode exigir ou não a data fim como obrigatório, vai depender do critério do analista do sistema (o testador consulta o analista) Informar apenas data fim O sistema pode exigir ou não a data início como obrigatório, vai depender do critério do analista do sistema (o testador consulta o analista) Não informar nenhum dos campos É exibido o alerta para que o usuário preencha o(s) campo(s) obrigatório(s) para a consulta (a obrigatoriedade, mais uma vez, depende do analista). Informar a data fim anterior à data início É exibido o alerta “A data fim informada é anterior à data início. Verifique, por falor.”

Documentação Elaborar documentos de testes Manter consistência com documento de requisitos Ex: O analista de testes tem conhecimento da existência de um campo de e-mail no cadastro de usuário. Imediatamente, ele cria um caso de teste que exija uma validação do campo de e-mail (aceitar apenas e-mails válidos). Quando finalmente consulta os fluxos de exceção do caso de uso, nota que não existe uma exceção levantada para o cadastro de e-mails inválidos. Então é adicionado um erro de especificação “Criar fluxo de exceção para cadastro de e-mails inválidos”.

Plano de Testes Identificar o que será testado (requisitos) Descrever as estratégias de teste a serem empregadas Abordagem (Caixa Preta e Caixa Branca) Tipos de testes: funcionais, de segurança, entre outros. Descrever quais técnicas serão utilizadas para criação dos casos de testes: baseados em casos de uso, de boundary, entre outras. Critérios de sucesso Identificar os recursos necessários Recursos humanos Ferramentas Prover uma estimativa dos esforços de teste Atividades Responsabilidades Cronograma

Projeto de Testes Artefato que descreve os casos de testes e os procedimentos para execução dos mesmos. Para projetar casos de testes, são visualizados cenários (casos de uso) a partir dos quais serão criados casos de testes. Estabilizar o Test bed: combinação de drivers e stubs Determinar pré-condições para o teste e os objetivos a serem atingidos Especificar os casos de testes individuais Determinar como executar os testes

Exemplo de criação de caso de teste baseado em caso de uso [UC07] Nome: Cadastrar usuário Atores: Vendedor Prioridade: Essencial Requisitos associados: [RF02] Cadastro de usuários Entradas: Nome, CPF, Data de Nascimento Login (exceto para funcionário) Senha (exceto para funcionário) Crédito, data inicial, final, permissão para comprar em dinheiro, dias da semana (apenas funcionário) Pré-condições: O vendedor deve estar logado no sistema O usuário não deverá estar cadastrado no sistema Pós-condições: O usuário deve estar cadastrado no banco de dados Fluxos de eventos Fluxo Normal: O usuário seleciona a opção “Cadastrar Usuário”. [Fluxo Excepcional 1] O usuário seleciona se o cadastro a ser feito é de funcionário, gerente ou vendedor. O usuário fornece os dados da pessoa a ser cadastrada. O sistema verifica se todas as informações obrigatórias foram fornecidas. [Fluxo Excepcional 2] O sistema valida as informações fornecidas. O sistema mostra uma tela para confirmação do cadastro. O usuário confirma o cadastro. Os dados são armazenados na base de dados. Fluxo Excepcional 1: A opção “Voltar” é selecionada. Todos os dados informados são descartados. A tela inicial do sistema é mostrada. Fluxo Excepcional 2: Uma ou várias informações obrigatórias não são informadas ou o formato da informação não é o adequado. O sistema mostra uma tela informando que falta uma ou mais informações obrigatórias. O sistema retorna para a tela “Cadastrar Pessoa” com os dados informados nos seus respectivos lugares.

Cadastrar Alterar Remover Relatórios Fazer logoff

Cadastrar Alterar Remover Relatórios Fazer logoff Organização Almoxarifado Produto Vendas Usuário

Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de Usuário Nome: CPF: Data de Nascimento: Tipo de usuário: Nome 1 032.165.987-52 23/03/1985 Gerente Continuar >> << Voltar

Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de Usuário Login: Senha: login1 senha1 Cadastrar << Voltar

O usuário foi cadastrado com sucesso! Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de usuário O usuário foi cadastrado com sucesso! OK

Cadastrar Alterar Remover Relatórios Fazer logoff

Cadastrar Alterar Remover Relatórios Fazer logoff Organização Almoxarifado Produto Vendas Usuário

Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de Usuário Nome: CPF: Data de Nascimento: Tipo de usuário: Nome 2 053.725.944-50 07/07/1989 Vendedor Continuar >> << Voltar

Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de Usuário Login: Senha: login2 senha2 Cadastrar << Voltar

O usuário foi cadastrado com sucesso! Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de usuário O usuário foi cadastrado com sucesso! OK

Cadastrar Alterar Remover Relatórios Fazer logoff

Cadastrar Alterar Remover Relatórios Fazer logoff Organização Almoxarifado Produto Vendas Usuário

Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de Usuário Nome: CPF: Data de Nascimento: Tipo de usuário: Nome 3 012.165.548-54 07/07/1980 Funcionário Continuar >> << Voltar

Permissão para compras em dinheiro? Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de Usuário Crédito em reais: Data Inicial: Data Final: Permissão para compras em dinheiro? Dias permitidos para realizar compras: todos 2ª feira 3ª feira 4ª feira 5ª feira 6ª feira 10,00 01/11/2007 07/11/2007 Não Cadastrar << Voltar

O usuário foi cadastrado com sucesso! Cadastrar Alterar Remover Relatórios Fazer logoff Cadastro de usuário O usuário foi cadastrado com sucesso! OK

Exemplo de criação de caso de teste baseado em caso de uso Técnica utilizada: Use Case Testing ID CT_001 Tipo do teste Funcional Objetivo Verificar se a funcionalidade de cadastrar usuário está executando corretamente. Requisito [RF02] Cadastro de usuários Pré-condição 1. O vendedor deve estar logado no sistema 2. O usuário não deverá estar cadastrado no sistema Nº. do Passo Passos Resultados Esperados 1 Selecione a opção “Cadastrar Usuário”. A tela de cadastro é apresentada. 2 Forneça os dados do usuário (nome = nome1, CPF = 032.165.987-52, data de nascimento = 23/03/1985, tipo de usuário = gerente ) e selecione o botão “Continuar”. A tela para cadastrar login e senha é apresentada. 3 Forneça os valores de login e senha (login = login1 e senha = senha1) e selecione o botão “Cadastrar”. O sistema retorna uma mensagem informando que o usuário foi cadastrado com sucesso. 4 Verifique se o usuário está cadastrado no banco de dados com todas as informações fornecidas. O usuário foi cadastrado no banco de dados com sucesso.

Exemplo de criação de caso de teste baseado em caso de uso E se nem todos os dados obrigatórios forem preenchidos? E se esse usuário já tiver sido cadastrado no banco de dados? E se o formato do CPF ou da data não obedecer ao padrão? E se o usuário desistir de cadastrar usuário durante a realização do cadastro? E se outras pré-condições forem violadas? Sugestão: “tentar criar casos de testes não convencionais (se você não tentar, os usuários irão!!!)”

Conclusão Produzir requisitos de testes baseados nos requisitos de análise “As fábricas de software que experimentam algumas mudanças chegam sempre às mesmas conclusões: optar por testar somente no fim é ineficaz, gera mais gastos, e ainda induz ao maior de todos os prejuízos: a insatisfação do usuário. ”

Referências [1] Testes de Software, disponível em www. URL: <http://testesdesoftware.blogspot.com/2007/05/artigo-ii.html#links>, último acesso em 23 de setembro de 2007. [2] Disciplina de Engenharia de Software, disponível em www. URL: http://www.cin.ufpe.br/~if682 [3] Spillner, A.; Linz, T.; Schaefer, H.: Software Testing Foundations, Rock Nook, 2007.