Teste de garantia de qualidade aperfeiçoado - um tutorial de fluxo de usuário

À medida que os produtos e serviços são implantados cada vez mais rápido, a garantia de qualidade (QA) precisa se adaptar ao ambiente em evolução, às vezes atingindo o mesmo nível de cobertura em um período de tempo mais curto. Como podemos evitar o erro da quantidade sobre a qualidade ? Como podemos cobrir mais, aumentar a eficiência e ainda ser eficazes em nosso trabalho?

Todos nós sabemos que os casos de teste levam muito tempo para serem criados. Temos que aplicar diferentes técnicas, tipos de teste e documentar pré-condições, etapas e resultados esperados. Além disso, temos que criar um plano de teste.

Os especialistas em garantia de qualidade geralmente ficam sem tempo, especialmente quando tentam cumprir todas as fases do processo de controle de qualidade. A maior dor de cabeça é a fase de planejamento e design de teste, que gira em torno da criação de casos de teste e documentação de teste. Pode levar horas, às vezes até dias de esforço para concluir todo o trabalho e, geralmente, eles optam por pular certas entregas e resumir, deixando de fora informações importantes que podem levar ao esquecimento de um teste. Isso também resulta na perda do benefício do compartilhamento de conhecimento.

O teste de controle de qualidade tradicional atende ao fluxo do usuário

Eu sou um grande fã de casos de teste tradicionais e planos de teste. Eles não apenas ajudam a identificar toneladas de casos de teste, mas também documentam o produto muito bem. Você pode usá-los em treinamento, e qualquer pessoa da equipe os entende. Você não precisa confiar demais na experiência para que alguém comece a testar. Os planos de teste têm mais informações, como detalhar o escopo, os itens de teste, os recursos que você está testando e os que não estão. Há também uma análise de risco que entra no plano de teste. Estes são apenas alguns dos benefícios, no entanto, o tempo total que leva é muito longo em muitos casos.

O propósito de um plano de teste é uma forma de comunicação e um acordo entre as partes interessadas do projeto. Ele ajuda a detalhar os objetivos, recursos necessários e qualquer abordagem ou estratégia para testar o produto. O plano ajuda a garantir que tudo está sendo pensado e fornece às partes interessadas a confiança de que o processo de garantia de qualidade é investido estrategicamente. Não existe uma regra concreta de que este plano deve ter 10 páginas. Podemos redefini-lo para se adequar a uma equipe de ritmo acelerado.

A alternativa é simplificar os casos de teste tradicionais e o plano de teste de uma maneira que reduza o investimento de tempo necessário, mas forneça a mesma cobertura e documentação, se não mais, que faça sentido para todas as partes interessadas. Isso envolve uma única fonte de verdade, um fluxo de usuário com uma reviravolta. Ao estruturar e manter um fluxo de usuário, você terá a maior parte do design do caso de teste já feito para você. Isso pode ser aplicado a qualquer produto ou equipe e é versátil em seus detalhes e estrutura.

O uso do método de fluxo ajudará você a obter um tempo de resposta mais rápido com sua documentação de teste. Isso não é apenas para controle de qualidade manual, mas também para automação. O fluxo também pode contribuir para algumas seções do plano de teste.

Indo no embalo

Sem mais delongas, vamos mergulhar direto na construção de um fluxo de usuários para um site de mensagens simples.

Primeiro precisaremos de uma ferramenta gratuita de mapeamento mental. Eu pessoalmente uso XMind. Sinta-se à vontade para baixar qualquer ferramenta com a qual você se sinta confortável - usaremos apenas recursos básicos, como desenhar um diagrama de fluxo, adicionar “notas” a alguns dos tópicos, colorir diferentes condições e usar rótulos.

Nosso primeiro passo é entender o produto. Normalmente, você fará referência a imagens de maquete ou wireframes. Se nenhum deles estiver disponível, uma rápida chamada de atualização com um desenvolvedor produzirá exatamente quais telas esperar. Sinta-se à vontade para acompanhar e praticar à medida que avançamos. O fluxo não se limita apenas a uma interface de usuário e também pode ser usado para mapear chamadas de API para API, diagramas de banco de dados, estruturas de dependência e muito mais. Os mesmos princípios se aplicam.

Condições, Estados, Ações

Restringimos nosso fluxo usando apenas três atores. Você terá uma Condition , que é como um usuário com uma função específica, um cache limpo ou um usuário fazendo login pela primeira vez. Em segundo lugar, temos um State/Page , que é um componente GUI real, como uma página inicial ou uma janela de login. Em seguida vem o Action , que é uma interação física do usuário que faz com que o estado mude. Vamos ver isso em ação.

Analisando os Requisitos

Esta é a nossa homepage, que é o Estado. Temos duas ações possíveis: Cadastrar e Entrar.

