Menu

Implementação prática de teste manual em 7 etapas antes da liberação da produção

7 step practical implementation manual testing before production release

Experimente Nosso Instrumento Para Eliminar Problemas

No post anterior desta série sobre o Teste Manual, tentei lançar o máximo possível sobre os fundamentos do Teste Manual.

Se você perdeu, Você pode lê-lo aqui .

Espero que tenha conseguido levá-lo o mais próximo possível das respostas que procurava.

Nesse caso, você não gostaria de saber mais sobre a implementação prática do Teste Manual, como se familiarizar mais com ele e como realmente iniciar uma carreira nele?

Este artigo lançará luz sobre todos esses aspectos.

Implementação de Teste Manual

Vamos começar.

O que você aprenderá:

Ciclo de Teste Manual

Para entender Ciclo de Teste Manual ou Software Test Life Cycle (STLC), em primeiro lugar, precisamos entender o Software Development Life Cycle (SDLC), o qual tenho certeza que você já conhece.

As pessoas se referem a eles separadamente, mas não têm certeza se eles podem realmente coexistir. Eles estão fortemente integrados um ao outro. Bem, mesmo esses ciclos têm tantas versões deles criadas e flutuando no espaço da internet, eles variam muito em qual modelo de desenvolvimento é selecionado.

Como a maioria dos mundo está se tornando ágil atualmente, vou manter minhas coisas simplificadas em torno do Agile.

7 etapas de teste manual prático antes da liberação da produção

Aqui vou eu.

Lembre-se de que estou falando sobre SDLC e STLC.

# 1) Coleta de requisitos

Fase de coleta de requisitos

O analista de negócios (pessoa / equipe responsável pela coleta de requisitos) documenta os requisitos. Eles documentam os requisitos, esse é o destaque, você pode manter o foco apenas nisso. Onde está documentado importa menos.

As pessoas usam qualquer coisa para documentar isso que lhes convém, mas não se limitando a plataformas tradicionais como MS Word doc, plataformas modernas como Jira / Rally e ferramentas da nova era como Trello.

# 2) Discussão / Compartilhamento de Requisitos

Fase de discussão de requisitos

O analista de negócios deve então compartilhar os requisitos documentados com a equipe de desenvolvimento, a equipe de teste e a equipe de UX (se necessário). Isso geralmente acontece por meio de uma reunião formal onde os SPOCs (Ponto Único de Contatos ou uma equipe inteira, depende) de todas as três funções atendem e entendem todos os requisitos.

Em uma cultura de trabalho saudável, os requisitos são discutidos sob todos os ângulos e cada membro da reunião pode colocar questões e dúvidas. Depois que todas as perguntas forem respondidas e a modificação necessária no requisito for concluída, essa fase pode ser considerada Concluída. Novamente, o que se chama esta reunião / etapa específica e sua documentação diferem de empresa para empresa.

Leitura adicional=> Como revisar o documento SRS

Depois que todas as perguntas forem respondidas e as modificações necessárias no requisito forem feitas, esta fase pode ser considerada como Feito .

Novamente, o que se chama esta reunião / etapa específica e sua documentação diferem de empresa para empresa.

Por exemplo, a documentação é chamada ou subdividida em SRS (Especificação de Requisito do Sistema), Documento de Requisito, Epopéia, História do Usuário, Ponto de História (possivelmente, menor unidade de requisito), etc. Em linhas semelhantes, esta reunião em que o requisito é compartilhado é chamada de Reunião de discussão de requisitos, reunião de preparação, reunião de perfuração, etc., espero que você entenda.

Pressionando essas terminologias para que você sempre se lembre da ideia principal, independentemente dos diferentes nomes.

Poste esta reunião, duas etapas são acionadas ao mesmo tempo, sem uma ordem específica, consulte as duas próximas etapas.

# 3) Projetando

A equipe de desenvolvimento começa com seu projeto técnico assim que os requisitos são discutidos e quando não há grandes pontos pendentes. O que é feito nesta fase novamente difere de empresa para empresa.

Esta fase pode envolver, mas não se limitando às seguintes tarefas:

  • Decidindo a abordagem de desenvolvimento
  • Preparando documento de design
  • Projetando os fluxogramas
  • Estimando os esforços
  • Descobrir o impacto deste novo requisito em qualquer funcionalidade existente
  • Precisa corrigir dados existentes, etc.

