Menu

Fluxo de processo de controle de qualidade de teste de software prático (requisitos para liberação)

practical software testing qa process flow

Experimente Nosso Instrumento Para Eliminar Problemas

Uma visão geral completa do fluxo do processo de teste de software de QA de ponta a ponta:

Nota - Estamos republicando esta postagem útil com conteúdo atualizado.

O trabalho de um profissional de teste de software não é fácil. Está repleto de desafios, o que também exige. Os testadores devem estar alertas e entusiasmados em cada fase do ciclo de vida do aplicativo.

Embora existam desafios, existem várias oportunidades tremendas também para aprender e explorar os vários aspectos das metodologias de teste, processos e, claro, o software em detalhes.

O papel de um engenheiro de teste começa muito cedo. E, desde a conceituação do projeto, os testadores estão envolvidos em discussões com o proprietário do produto, gerente de projeto e várias partes interessadas.

Requisitos para liberação

Este tutorial sobre “Fluxo do processo de teste de software” oferece uma visão geral completa das várias fases do STLC, juntamente com os desafios envolvidos e as melhores práticas para superar esses desafios de uma maneira facilmente compreensível.

O que você aprenderá:

Requisito para liberação - uma visão geral completa

Ciclo de vida de teste de software

Desde o requisito até a liberação, cada fase é explicada claramente. Vamos dar uma olhada neles em detalhes.

# 1) Requisito

Um projeto não pode decolar sem ter um requisito claro. Esta é a fase mais crucial em que as ideias precisam ser escritas em um documento bem compreensível e formatado. Se você faz parte do projeto em que está participando da fase de coleta de requisitos, considere-se com sorte.

qual é um bom conversor de youtube para mp3

Quer saber por quê? É porque você está testemunhando um projeto a partir do zero. Embora haja orgulho em ser desde o início, ele também traz algumas responsabilidades e desafios.

Desafios

Não se pode imaginar todos os requisitos para reunir em uma única sessão. Seja paciente o suficiente.

Muitas discussões acontecerão, algumas das quais podem ser simplesmente irrelevantes para o seu projeto, mas mesmo assim podem conter algumas informações vitais para o seu projeto. Às vezes, a velocidade das discussões pode exceder sua capacidade de compreensão ou você simplesmente não prestaria atenção ao product owner.

A imagem abaixo destaca as etapas cruciais envolvidas na coleta de requisitos:

Ciclo de vida de requisitos

Cada informação perdida tem um grande impacto no entendimento geral e no teste do projeto. Para superar isso, aqui estão algumas práticas recomendadas que devem ser seguidas durante esta fase.

Melhores Práticas

  • Mantenha sua mente aberta e preste atenção a cada palavra do proprietário do produto.
  • Não se limite a ouvir, limpe a sua dúvida, por menor que seja.
  • Sempre use cadernos para anotações rápidas. Você deve usar um laptop, apenas se realmente puder digitar a uma velocidade razoável.
  • Repita as frases e esclareça-as do PO que você acha que entendeu.
  • Desenhe diagramas de bloco, texto de link, etc. para tornar os requisitos mais claros em um período posterior.
  • Se as equipes estiverem em locais diferentes, tente fazer um WebEx ou gravação semelhante. Sempre será útil quando você tiver uma dúvida após o término das discussões.

Embora não haja uma parede separada para cada fase, os requisitos mudam mesmo muito tarde no desenvolvimento. Portanto, a ideia é pegar a maior parte dos requisitos e documentar isso corretamente.

Uma vez documentado com todos os pontos necessários, distribua e discuta todos os stakeholders para que quaisquer sugestões ou alterações sejam percebidas com antecedência e antes de prosseguir, todos estejam na mesma página.

# 2) Estratégia de Teste

Os testadores devem apresentar uma estratégia de teste que não seja apenas suficiente para testar melhor o software, mas que também inspire confiança em todas as partes interessadas em relação à qualidade do produto.

Estratégia de Teste

Desafios

O aspecto mais crucial desta fase é criar uma estratégia que, quando trabalhada, deve entregar um produto de software livre de erros, sustentável e aceito por seus usuários finais.

As estratégias de teste são algo que você não mudará a cada dois dias. Em alguns casos, você também precisa discutir suas estratégias de teste com os clientes. Portanto, esta parte deve ser tratada com grande importância.