Em seguida, temos a janela Entrar, outro Estado. As ações aqui são Voltar e Entrar. Observe que não classificamos os campos de entrada como ações. Você é mais do que bem-vindo para fazer isso. Na minha experiência, descobri que ao trabalhar em sistemas complexos que executam alguns décimos de profundidade, fica um pouco difícil de manter, mas para aplicativos simples, pode ser uma ótima opção.

Por fim, chegamos ao painel que o usuário acessará quando fizer login com sucesso. Aqui, temos três ações: podemos criar, editar ou excluir uma mensagem.

Agora temos informações suficientes para iniciar o fluxo do usuário. Vamos resumir o que temos. Anotamos os estados do produto. Pelo que podemos ver, são quatro páginas:

1. Pagina inicial
2. Janela de login
3. Janela de registro
4. Painel

Nós anotamos nossas ações em cada página/estado que pode ser “interagido” com:

1. Pagina inicial
   1. Conecte-se
   2. Registro
2. Janela de login
   1. Entrar
   2. Cancelar
3. Janela de registro
   1. A definir (depende do produto)
4. Painel
   1. Crio
   2. Editar
   3. Excluir

Começamos com o Nome do Produto , que pode ser alterado para se adaptar ao seu ambiente, mas isso se encaixa na maioria das equipes e seus produtos e também fornece um bom ponto de partida. Abaixo, notamos um ponto de interrogação ao lado de Register .

Muitas vezes, você encontrará um componente no Agile que ainda não está no escopo ou planejado para uma versão futura. Tome nota de sua existência, mas deixe-a como desconhecida até obtermos mais informações.

Desenhando o Diagrama de Fluxo

Desenhamos o acima no XMind para se parecer com:

Você notará que estou simplesmente codificando por cores o que é um estado e o que é uma ação. Também adicionei uma linha da ação Cancelar à página inicial para representar esse fluxo com precisão. Também vemos duas condições quando um usuário seleciona “Login”. Embora ambos vão para o painel, ainda queremos testar as duas condições possíveis.

O bom do XMind é que, se trabalharmos em um aplicativo grande e complexo, podemos criar diferentes níveis do diagrama; portanto, se você quiser dividir o fluxo em vários fluxos, mas mantê-los vinculados, isso é muito fácil de fazer com a vinculação os tópicos para folhas separadas. Você pode selecionar inserir um hiperlink e, no pop-up do assistente, pode escolher um “Estado” ao qual a ação leva. Isso significa que se você selecionar “Login” no XMind e ele criar um hiperlink para “Dashboard”, o cursor do mouse pulará para “Dashboard”, mesmo que esteja em uma planilha diferente. Muito legal.

O que está faltando no nosso fluxo são rótulos. Damos ao produto um rótulo de 0, pois essa é a raiz do fluxo. Então, para cada Estado (azul), adicionamos um rótulo S#, para cada Action (verde), adicionamos um rótulo A# e, por último, para cada Condição (ciano), adicionamos um rótulo C#. Cada rótulo deve ser único. Finalizamos com o seguinte:

Para rastrear qual número você usou pela última vez, porque à medida que o produto cresce, tentar encontrar o número mais alto pode ser um desafio, armazeno isso no tópico Raiz do fluxo, como abaixo:

Chegamos agora à parte da criação de casos de teste. Vamos nos concentrar nos Resultados Esperados, que provavelmente é a informação mais importante em um caso de teste e parte dos critérios de aceitação do recurso. Adicionarei um título para cada seção ou teste e depois listarei os resultados esperados abaixo dele. Farei isso para apenas um subconjunto para manter este artigo conciso:

Em seguida, a janela de login:

Em seguida, a ação de login:

Está realmente tomando forma. Observe os testes de limite e segurança adicionados. Você pode dar o título que quiser, o que for mais fácil para você marcar. Às vezes, marco o título com um tipo de teste, como Security – JS Inject – Email Field, e listo os resultados esperados abaixo.

Na maioria das equipes, consideramos a mudança de requisitos um incômodo para manter. Não mais. Digamos que acabamos de saber que todos os usuários iniciantes devem receber a janela Ts e Cs e devem aceitar antes de prosseguir para o painel — sem problemas. Podemos adicionar o estado e as ações com relativa facilidade, como abaixo:

Agora vemos o impacto de adicionar um novo estado. Observe que a numeração pode ser estranha no início, mas, desde que nos lembremos, os números servem apenas para identificar exclusivamente cada ator - como uma chave primária em um banco de dados. Não se esqueça de atualizar suas notas de “Último Usado” para acompanhar os números que você usa.

Criando os casos de teste do fluxo

Depois de todo esse progresso, agora chegamos à parte mais fácil: a criação do caso de teste. Permitam-me destacar alguns pontos importantes. Temos rótulos para cada ator, temos títulos para cada teste e esperamos resultados para cada teste, com condições incorporadas como parte de nosso fluxo. Isso soa como a receita para um caso de teste, você não concorda?

