7 dicas de Escrita de caso de teste para melhorar o seu processo de teste de software ERP

os casos de teste são muito importantes para garantir a qualidade no seu processo de teste de software ERP. Eles são os primeiros passos em um ciclo de teste e se os casos de teste não forem de qualidade suficiente, todo o projeto será “sobrecarregado”. Escrever casos de teste “ótimos” é uma habilidade que obtém forma simplesmente fazendo isso. Mas é muito útil ter alguns insights que possam ajudá-lo. Com este artigo, quero entrar em contato com você e dar sugestões para torná-lo mais fácil, mais divertido e melhor. As dicas que serão dadas se relacionarão particularmente com os casos de teste no teste de aceitação de sistemas ERP.

o que são casos de teste?

no mundo dos testes de software, existem muitas definições de casos de teste. Por causa disso, é importante nomear nossa definição. Em nossa filosofia, os casos de teste são (com base no IEEE610): “um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para um objetivo específico.”Saber escrever bons casos de teste é extremamente útil para quem quer testar. Seja um teste funcional, um teste de aceitação do Usuário, testando um aplicativo da web ou um módulo de um sistema ERP. Em todas as situações descritas acima, os casos de teste determinam o que estender os resultados dão um veredicto sobre as metas pré-definidas.

por que escrever casos de teste é tão difícil?

conforme descrito na definição, os casos de teste ajudam a orientar os testadores por meio de uma sequência de instruções de teste para determinar se o software atende ou não aos requisitos pré-definidos. A execução de casos de teste nos ajuda a coletar e descobrir informações para perceber esse objetivo ou alvo específico. O primeiro problema que encontramos diretamente é a diversidade de possíveis alvos. E como existem diferentes tipos de teste e objetivos, existem diferentes tipos de casos de teste correspondentes.

um segundo problema está relacionado ao conteúdo da instrução ou etapas reais do teste. O nível dessas instruções depende do tipo de Testador que deve interpretar essas informações e dar uma opinião. Um testador profissional precisará de instruções diferentes em oposição a um usuário final envolvido no teste de aceitação de um sistema ERP

Dica 1: Determine sua meta e o que você deseja relatar

pense no que deseja relatar, para que você possa determinar sua meta derivada. Usando isso como base, você tem o esboço do caso de teste em exibição. Existem muitos objetivos diferentes, onde sempre temos que nos perguntar o que estamos tentando aprender ou alcançar quando vamos fazer o teste. Aqui estão alguns exemplos:

• encontrar defeitos: este é o objetivo clássico do teste. Um teste é realizado para expor defeitos.
• Maximize o número de bugs: A distinção entre” maximizar o número de bugs “e” encontrar defeitos ” é que o número total de bugs é mais importante do que a cobertura.
• bloquear lançamentos prematuros de produtos: o objetivo deste teste é encontrar prematuramente tantos defeitos graves (showstoppers) para que ninguém leve o produto à produção.
• os gerentes de suporte com suas decisões go / NO-go: os gerentes tomam decisões com base em riscos. Indicações de risco como cobertura de teste, impacto de problemas encontrados, etc. Dar – lhes um melhor fundo sobre o qual basear suas decisões.
• avalie a conformidade de acordo com a especificação: as supostas especificações são verificadas quanto à sua operação. Todos os assuntos que não estão associados às especificações são desconsiderados.
• avalie a qualidade: este é um objetivo difícil, porque a qualidade é multidimensional. A natureza da qualidade depende da natureza do produto. Para avaliar a qualidade, devem ser elaborados critérios claros, que são definidos de forma que possam realmente ser mensuráveis.

os resultados do teste derivados dos casos de teste fornecem informações relevantes diretas sobre o objetivo.

Dica 2: reserve tempo de projeto suficiente

Reserve tempo suficiente para projetar seus casos de teste, para que eles correspondam aos seus objetivos. Casos de teste ruins Irão assombrá-lo durante todo o processo de teste. Comparando os resultados dos testes, relatando várias rodadas de testes, etc. São essencialmente determinados pela qualidade de seus casos de teste.

se você já está ficando sem tempo para projetar, mas ainda deseja iniciar o teste, certifique-se de ter pelo menos definido os principais riscos. Se 10 Testadores devem rever 5 casos de teste com 1 etapa de teste, isso resultará em 50 resultados de teste. Não importa o que estes 50 resultados dão mais informações sobre a qualidade, em seguida, não fazer nada. Isso provavelmente não será exaustivo, mas é um primeiro passo. A partir daí, o nível de detalhe de certas partes pode ser determinado.

preferimos que você pense com antecedência sobre como o teste deve ser projetado e que os resultados do teste dêem uma resposta real ao objetivo. Mas, na realidade, isso às vezes é indisciplinado.