A equipe de UX também pode se envolver nesta fase quando houver uma mudança na IU ou uma nova tela estiver para ser desenvolvida. A equipe de UX ajuda a equipe de desenvolvimento e a equipe de teste com um protótipo de IU para a funcionalidade / recurso em discussão. Pode ser um documento do Photoshop, uma imagem simples, uma apresentação do PowerPoint ou qualquer outra coisa que faça a equipe de desenvolvimento entender como as telas devem ser desenvolvidas.

Observação: O ideal é que essas telas, ou pelo menos suas versões de rascunho, sejam mostradas na sessão de discussão de Requisitos apenas para ajudar a equipe a construir um melhor entendimento. Ele é marcado com o requisito original para que possa ser consultado a qualquer momento.

# 4) Cenário de teste / projeto de caso de teste

Fase de projeto do cenário de teste

Paralelamente à fase de projeto, a equipe de teste começa com a construção de cenários de teste e / ou casos de teste com base nos requisitos discutidos. Se os cenários de teste são sempre escritos primeiro e depois divididos em casos de teste, é algo que novamente não é constante.

Em minha opinião, quer você documente os cenários de teste ou não, eles sempre estarão lá antes dos casos de teste. O cenário de teste é o seu ponto principal, você pode dizer, eles o orientam para detalhar as coisas ainda mais. Assim que a escrita do caso de teste terminar, ele pode ser compartilhado com a equipe de Desenvolvimento para dar a eles uma ideia do escopo do Teste e eles também podem ter certeza de que o desenvolvimento que aconteceu ou está acontecendo está satisfazendo os casos de teste escritos.

Assim que a escrita do caso de teste terminar, ele pode ser compartilhado com a equipe de Desenvolvimento para dar a eles uma ideia do escopo do Teste e eles também podem ter certeza de que o desenvolvimento que aconteceu ou está acontecendo está satisfazendo os casos de teste escritos.

Os casos de teste, uma vez escritos, de maneira ideal, são revisados ​​por um líder de teste ou par de vários ângulos, como:

  • Cobertura de requisitos
  • Gramática ortográfica
  • Padrões de redação de casos de teste (nada além de um modelo que uma equipe / empresa segue)
  • Compatibilidade com versões anteriores
  • Compatibilidade de plataforma
  • Referências de dados de teste
  • Tipos de teste direcionados, etc.

Leitura adicional=> Escrevendo casos de teste do documento SRS

Idealmente, somente após revisão e modificação necessária, eles são repassados ​​para a equipe de Desenvolvimento.

Quando eu disse 'uma vez que a escrita do caso de teste acabou', quis dizer uma vez 'todos os casos de teste são escritos com base no conhecimento completo de determinado requisito e possíveis cenários de teste descobertos até aquele momento específico'. É quase impossível ter 100% de cobertura de casos de teste na primeira tentativa.

Haverá defeitos que você encontrará em ações aleatórias (mas intencionais), em ações puramente aleatórias (teste de macaco) e em alguns cenários raros. Há chances de você perder alguns deles. E em algum momento você pode perder até mesmo os mais básicos, afinal, você é humano. Mas aqui, pelo menos, uma boa revisão de casos de teste e uma forma estruturada de redação de casos de teste podem salvá-lo.

Na maioria das vezes, um testador ou equipe de teste continua adicionando mais e mais casos de teste ao bloco existente à medida que descobrem a verdade ou pensam mais sobre os requisitos.

Bem, agora alguns de vocês devem estar duvidando do meu conhecimento de Teste de Software, pois alguma palavra (que meio que se tornou uma norma em Teste de Software) ainda não é usada por mim. Plano de teste certo?

Deixe-me dizer algo sobre isso. Acredito fortemente na necessidade da maioria das informações mencionadas no Plano de Teste, mas documentar todas no mesmo lugar e torná-las absolutamente obrigatórias é algo que considero discutível.

De qualquer forma, esse é um tópico totalmente separado para discutir. Compartilhar informações 'adequadas a todos' sobre isso é difícil, mas deixe-me tentar.

Você, você com seu líder de teste ou líder de teste prepara o Plano de Teste ou documenta as informações necessárias em locais diferentes.