Melhores Práticas

  • Aqui estão algumas das práticas recomendadas que, quando seguidas, podem fornecer um grande alívio e resultar em testes tranquilos.
  • Leia o documento de requisitos mais uma vez. Destaque os pontos de importação em relação ao ambiente do software de destino.
  • Faça uma lista de ambientes onde o software será realmente implantado.
  • Os ambientes podem ser entendidos como um tipo de Sistema Operacional ou Dispositivos Móveis.
  • Se o Windows for o sistema operacional, liste todas as versões da janela onde você testará seu software. Se as versões viz. O Windows 7, Windows 10 ou Windows Server (s) ainda não estão definidos no documento de requisitos, então é a hora de discuti-los.
  • Em uma observação semelhante, obtenha os navegadores de destino com as versões discutidas e documentadas se o AUT for um sistema baseado na web.
  • Faça uma lista de todos os softwares de terceiros de que o aplicativo precisará (se necessário / compatível). Estes podem incluir Adobe Acrobat, Microsoft Office, quaisquer add-ons, etc.

Aqui, a ideia por trás é manter todas as plataformas, dispositivos e softwares necessários e exigidos que nosso aplicativo precisará para funcionar antes de nós para que uma estratégia abrangente possa ser formulada.

A figura abaixo ajudará você a entender o esboço da estratégia de teste se você estiver trabalhando em um projeto ágil:

Estratégia de Teste

# 3) Planejamento de Teste

Depois que os testadores estão munidos de todas as informações sobre o AUT, a fase de planejamento é onde a Estratégia é implementada.

Como uma estratégia de teste, o planejamento de teste também é uma fase crucial.

Plano de teste

Desafios

Como o sucesso (ou falha) do AUT depende muito de como os testes foram realizados, essa fase se torna um aspecto importante de todo o ciclo de vida do teste. Porque? Porque uma parte do teste é definida nesta fase.

Para superar alguns desafios, essas práticas recomendadas podem ser realmente úteis.

Melhores Práticas

  • Lembre-se sempre de não deixar pedra sobre pedra quando for testar sua aplicação.
  • É hora de formular uma estratégia de teste.
  • Crie uma matriz do ambiente para que o software seja testado em todas as plataformas.
  • Como, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Como o navegador Chrome Android 4.2.2+.
  • Se sua aplicação trabalhar com múltiplos bancos de dados (se documentado), mantenha os bancos de dados (MySQL, Oracle, SQLServer) na matriz de teste de forma que fiquem muito integrados com alguns testes.
  • Configure as máquinas de teste de acordo e nomeie-as como SetUp1, SetUp2, etc.
  • SetUp1 terá Windows 7+ IE 10+ Office 2007+.
  • SetUp2 pode ter Windows 10+ IE Edge + Office 2013+.
  • SetUp3 pode ter um telefone Android com seu arquivo .apk instalado.
  • Parabéns! Sua configuração de teste está pronta e você também incluiu todas as combinações possíveis de plataformas nas quais seu aplicativo funcionará.

# 4) Teste

Encontrando Bugs

Finalmente, o build do seu aplicativo foi lançado e você está pronto para encontrar bugs! Agora é hora de trabalhar no planejamento do teste e encontrar o máximo de bugs possível. Haverá algumas fases intermediárias se você trabalhar em um ambiente ágil, então simplesmente siga esses métodos scrum.

O diagrama abaixo descreve a categorização de vários tipos de teste:

Tipos de teste

Desafios

O teste é um processo complicado que está sujeito a erros! Muitos desafios são encontrados durante o teste de um aplicativo. A seguir estão algumas das melhores práticas de resgate.

Melhores Práticas

Alegrar! Você está tentando encontrar defeitos no código. Você precisa prestar atenção ao funcionamento geral do software.

  • É sempre aconselhável olhar para o aplicativo com um novo visual, SEM PASSAR POR CASOS DE TESTE.
  • Siga o caminho de navegação do seu software (AUT).
  • Familiarize-se com o AUT.
  • Agora leia os casos de teste (Todos) de qualquer módulo em particular (talvez de sua escolha).
  • Agora vá para o AUT e compare as descobertas com aquelas mencionadas na seção esperada dos casos de teste.
  • A ideia por trás disso é testar todos os recursos mencionados em todas as plataformas suportadas.
  • Anote cada desvio, por mais trivial que pareça.
  • Anote as etapas de como chegar a qualquer desvio, faça capturas de tela, capture logs de erros, logs do servidor e qualquer outra documentação de suporte que possa provar a existência de defeitos.
  • Não hesite em perguntar. Embora você tenha o documento de requisitos, haverá momentos em que você ficará em dúvida.
  • Entre em contato com os desenvolvedores (se eles sentarem ao seu lado ou forem acessíveis) em dúvida antes de falar com o Product Owner. Compreenda a perspectiva do desenvolvedor sobre o funcionamento do software. Compreendê-los. Se você sentir que esta implementação não está de acordo com o requisito, informe o gerente de teste.