Dica 3: Caso De Teste de nome

nomear casos de teste é importante. Em um teste ERP médio, você tem facilmente mais de 500 casos de teste. Você entenderá que uma estrutura de nome lógico aumenta a findability. Na literatura é muitas vezes referido como um nome completo quanto possível, em que o processo a ser testado, módulo, objeto etc. Estão todos incluídos no nome. Você pode imaginar que fornecer 500 casos de teste com um título tão completo dá uma administração caótica. Com uma planilha simples do Excel, você perde facilmente a visão geral. As ferramentas de gerenciamento de testes fornecem uma estrutura à qual você pode relacionar casos de teste a objetos reutilizáveis, sem que eles “poluam” o nome. Você também tem ferramentas de registro de teste que organizam esses relacionamentos de uma maneira diferente.

no TestMonitor, por exemplo, inventamos uma solução diferente. Na ferramenta, você pode definir rótulos ou tags que podem ser vinculados a casos de teste. Dentro do TestMonitor, os casos de teste estão vinculados a um ou vários processos de negócios-, risco-, requisitos – ou rótulos de aplicativos. Isso permite que os casos de teste sejam agrupados e recuperados de diferentes perspectivas.

para o nome de um caso de teste dentro do TestMonitor, basta uma descrição clara da finalidade do caso de teste. Para simplificar, você descreve uma atividade com uma expectativa implícita.

exemplo nome do caso de teste:
“rescisão do contrato de arrendamento – casa independente”
” Criar cliente “”recibo de reserva provisória”
etc.

Exemplo de caso de teste “Provisório confirmação de reserva”, que está ligada a vários rótulos:

• de negócio do processo de Recepção de mercadorias’
• exigência de Contrato de exigência’
• risco Operacional risco’
• “aplicativo ERP’

É importante para descrever o resultado esperado por caso de teste. O testador então sabe em que direção a” resposta ” precisa ser e obtém diretamente uma estrutura de teste explícita.

Dica 4: Descrição da etapa de teste

conforme descrito na definição os casos de teste são uma coleção de instruções de teste que nos ajudam a descobrir informações para atingir um objetivo específico.

um caso de teste deve ter um começo e um fim claros para determinar se o caso de teste passou ou falhou. Além disso, um caso de teste é composto por uma ou mais instruções ou etapas de teste, em que existem vários caminhos possíveis para alcançar o resultado desejado. Apenas testar o caminho do sucesso é muitas vezes insuficiente. Em certas situações, seguir caminhos sem sucesso pode apenas fazer a diferença.

é importante definir as etapas de teste o mais claramente possível para que o usuário final de um teste de aceitação do usuário saiba exatamente o que precisa fazer. Claro, existem pré-condições para chegar, como testador de nível funcional, conhecimento do novo sistema, conhecimento dos possíveis processos de negócios ajustados, etc. Mas, em essência, todos devem entender todas as etapas do teste.

suponha que descrevamos ainda mais o caso de teste “rescisão de arrendamento-casa independente” para um caminho de sucesso simples:

1. selecione uma unidade e comece a rescindir o contrato de arrendamento. Controle se houver pré-requisitos entre os quais a rescisão do contrato de arrendamento pode/não ser aceita e crie um registro disso.
2. marque uma consulta para a inspeção final.
3. preencha os dados na tela rescisão do contrato de arrendamento. Verifique novamente os dados do inquilino no cartão de rescisão do arrendamento.
4. registre a rescisão do contrato e envie uma carta de Conformidade. Verifique se a carta de confirmação veio no Arquivo digital.
5. verifique no registro de contrato da unidade que o contrato atual é rescindido, que o contrato rescindido está vinculado à rescisão do contrato de arrendamento e que existe um contrato de vaga recém-criado.
6. verifique o novo contrato (vaga) com base na política de aluguel e nos modelos de elementos.

o que você percebe?

• cada etapa do teste começa com um verbo
• seguido de um tópico
• concluindo com detalhes e possivelmente controlar perguntas. Você pode optar por colocar as perguntas de controle em etapas de teste separadas, mas a prática mostra que a questão de controle é um refinamento da ação e, logicamente, será anotada como uma etapa de teste.

no exemplo acima mencionado, supõe-se que um especialista de um determinado campo avaliará a etapa de teste. E porque ele ou ela é um especialista, nenhuma condição de entrada é dada ou expectativas explícitas delineadas, porque o especialista ainda tem seus próprios estudos de caso na manga e suas expectativas são cristalinas.

no momento, se você não tiver um especialista, poderá expandir as etapas de teste com condições de entrada e expectativas explícitas.

por exemplo, teste a Etapa 1 no caso de teste “rescisão da casa independente de Locação” com mais detalhes.