Leitura Adicional=> Como escrever um documento de plano de teste

Informações que devem ser absolutamente congeladas nesta fase:

  • O escopo do teste: Requisito, compatibilidade com versões anteriores, plataformas, dispositivos, etc.
  • Pessoa / equipe que vai testar
  • Estimativa de esforço de teste
  • Limitações: Quaisquer suposições feitas ou limitações aceitas com antecedência.
  • As pessoas, adicionalmente, documentam os critérios de entrada, critérios de saída, risco, etc. que eu acho que realmente não precisam de menção separada, pois deveria ser uma compreensão normal.
    • Critério de entrada (Quando começar o teste): Poucos começam quando há parte testável da funcionalidade disponível para teste. Poucos esperam que toda a funcionalidade seja testada. Assim que o fluxo básico estiver funcionando, o teste será iniciado.
    • Critério de saída (Quando parar): Quando não há bloqueador, defeitos críticos e principais (sujeitos a impacto) no teste de estágio aberto podem ser interrompidos. Ou no meio do caminho, quando há muitos defeitos enfrentados, o teste pode ser interrompido pelas partes interessadas apropriadas.
    • Risco : Risco de negócio ou risco funcional se o teste não acontecer de acordo com o plano documentado.

# 5) Fase de desenvolvimento

Fase de desenvolvimento de software

A equipe de desenvolvimento após a fase de design começa com o desenvolvimento real e os testes de unidade à medida que são concluídos com o desenvolvimento de blocos de requisitos testáveis. Eles podem passar a funcionalidade para teste em blocos conforme e quando ela for implementada ou podem passar a funcionalidade inteira de uma vez.

Em um cenário ideal, a revisão formal do código e o teste da caixa branca acontecem antes de passar a funcionalidade desenvolvida para o Teste. idealmente, a equipe de desenvolvimento também deve consultar os casos de teste fornecidos pela equipe de teste, além dos requisitos e documentos de design.

# 6) Fase de teste

Conforme mencionado anteriormente, o início desta fase difere de empresa para empresa, de equipe para equipe.

A equipe de teste começa o teste quando testável (algo que pode ser testado independentemente) parte de todo o requisito é desenvolvida ou quando todo o requisito é desenvolvido.

como executar arquivos jar no windows

Deixe-me aprofundar ainda mais nesta fase e falar sobre as tarefas importantes:

  • O Testador / Equipe de Teste começa com a rodada de testes (teste exploratório e execução de casos de teste escritos) e registro de defeitos
  • A equipe de desenvolvimento os resolve de acordo com a prioridade.
  • A nova construção (código) é feita no ambiente em que o teste está acontecendo
  • Os defeitos resolvidos são então verificados pelo Testador / Equipe de Teste e marcados como Corrigidos
  • Este ciclo continua até que o critério de saída de tempo seja alcançado.
  • Observe que, conforme necessário, os defeitos também são marcados como inválidos, duplicados e também podem ser categorizados como aprimoramentos.

Outra coisa que difere de empresa para empresa é a quantidade de rodadas de testes a serem realizadas. Como em alguns casos, a primeira rodada de testes acontece em pequenas partes do recurso assim que estão prontas, seguida por uma rodada de testes ponta a ponta em outro ambiente, uma vez que todos os requisitos são desenvolvidos. Mas, novamente, eu também ouvi falar de pessoas fazendo três rodadas de teste completas adequadas e a quarta rodada como sanidade / fumaça.

A primeira agenda por trás de várias rodadas de teste é testar a funcionalidade em diferentes ambientes e a segunda para fazer testes de ponta a ponta, uma vez que todos os pontos da história são desenvolvidos. A rodada de sanidade geralmente acontece para ganhar confiança rápida, uma vez que todas as histórias em um lançamento são desenvolvidas e testadas independentemente.

Leia as etapas detalhadas=> Fase de execução de teste

# 7) Avaliação do analista de negócios (BA)

O analista de negócios revisa a funcionalidade solicitada referindo-se ao resultado do teste ou referindo-se ao resultado do teste, além de brincar com o aplicativo para obter uma sensação real. Esta etapa novamente está sujeita a diferentes ações nas empresas.

O BA pode revisar o escopo de toda a liberação de uma vez ou em partes. Dependendo do mesmo, esta etapa pode vir antes do teste final de sanidade ou após a rodada final de teste de sanidade pela equipe de teste.