Tudo o que fazemos agora é copiar e colar o que está em nosso fluxo em qualquer ferramenta de gerenciamento de casos de teste, site do Confluence ou documento do Excel que você desejar. Eu ainda uso o bom e velho Excel. Eu mantenho um registro de todos os meus casos de teste em um arquivo chamado “Baseline” - muito original. Assim que terminar de copiar e colar, termino com o seguinte:

Sinta-se à vontade para adicionar colunas para tipos de teste, status de teste e configurações de teste conforme necessário. As condições podem ser mais bem colocadas antes da ação “Entrar”, porém, não existe forma certa ou errada de fazê-lo, depende da preferência pessoal e de como você se organiza.

Há algumas coisas a destacar. Uma é que eu mesclei células que compartilham as mesmas informações – não há necessidade de copiar e colar repetidamente, é uma perda de tempo e é mais difícil de manter. Outro item são os Passos. Você notará que dois dos testes têm etapas que incorporam os números de Estado e Ação. Isso pode ser usado quando você tem o fluxo como parte do SDLC em sua equipe. Todas as partes interessadas contribuem para o fluxo fornecendo informações, modelos, aumentando os riscos etc. Isso significa que, ao informar os números do fluxo, qualquer pessoa na equipe saberá o que fazer e, se houver um novo membro da equipe, é tão fácil como “siga a trilha, consulte as notas”.

Isso também ajuda a automação. Você pode dar a cada etapa ou ação uma referência exclusiva. Ao criar um pacote de automação estruturado como seu fluxo, você descobrirá que a estrutura de automação que você pode criar tem o potencial de ser altamente robusta, modular e compatível em todo o aplicativo. Ele estará utilizando objetos de paginação em uma escala maior, o que reduzirá o tempo de manutenção e permitirá que você troque funções de teste por novas.

O fluxo pode ser a única fonte de verdade para toda a documentação do produto, incluindo especificações técnicas, especificações funcionais, casos de teste, transição de estado, fluxos de dados etc.

A abordagem do plano de teste simplificado

E os planos de teste?, você deve estar pensando. Isso é simples. Um Plano de Teste contém seções como:

1. Introdução e escopo
2. Itens de teste
3. Recursos a serem testados
4. Recursos que não devem ser testados
5. Suposições
6. Critério de entrada
7. Critério de saída
8. EAP
9. Riscos
10. Requisitos do ambiente

A introdução e o escopo serão a história do JIRA ou qualquer tarefa ou história em outra ferramenta. Os itens de teste são simplesmente as versões de software ou números de confirmação atualmente implantados em seu ambiente, que você pode vincular ao ticket do JIRA ou em sua execução de teste no Confluence ou na ferramenta de gerenciamento de teste.

Os recursos a serem testados e os recursos não testados são, na verdade, seus casos de teste. Os casos de teste escolhidos para serem executados para esta história do JIRA são "Recursos a serem testados" e qualquer coisa não listada é "Recursos não testados". Muito simplesmente, liste os Estados e Ações que você testará no ticket da história.

Suposições, riscos e até requisitos de ambiente podem ser compilados em um documento ou adicionados aos comentários no JIRA, às vezes até colocados no Confluence e vinculados à história.

Uma WBS é uma estimativa que você atribui à história em termos de pontos de história ou horas, dependendo do seu projeto. Os critérios de entrada e saída já farão parte da história.

Se você quiser se aproximar dos planos de teste “tradicionais”, peça ao desenvolvedor ou a outras partes interessadas que comentem a história com um Sim ou Não para ver se concordam ou não com o plano de controle de qualidade. Isso tecnicamente serve como sua assinatura digital. Tudo isso pode ser incluído em seu processo de controle de qualidade com bastante facilidade e ajudá-lo a otimizar sua documentação de controle de qualidade.

O que aprendemos?

O fluxo de usuários com a abordagem acima e os planos de teste simplificados para usar as ferramentas disponíveis hoje nos ajudarão a reduzir o trabalho repetitivo e auxiliará o controle de qualidade a obter um tempo de resposta mais rápido sem sacrificar a qualidade.

Essa abordagem foi fundamental para me orientar a me manter organizado, cobrir todas as bases e construir uma documentação que toda a equipe entenda. No Agile, isso será realmente útil, e a melhor parte disso é que ainda seguimos uma das abordagens Agile: “Simplificar a documentação”.

Espero sinceramente que as informações tenham sido úteis. Tudo depende de você como leitor. Este não é um conjunto concreto de regras a seguir, são apenas diretrizes para lhe dar ideias para crescer e melhorar sua eficiência. Nenhuma técnica se encaixa em cada projeto, equipe ou produto, mas pode abrir caminho para outra ideia inovadora.