# 5) Antes do lançamento

Antes de lançar qualquer produto no mercado, a qualidade do produto deve ser garantida. Os softwares são desenvolvidos uma vez, mas na verdade são testados até serem substituídos ou removidos.

Desafios

O software deve ser testado rigorosamente para muitos de seus parâmetros.

Os parâmetros não podem ser limitados a:

  • Funcionalidade / Comportamental.
  • Desempenho.
  • Escalabilidade.
  • Compatível com as referidas plataformas.

O desafio também é prever a taxa de sucesso de um aplicativo que depende de muitas iterações do teste executado.

Melhores Práticas

  • Certifique-se de que todos os recursos em todas as plataformas foram testados.
  • Destaque as áreas que não foram testadas ou aquela que precisa de mais esforços de teste.
  • Mantenha uma matriz de todos os resultados do teste antes do lançamento. A matriz de teste dará uma visão geral da estabilidade do produto. Também ajudará a administração a fazer uma chamada sobre as datas de lançamento.
  • Forneça sua opinião / sugestões à equipe sobre suas experiências durante o teste do produto.
  • Sua opinião, considerando-se o usuário final, irá beneficiar o software em geral.
  • Devido à falta de tempo ou qualquer outra situação semelhante, perdemos alguns testes ou não nos aprofundamos nisso. Não hesite em informar o status do teste ao seu gerente.
  • Apresente o cartão de saúde do aplicativo às partes interessadas. Os cartões de saúde devem ter um número de todos os defeitos registrados, abertos, fechados e intermitentes, com sua gravidade e prioridade.
  • Elabore um documento de lançamento e compartilhe-o com a equipe.
  • Trabalhe no documento de liberação preparado.
  • Melhorar as áreas que são sugeridas pela direção / equipe.

A imagem abaixo mostra o mapa do ciclo de vida da versão do software:

Antes do lançamento

# 6) Lançamento

Finalmente, chega a hora em que temos de entregar o produto aos usuários pretendidos. Todos nós, como uma equipe, trabalhamos muito para aprovar o produto e permitir que o software ajudasse seus usuários.

Desafios

Os engenheiros de teste de software são os principais responsáveis ​​pelo lançamento de qualquer software. Esta atividade requer um fluxo de trabalho orientado para o processo. Aqui estão algumas das melhores práticas envolvidas nesta fase.

Melhores Práticas

  • Lembre-se sempre de que você não está trabalhando no documento de lançamento na data de RELEASE.
  • Sempre planeje a atividade de lançamento antes da data de lançamento real.
  • Padronize o documento de acordo com as políticas da empresa.
  • Seu documento de lançamento deve tentar estabelecer expectativas positivas do software.
  • Mencione todos os requisitos de software e hardware específicos para suas versões claramente no documento.
  • Inclui todos os defeitos abertos e sua gravidade.
  • Não esconda as principais áreas impactadas devido a defeitos abertos. Dê a eles um lugar no documento Release.
  • Faça com que o documento seja revisado e assinado digitalmente (pode variar de acordo com a política da empresa).
  • Esteja confiante e envie o documento de lançamento junto com o software.

Processo de teste de controle de qualidade em um projeto real - método em cascata

Eu tenho uma pergunta interessante de um leitor, Como os testes são realizados em uma empresa, ou seja, em um ambiente prático?

Quem acaba de sair da faculdade e começa a procurar emprego tem essa curiosidade - como seria o real ambiente de trabalho em uma empresa?

Aqui, concentrei-me no processo de trabalho real de Teste de software nas empresas .

Processo de teste real nas empresas

Sempre que recebemos qualquer novo projeto, há uma reunião inicial de familiaridade com o projeto. Nesta reunião, basicamente discutimos quem é o cliente? qual a duração do projeto e quando é sua entrega? Quem está envolvido no projeto, ou seja, gerente, líderes de tecnologia, líderes de QA, desenvolvedores, testadores, etc.?

A partir do plano de projeto SRS (especificação de requisitos de software) é desenvolvido. A responsabilidade dos testadores é criar um plano de teste de software a partir deste SRS e do plano de projeto. Os desenvolvedores começam a codificar a partir do design. O trabalho do projeto é dividido em diferentes módulos e esses módulos do projeto são distribuídos entre os desenvolvedores.

Enquanto isso, a responsabilidade de um testador é criar um cenário de teste e escrever casos de teste de acordo com os módulos atribuídos. Tentamos cobrir quase todos os casos de teste funcional do SRS. Os dados podem ser mantidos manualmente em alguns modelos de casos de teste do Excel ou ferramentas de rastreamento de bugs.