As 7 etapas acima acontecem para todas as histórias de usuário / requisitos a serem cumpridos em determinada Liberação (Remessa). Depois que todas essas etapas forem concluídas para todos os requisitos, a liberação é considerada pronta para envio.

# 8) Remessa / Liberação

O lançamento é marcado como pronto para envio após revisão bem-sucedida pelo analista de negócios.

Leitura recomendada=> Processo de liberação de teste

Tipos de teste manual (leia-se humano)

Bem, se temos que falar sobre os tipos gerais de teste em números, então em algum lugar eu encontrei 100 tipos de teste com nomes diferentes . Para ser honesto, não sou inteligente o suficiente para entender a distinção entre todos esses tipos (trocadilho intencional).

É direto e simples: Testar a funcionalidade do aplicativo em relação aos requisitos fornecidos com esforços humanos e inteligência. Ele é dividido em alguns tipos com base no escopo e na agenda de testes. Tipos listados no próximo parágrafo.

Ele é dividido em alguns tipos com base no escopo e na agenda de testes. Tipos listados no próximo parágrafo.

Se eu puder, deixe-me falar algumas linhas de Teste Humano (que encorajo todos os testadores a fazerem apenas testes funcionais manuais). Agora, não se confunda, na minha opinião o teste funcional manual é um subconjunto do Teste Humano. Porque existem tantas coisas que apenas a mente humana pode fazer.

Abaixo está a lista com alguns dos tipos de teste populares e importantes que podem ser categorizados em Teste Humano:

  • Teste Funcional Manual : Testar a funcionalidade do aplicativo em relação aos requisitos fornecidos com esforços humanos e inteligência. Além disso, é dividido em alguns tipos com base no escopo e na agenda de testes, como teste de sistema, teste de unidade, teste de fumaça, teste de sanidade, teste de integração, teste de regressão, teste de IU, etc.
  • Teste de performance : Isso é categorizado em testes não funcionais, certo? Mas, novamente, é o humano que o implementa, embora a execução seja feita por um humano ou ferramenta. O testador deve pelo menos fazer este teste em termos de tempo de resposta (para ver se é aceitável) se ele não deve usar nenhuma ferramenta para teste de carga e tudo.
  • Navegador / Teste de compatibilidade de plataforma: O aplicativo em teste deve ter a aparência e funcionar conforme o esperado (obviamente, pode haver uma pequena diferença dependendo do mecanismo do navegador) entre navegadores e plataformas (ou dispositivos, se for um aplicativo móvel).
  • Testando usabilidade : Deixe-me concordar em primeiro lugar que este é um tópico enorme em si mesmo e geralmente propriedade de especialistas em testes de usabilidade. Ainda acredito que, como testadores, devemos pelo menos relatar ou destacar se encontrarmos algo menos utilizável, ou devemos compartilhar nossa opinião.
  • Teste de Segurança : Novamente um tipo de teste muito grande e requer muito conhecimento prático, é claro. O testador deve tentar aprender e executar pelo menos testes básicos como adulteração de URL, script entre sites, injeção de SQL, sequestro de sessão, etc., dependendo do conhecimento disponível e onde aplicável.
  • Teste de multilocação: Se seu aplicativo for multilocatário, ou seja, uma instância única contendo dados de vários clientes, este teste é obrigatório. Independentemente da menção explícita nos requisitos, isso deve ser feito. Os dados de um cliente sendo mostrados a outro é uma espécie de crime de desenvolvimento e teste.

Observação: As visualizações acima são minhas opiniões pessoais. Também recomendo que você dê uma olhada na extensa lista de tipos de teste para seu conhecimento e siga / use-os se achar necessário. Com o passar dos anos, entendi que, quer você use algo ou não, acredite em algo ou não, você ainda deve ter algum conhecimento de conceitos amplamente utilizados em sua área.

Isso é tudo para esta parte. Obrigado por ler. Compartilhe suas opiniões / feedback nos comentários.

Na próxima e última parte deste série de tutoriais de teste manual , Vou tentar ajudar todos vocês com qual preparação você deve fazer se quiser entrar no campo de testes e quais são as maneiras possíveis de entrar lá.

Leitura recomendada

^