1. selecione a unidade “Fleet street 677” e inicie o término do arrendamento. As condições garantem que esta unidade não possa ser encerrada antes do pagamento dos atrasos.
2. Etc.

Dica 5: Não mais de 10 Instruções de teste em 1 caso de teste

encontramos regularmente projetos de teste em que >50 etapas de teste são atribuídas a um caso de teste. Isso é demais por alguns motivos:

• todas as etapas do teste devem ser tomadas separadamente (ou explicitamente aprovadas) antes que um caso de teste receba um veredicto.
• a avaliação final de um caso de teste é determinada pela Pontuação” pior”. Portanto, pode muito bem ser que 49 etapas do teste sejam avaliadas como “boas” e uma Como “errada” o que resulta em um caso de teste “errado”. A medição das etapas de ensaio deve ser semelhante. Com isso, quero dizer que praticamente todas as etapas de teste devem ser iguais ao efeito da avaliação. Se você tiver 10 etapas de teste que você deve seguir, incluindo 2 pequenas etapas de teste que são desproporcionais às outras 8 etapas de teste, você precisa reformulá-las. O mesmo se aplica ao contrário com uma etapa de teste difícil.
• o testador se perde rapidamente com muitas etapas de teste em um caso de teste. Não fizemos um estudo científico sobre isso, mas a prática mostra que um caso de teste não deve incluir mais de 10 etapas de teste. Pode-se pensar em muitas exceções (controles de conversão, etc), mas na prática, para um teste de aceitação do usuário de um sistema ERP, isso funciona melhor.
• é difícil para os desenvolvedores reproduzir o erro encontrado. Com muitas etapas de teste, o desenvolvedor perderá muito tempo tentando reencenar a situação.
• reprises ou reteste de grandes casos de teste leva muito tempo. Quando uma falha é detectada por um testador, O caso de teste correspondente terá que ser testado novamente. Um reteste requer que o próprio passo seja reavaliado, você deseja evitar erros de regressão obviamente. Ao tomar muitas etapas de teste, você provavelmente está testando demais. Dessa forma, o processo de teste leva mais tempo e pode eventualmente sobrecarregar seus testadores.

além disso, você também tem ferramentas de registro de teste que podem apresentar os casos de teste em várias formas ao testador. TestMonitor, por exemplo, tem duas visualizações diferentes. TestMonitor tem uma exibição que mostra todas as etapas de teste separadamente por página e uma exibição na qual os casos de teste são apresentados por página, incluindo todas as etapas de teste.A vantagem da primeira tela é que cada testador pode obter mais informações para cada etapa de teste. A desvantagem no caso de o testador ser mais experiente, ele precisa clicar em “Avançar” toda vez que quiser prosseguir para a próxima etapa de teste. Na outra visão para cada caso de teste, as vantagens e desvantagens são vice-versa.

Dica 6: revisão por um não designer/fornecedor

na prática, vemos regularmente scripts de teste preparados pelos programadores do Fornecedor de software. Ao revisar esses scripts de teste pelos eventuais Testadores, geralmente há mais perguntas do que respostas. Por outro lado, isso funciona da mesma forma para scripts de teste preparados por seus próprios funcionários. Dá um valor acrescentado real que revê estes pelo fornecedor do software. Eles olham para os scripts de teste concluídos com olhos diferentes e sempre apresentam adições ou modificações significativas.

com um pouco de brainstorming com os especialistas em fornecedores de software e a organização do cliente, você rapidamente se concentra na essência do que precisa ser testado. Em seguida, reserve um tempo para considerar os casos de teste, cenários sem sucesso e você verá que seu modelo de teste está rapidamente se tornando mais extenso e detalhado. Além disso, você obtém mais informações sobre a qualidade que considerou possível.

Dica 7: TestMonitor

além disso, use uma plataforma de teste profissional e torne a qualidade realmente perspicaz. Solicite uma avaliação gratuita do TestMonitor hoje e veja e experimente a diferença por si mesmo.

se você é um recém-chegado no mundo dos testes, fica facilmente sobrecarregado com toda a terminologia de teste sendo lançada. Neste artigo, tentaremos explicar alguns dos jargões que você pode encontrar em sua vida diária de teste, apenas para tornar tudo um pouco mais compreensível.

comece a testar com TestMonitor

ainda não é um usuário TestMonitor? Testes bons e fáceis são prioridade fundamental para gerentes de garantia de qualidade, testmanagers, gerentes de TI, gerentes de teste e gerente de lançamento. TestMonitor torna o teste fácil e divertido para os usuários de teste também.

então vamos começar. Você pode querer verificar nosso vídeo ou baixar o folheto do produto. Mas é claro que, com um teste gratuito, você pode realmente experimentar a facilidade de Uso do TestMonitor.

manter contato? Siga TestMonitor no Twitter e LinkedIn.