Quando os desenvolvedores terminam os módulos individuais, esses módulos são atribuídos aos testadores. O teste de fumaça é executado nesses módulos e se eles falharem neste teste, os módulos são reatribuídos aos respectivos desenvolvedores para uma correção.

Para os módulos aprovados, o teste manual é realizado a partir dos casos de teste escritos. Se for encontrado algum bug que seja atribuído ao desenvolvedor do módulo e seja registrado no ferramenta de rastreamento de bugs . Na correção de bug, um testador faz verificação de bug e teste de regressão de todos os módulos relacionados. Se o bug passar na verificação, ele é marcado como verificado e fechado. Caso contrário, o ciclo de bug mencionado acima será repetido. (Vou cobrir o ciclo de vida do bug em outra postagem)

Diferentes testes são realizados em módulos individuais e testes de integração na integração de módulos. Esses testes incluem testes de compatibilidade, ou seja, testes de aplicativos em diferentes hardwares, versões de sistemas operacionais, plataformas de software, navegadores diferentes, etc.

Testes de carga e estresse também são realizados de acordo com o SRS. Finalmente, o teste do sistema é executado criando um ambiente de cliente virtual. Uma vez que todos os casos de teste são executados, um relatório de teste é preparado e é tomada a decisão de lançar o produto!

Etapas nos requisitos para liberação

A seguir são apresentados os detalhes de cada etapa de teste realizada em cada qualidade de software e ciclo de vida de teste especificado por Padrões IEEE e ISO.

# 1) Revisão SRS : Revisão das especificações dos requisitos de software.

# 2) Objetivos estão definidas para versões principais.

# 3) Data Prevista planejado para os lançamentos.

# 4) Plano de Projeto Detalhado É construído. Isso inclui a decisão sobre as especificações do projeto.

# 5) Desenvolver plano de teste baseia-se nas especificações de design.

# 6) Plano de Teste: Isso inclui objetivos, a metodologia adotada durante o teste, recursos a serem testados e não a serem testados, critérios de risco, cronograma de teste, suporte multiplataforma e a alocação de recursos para teste.

# 7) Especificações de teste: Este documento inclui detalhes técnicos (requisitos de software) necessários antes do teste.

# 8) Escrita de casos de teste

  • Fumaça ( BVT ) casos de teste
  • Casos de teste de sanidade
  • Casos de teste de regressão
  • Casos de Teste Negativos
  • Casos de teste estendidos

# 9) Desenvolvimento: Os módulos são desenvolvidos um a um.

# 10) Vinculação dos instaladores: Os instaladores são construídos em torno do produto individual.

como abrir um arquivo .dat

#onze) Procedimento de construção : Uma construção inclui instaladores dos produtos disponíveis - várias plataformas.

# 12) Teste: Smoke Test (BVT): Teste de aplicação básico para tomar uma decisão sobre testes adicionais.

  • Teste de novos recursos
  • Cross-browser e teste de plataforma cruzada
  • Teste de estresse e teste de vazamento de memória.

# 13) Relatório de resumo de teste

# 14) Congelamento de código

  • Nenhum outro recurso novo é adicionado neste momento.

# 15) Teste: Teste de construção e regressão.

# 16) Decisão de liberação do produto.

# 17) Cenário pós-lançamento para outros objetivos.

Este foi um resumo de um processo de teste real em um ambiente de empresa.

Conclusão

O trabalho de um testador de software é cheio de desafios, mas é agradável. Isso é para alguém que é igualmente apaixonado, motivado e cheio de entusiasmo. Encontrar defeitos em alguém nem sempre é uma tarefa fácil! Isso requer muitas habilidades e um alvo para os defeitos.

Além de todas as qualidades, um testador também deve ser orientado para o processo. Como todas as outras indústrias, os projetos de TI também são trabalhados em fases, onde cada fase tem alguns objetivos bem definidos. E cada meta tem um critério de aceitação bem definido. Um engenheiro de teste tem que carregar muitas cargas de qualidade de software em seus ombros.

Ao trabalhar em qualquer fase do software, os testadores devem seguir as melhores práticas e devem se alinhar com o processo envolvido nas respectivas fases. Seguir as melhores práticas e processos bem formulados não apenas ajuda a facilitar o trabalho dos testadores, mas também ajuda a garantir a qualidade do software.

Você participou de alguma das fases acima? Sinta-se à vontade para compartilhar suas experiências abaixo.

Leitura recomendada

^