what are iq oq pq 3 q s software validation process
Introdução ao IQ-OQ-PQ:
IQ, OQ e PQ constituem os 3Qs do Processo de Validação de Software.
Como testadores, todos sabemos que a Equipe de Desenvolvimento de Software desenvolve o software internamente de acordo com a Especificação de Requisitos de Software (SRS), Especificação Funcional e, posteriormente, a Equipe de Teste verifica a implementação em diferentes níveis de teste em vários ambientes de teste, do mais simples ao high end, o que, portanto, replica o ambiente de produção.
Com esta abordagem de SDLC, a Equipe de Desenvolvimento de Software geralmente sai de cena, entregando o software completo (desenvolvido e verificado) para a Equipe de Operações. Além disso, é a equipe de operações (geralmente referida como equipe de operações) que se encarrega de implantá-la em um ambiente de produção e torná-la pronta para ser usada pelos usuários finais.
Agora, aqui está o verdadeiro desafio para a Equipe de Operações em tornar o software funcional no ambiente de produção, pois durante as fases de desenvolvimento de software, o desenvolvimento e a verificação foram feitos em um ambiente simulado, e raramente próximo ao ambiente live, apenas em caso de disponibilidade de dados e configurações do ambiente de produção.
É aqui que a validação do software entra em cena. Uma vez que a verificação seja concluída e o software seja assinado pela equipe do Programa / Produto, a Equipe de Operações realizaria um conjunto de atividades antes de aceitar o software a ser implantado na produção, para provar que o software está se comportando conforme o esperado, o que nada mais é que as atividades de validação.
O que você aprenderá:
Verificação vs Validação
Aqui, vamos entender claramente a diferença entre as atividades de 'Verificação' e 'Validação'. ' Verificação 'É avaliar o software em relação ao determinado conjunto de requisitos e especificações que é feito internamente no site de Desenvolvimento de Software pelos Desenvolvedores e Testadores.
Enquanto ' Validação 'É um conjunto de verificações de garantia de qualidade que são realizadas por clientes externos, proprietários, fornecedores do produto que está sendo entregue a eles, para verificar a adequação antes de aceitar ou comprar o produto. As atividades de validação são realizadas principalmente no local de produção.
Portanto, no caso de Desenvolvimento de Aplicativos, é a Equipe de Operações que realiza as atividades de Validação do software.
Leia também:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Fases do processo de validação
Geralmente, o processo de validação de qualquer produto se refere ao ciclo de vida completo de um produto, desde o desenvolvimento até o uso e manutenção. E, portanto, o processo de validação é dividido em 5 fases.
5 fases do processo de validação são:
Esta abordagem de 5 fases do processo de validação está sendo seguida em muitas indústrias como manufatura, medicina, farmacêutica, etc. Aqui, a validação será feita pelo cliente final antes de comprar o maquinário, equipamento ou produto.
Os constituintes das atividades de validação de um software são provar que 'o software está pronto para ser consumido pelos usuários' e, principalmente, verificar a instalação bem-sucedida do software seguida pela funcionalidade e operabilidade.
Abordagem do 3Q: IQ-OQ-PQ
No entanto, no contexto do software, o Abordagem do 3Q, IQ-OQ-PQ está sendo seguido como parte da Validação e será realizado pela equipe de Operações, que é a responsável final por implantar o software na produção.
A seguir está o Diagrama de Fluxo do Processo de Validação:
O modelo, plano e quaisquer outros documentos que são de entrada para realizar os 3Ts, serão apresentados pela Equipe de Software para o seu software e inclui a abordagem detalhada, tarefas / atividades / testes a serem realizados como parte dessas qualificações ao longo com os resultados do teste.
Os relatórios resumidos serão entregues à equipe de operações durante a transferência do software, juntamente com os binários e outras entregas.
Em alto nível,
No geral, o objetivo de realizar IQ, OQ e PQ é garantir que o software possa ser implantado com sucesso e todas as funcionalidades possam ser usadas sem quaisquer gargalos.
Idealmente, IQ, OQ e PQ são as atividades sequenciais, que precisam ser executadas na ordem. A menos que a instalação seja feita, uma funcionalidade do software não pode ser verificada e, a menos que a funcionalidade seja comprovada, não há como medir o desempenho. Às vezes, devido à restrição de tempo, PQ pode começar em paralelo com OQ, uma vez que os principais aspectos do OQ são estabelecidos.
Agora, vamos entender mais sobre cada uma dessas três fases em detalhes.
Qualificação de instalação (IQ)
Qualificação de instalação também conhecida como ‘QI’ , é o processo de validação se o software fornecido (binários, scripts etc.) pode ser instalado com sucesso no ambiente especificado com as configurações especificadas e para verificar como essas etapas de instalação são registradas no documento denominado ‘Guia de Instalação’.
Os itens a seguir são fornecidos pela equipe de desenvolvimento junto com o pacote de software entregue e são usados pela equipe de operações para realizar o IQ.
1) Documento de ‘Guia de Instalação’, que documenta as etapas de instalação nos ambientes selecionados.
2) Documento do ‘Guia de configuração’ para definir o configurável do software. Às vezes, este documento torna-se parte do próprio documento do Guia de instalação.
3) Pacote de software e scripts de instalação, de preferência scripts automatizados.
A fase de qualificação de instalação de software é considerada a mais crucial e, normalmente, muitos problemas abrir durante esta fase.
Porque:
para) O ambiente de desenvolvimento não terá um ambiente 100% em tempo real disponível para verificar os problemas de instalação e, portanto, uma diferença no ambiente contribui para vários problemas.
b) Por vários motivos, pode não haver colaboração e coordenação suficientes entre o Desenvolvimento e a Equipe de Operações durante os estágios iniciais de desenvolvimento de software para lidar com os problemas com antecedência.
c) Pode haver alguns problemas de documentação ao registrar as etapas reais de instalação no documento, que podem não corresponder exatamente ao ambiente de produção.
Atualmente, todo o procedimento de instalação do software será automatizado tanto quanto possível por meio de uma série de scripts. Se houver algum problema com a instalação, a instalação automatizada falhará devido a qualquer correspondência incorreta nas configurações e será necessária a intervenção manual para corrigir esses problemas.
Como a equipe de operações realiza o IQ seguindo estritamente as instruções fornecidas pela equipe de software no guia de instalação, é muito importante e também responsabilidade da equipe de software garantir que o 'Guia de instalação' seja escrito de forma que o as etapas de instalação correspondem ao ambiente em tempo real.
E é responsabilidade dos Testadores garantir que o processo de 'Instalação' seja verificado internamente, juntamente com a verificação do documento quanto à sua integridade e identificar quaisquer erros de correspondência com as etapas reais a serem executadas no sistema em relação às etapas documentadas no Guia de instalação.
Os pontos a seguir devem ser mantidos em mente ao escrever um Guia de Instalação e verificá-los internamente, a fim de minimizar os problemas durante a instalação do software na produção.
| SNO | Pontos do Guia de Instalação |
|---|---|
| 7 | O tempo típico gasto para instalar o software deve ser mencionado no Guia de Instalação para que a Equipe de Operações tenha uma ideia sobre o tempo aproximado de instalação para planejar suas atividades de acordo. |
| 1 | Principalmente, o ‘Guia de Instalação’ deve ser escrito em uma linguagem simples e fácil de seguir. |
| dois | É preciso garantir que não fique muito tempo, mais de 5 páginas. Deve ser curto e limpo. |
| 3 | Precisa fornecer os números de série para cada etapa de execução para rastrear seu status. |
| 4 | Automatize as etapas o máximo possível e agrupe todas elas em um único script. |
| 5 | Um modelo padrão deve ser usado para escrever o procedimento de instalação. |
| 6 | Os pré-requisitos devem ser claramente mencionados para evitar o erro de correspondência e as etapas para verificá-los devem ser fornecidas. Se houver falha na correspondência, instruções para trazê-los até o nível esperado ou para instalar esses pacotes devem ser fornecidas. |
| 8 | Os serviços que precisam ser desativados durante a instalação, como desativá-los e o impacto de desativá-los, devem ser claramente mencionados no guia. |
| 9 | Deve-se evitar o fornecimento de links para outros documentos e a troca de um documento para outro. Todas as informações necessárias devem ser disponibilizadas no mesmo documento. Se documentos adicionais precisarem ser consultados, forneça-os junto com o pacote de software e, por sua vez, eles precisam ser consultados nos documentos principais. |
| 10 | É necessário garantir que o nome do script mencionado no documento seja o mesmo que está empacotado junto com o binário. |
| onze | Deve garantir que todos os scripts referidos no documento do Guia de instalação sejam fornecidos junto com o binário. |
| 12 | Certifique-se de que todos os parâmetros de configuração sejam claramente mencionados no Guia de instalação / Guia de configuração junto com os valores padrão e outros valores suportados. |
| 13 | Devem ser fornecidos testes automatizados para realizar os testes de verificação de build após a conclusão da instalação do software. Eles precisam ser em número mínimo e importantes para verificar se o build foi instalado com êxito. |
| 14 | 'Testes de fumaça' devem ser fornecidos para garantir que a conectividade de ponta a ponta do sistema seja perfeita e todos os componentes do sistema estejam se comunicando como esperado. |
| quinze | Em caso de falha na instalação do software, os scripts de rollback são fornecidos junto com o pacote e o procedimento de rollback é claramente escrito no Guia de Instalação para realizar rollback e restaurar o sistema com sucesso. |
Com todos os pontos acima a serem cuidados, é uma boa prática automatizar o processo de instalação do software com o mínimo de intervenção humana a fim de evitar erros humanos.
Se algum problema for encontrado durante a fase de validação de QI, ele será relatado à Equipe de Software, após a correção do mesmo, o teste de fumaça e os testes de verificação de construção será executado para verificar o sucesso da instalação do software.
Portanto, a fase de QI inclui a instalação do pacote de software seguida pela realização da verificação da compilação e testes de fumaça.
Portanto, a conclusão bem-sucedida da fase de QI é muito importante, pois uma instalação correta e bem-sucedida de um software garante que a maioria dos problemas relacionados a falhas de funcionalidade sejam negados.
Qualificação Operacional (OQ)
Qualificação operacional, também chamada de OQ é a próxima atividade do processo de validação de software após a conclusão bem-sucedida do IQ.
A atividade de qualificação operacional inclui t s testes a serem executados para verificar se o software está operacionalmente adequado para ser implantado junto aos consumidores. Idealmente, as principais funcionalidades do software são verificadas como parte desse processo de validação.
Um Plano OQ para realizar a Validação OQ precisa ser preparado pela Equipe de Software (Testadores), que deve abranger todos os aspectos do teste OQ que precisam ser realizados, incluindo os detalhes como no. de testes, cronograma de teste, metodologia, ferramentas, impacto no serviço, sequência de execução de teste, método de relatar problemas e os SLAs para corrigi-los, abordagem de Triagem de Defeito etc.,
Os testes de qualificação operacional que são executados como parte do OQ, são novamente fornecidos pela equipe de software junto com os produtos do software. Esses testes de qualificação operacional são uma coleção de testes importantes que são projetados com base no documento de 'Especificação de requisitos funcionais' para garantir que todo o sistema de software funcione de acordo com a expectativa.
Este Documento de Especificação de Teste OQ é preparado pelos Engenheiros de Teste em relação ao documento de Especificação de Requisitos Funcionais. Freqüentemente, este documento será o subconjunto do documento de Especificação de Teste do Sistema preparado e verificado durante a fase de teste do sistema do SDLC.
Os testes podem ser alterados ou atualizados para se adequarem aos requisitos da Equipe Operacional e às condições do local onde serão executados.
Portanto, deve-se tomar cuidado adicional ao selecionar os testes que fazem parte do OQ para garantir que todas as funcionalidades chave e os principais fluxos de trabalho de negócios sejam incluídos como parte desta verificação.
A seguir estão as dicas para testadores durante a preparação do documento de especificação de teste OQ.
| Sno | Dicas para testadores ao preparar o documento de especificação de teste OQ |
|---|---|
| 7 | Os casos de teste relacionados ao valor limite não precisam ser incluídos, o que verifica os valores extremos, mas usam os valores mais comuns usados no dia a dia como entradas, sempre que necessário. |
| 1 | Certifique-se de que os principais testes de funcionalidade para provar que as funções de software esperadas foram escolhidas e incluídas e, portanto, a rastreabilidade necessária para cada um dos casos de teste escritos estão disponíveis no documento OQ Test Spec. |
| dois | Certifique-se de que os testes são escritos ordenadamente com ações passo a passo, são autoexplicativos e podem ser compreendidos por um homem comum. |
| 3 | Não refira ou evite o uso de quaisquer termos técnicos nos casos de teste, tanto quanto possível, uma vez que o usuário deste documento pode não saber sobre essas terminologias e que os dados de teste usados ainda não existem no sistema. Fornece vários conjuntos de dados, caso o usuário queira executar os casos de teste mais de uma vez. |
| 4 | Mencionar claramente os pré-requisitos obrigatórios e opcionais para cada um dos testes. |
| 5 | Inclua a maioria dos casos de teste positivos para verificar a funcionalidade. |
| 6 | Inclua muito poucos casos de teste negativos para garantir que o comportamento do software seja o esperado em caso de entrada irrelevante e que o sistema seja capaz de lidar com os casos negativos com sucesso. |
| 8 | Mencione os valores de configuração a serem definidos, se for necessário alterar os valores padrão. |
| 9 | Forneça os casos de teste automatizados a serem executados, sempre que disponíveis. Certifique-se de que esses scripts de automação possam ser executados no sistema onde o OQ está sendo planejado. |
| 10 | Certifique-se de que cada caso de teste tenha os resultados 'Esperados' e 'Reais' claros como referência. E adicione comentários, se necessário, para explicar o resultado real. |
| onze | Também é necessário incluir os 'Critérios de aceitação' para cada um dos casos de teste. Os critérios de aceitação podem ser o status do sistema após a execução dos casos de teste. |
| 12 | Forneça os 'Dados de Teste' a serem usados para cada um dos testes com precisão. Tente fornecer os dados mais comuns ao vivo. E também alguns dados excepcionais, para garantir que o sistema também possa lidar com os casos excepcionais. Certifique-se de que os dados de teste usados ainda não existam no sistema. Fornece vários conjuntos de dados, caso o usuário queira executar os casos de teste mais de uma vez. |
| 13 | Se vários usuários operacionais estiverem executando os testes em diferentes locais em paralelo, forneça a instrução para realizar o teste de acordo com diferentes conjuntos de dados. |
| 14 | Forneça listas de verificação sempre que necessário para garantir que todas as configurações e pré-requisitos sejam definidos conforme o esperado antes de executar os testes. |
| quinze | Continue monitorando os logs, quando os testes estiverem em execução, se o acesso estiver disponível para o sistema. |
| 16 | Se possível e necessário, forneça um suporte de execução aos usuários operacionais durante a execução desses casos de teste. |
| 17 | Explique o método de relatar os problemas encontrados durante a execução. É melhor usar a ferramenta de rastreamento de bugs para rastrear os problemas. Monitore cada problema cuidadosamente e leve-o ao encerramento de acordo com os SLAs acordados. |
| 18 | Execute ‘Triagens de defeitos’ envolvendo as partes interessadas certas para entender os problemas críticos e graves e fornecer atualizações sobre esses problemas com frequência. |
| 19 | Forneça o modelo final de 'Relatório de Resumo de Execução de Teste OQ' para publicar os resultados finais após a conclusão da execução. |
Portanto, o Plano OQ e a Especificação de Teste assim preparados devem ser completamente revisados e aprovados pelas partes interessadas relevantes, principalmente para garantir que a cobertura não seja muito menor ou muito e todas as funcionalidades chave sejam cobertas.
A conclusão bem-sucedida do OQ demonstra que o software funcionará de acordo com suas especificações operacionais no ambiente selecionado e é a porta de entrada para mover o software em direção à sua produção e é o sinal para prosseguir com a próxima atividade do processo de validação que é PQ .
Qualificação de desempenho (PQ)
Depois de garantir o IQ bem-sucedido, a conclusão do OQ, a próxima atividade no processo de Validação é garantir se o produto / software atende aos aspectos de desempenho especificados sob a carga esperada de forma consistente, sem causar qualquer gargalo no ambiente de produção.
O aspecto principal do PQ é garantir que um software, quando instalado no sistema esperado, pode lidar com a carga dinâmica e atender ao tempo de resposta esperado e não trava sob os picos de carga e estresse ao lidar com usuários simultâneos.
Portanto, PQ é principalmente para garantir se os critérios de desempenho especificados para um software são alcançados ao longo de um período de tempo (talvez uma semana) em uma base confiável com condições de carga variáveis, como é o padrão ao vivo. Portanto, esses testes devem ser executados todos os dias para monitorar o comportamento do sistema de software e, portanto, o PQ levará um tempo para ser concluído até que seja garantido que o sistema foi testado quanto ao seu desempenho.
Idealmente, a Validação PQ é realizada após a conclusão do OQ, onde a funcionalidade do software é garantida e pode prosseguir com a verificação do aspecto de desempenho do produto ou software. Às vezes, devido à restrição de tempo, PQ pode começar em paralelo ao OQ, com base na confiança na porcentagem de conclusão do OQ.
É ideal realizar esses testes de desempenho no sistema ao vivo com o sistema totalmente carregado ou em condições semelhantes ao ao vivo e garantir que não haja gargalos nos aspectos de desempenho.
Os testes a seguir geralmente são executados como parte da Qualificação de desempenho. E a escolha dos testes varia de software para software.
# 1) Teste de disponibilidade: Para garantir que o software esteja continuamente disponível sem travar ou cair.
# 2) Teste de acessibilidade: Para garantir que o software seja facilmente acessível de todos os locais com a velocidade de desempenho esperada sem problemas.
# 3) Teste de carga: Para medir o comportamento do sistema sob a carga diária prevista e também nas condições de pico de carga.
# 4) Teste de estresse: Para medir o ponto de interrupção do sistema sob condições de carga extremas.
# 5) Teste de desempenho de rendimento: Para medir o tempo de resposta do sistema e para medir o TPS (transações por segundo)
# 6) Teste de escalabilidade: O sistema pode ser dimensionado para lidar com os usuários simultâneos esperados.
Os Cenários de Teste de Desempenho e os scripts automatizados correspondentes são preparados com base nos requisitos relacionados ao desempenho especificados nos documentos de ‘Especificação de Requisitos do Usuário’.
Semelhante a um Plano OQ, um plano QP detalhado que declara claramente a abordagem de teste, estratégia, plano e cronograma junto com as ferramentas deve ser preparado e executado com os executores QP.
A ferramenta de teste e monitoramento de desempenho precisa ser instalada no ambiente onde o PQ está sendo realizado para medir e relatar as métricas de desempenho.
A seguir estão as dicas para os testadores permitirem que a equipe de operações execute o PQ com sucesso.
| Sno | Dicas para os testadores habilitarem a equipe de operações |
|---|---|
| 7 | Orientar, apoiar e treinar a equipe de Operações para realização dos testes de desempenho no sistema. |
| 1 | Prepare os principais cenários específicos de negócios para realizar o teste de desempenho com base no URS. |
| dois | Certifique-se de que os testes sejam incluídos para provar que o sistema atende às expectativas de tempo de resposta, velocidade, escalabilidade e estabilidade sob várias condições de carregamento. |
| 3 | Certifique-se de que a carga especificada esteja disponível ou o método e as ferramentas para gerar a carga necessária sejam claramente mencionados nos respectivos casos de teste. |
| 4 | Mencione o pré-requisito para cada um dos cenários claramente, como as condições de pré-carregamento que devem existir no sistema, número de usuários simultâneos etc., |
| 5 | Mencione as ferramentas recomendadas para serem utilizadas na realização do teste de desempenho específico para cada categoria de teste e para cada teste. |
| 6 | Certifique-se de que o processo para monitorar as métricas de desempenho seja mencionado claramente. |
Após a conclusão bem-sucedida do PQ, atender aos requisitos de desempenho é muito importante, pois quaisquer desvios relacionados ao desempenho podem causar uma grande perda de negócios, criando desconforto para o usuário e a confiança no software a ser usado será perdida, levando à falha do software.
Em suma, t A tabela abaixo resume as atividades do IQ-OQ-PQ.
| QI | OQ | PQ | |
|---|---|---|---|
| o que | Para verificar o processo de instalação do software e como o processo é documentado | Para verificar o bom funcionamento do sistema | Clientes, proprietários, fornecedores, equipe de operações |
| Who | Clientes, proprietários, fornecedores, equipe de operações | Clientes, proprietários, fornecedores, equipe de operações | Clientes, proprietários, fornecedores, equipe de operações |
| Onde | No local do proprietário, local da equipe de operações, local ativo, ambiente semelhante ao produto | No local do proprietário, local da equipe de operações, local ativo, ambiente semelhante ao produto | No local do proprietário, local da equipe de operações, local ativo, ambiente semelhante ao produto |
| Quando | Quando o software é recebido da equipe de software, antes de OQ e PQ. | Antes de liberar o sistema para uso e após a conclusão bem-sucedida do QI | Antes de colocar o sistema para funcionar e depois de QI bem-sucedido, conclusão de QI |
A tabela abaixo explica as várias entradas para cada uma das fases de validação.
| Modelo | Entrada |
|---|---|
| QI | 1. Documento de Especificação de Projeto 2. Binários de software e outros scripts de instalação 3. Documento do Guia de Instalação 4. Documento do guia de configuração 5. Construir documento de verificação e teste de fumaça |
| OQ | 1. Documento de Especificação Funcional 2. Documento do Plano OQ 3. Documento de teste de qualificação operacional 4. Modelo de relatório de resumo de teste OQ 5. IQ concluído com sucesso |
| PQ | 1. Documento URS (Especificação de Requisitos do Usuário) 2. Documento do Plano PQ 3. Documento de teste de qualificação de desempenho 4. Modelo de relatório de resumo de teste PQ 5. IQ e OQ concluídos com sucesso |
Conclusão
Mesmo que o produto / software tenha passado por todos os estágios de verificação e não consiga provar qualquer um dos IQ-OQ-PQ, o resultado pode ser desastroso e incorrer em um custo enorme. Portanto, a conclusão bem-sucedida do IQ-OQ-PQ por si só é a transferência bem-sucedida do produto do local de desenvolvimento para o local de produção.
No geral, a conclusão bem-sucedida do processo de validação do IQ-OQ-PQ não só dá confiança no software, mas também dá paz de espírito ao cliente, proprietário, desenvolvedores de software e testadores.
para que serve o c ++?
A execução do IQ-OQ-PQ também reduz o risco de implantá-lo para viver, sem realizar testes e reduz o custo de falha e mitiga o risco de recall dos produtos.
Então, pessoal, desenvolvedores de software e testadores, nenhuma comemoração depois de concluir o desenvolvimento e os testes internos e liberar o software para a equipe de operações. A comemoração ocorre apenas quando o IQ-OQ-PQ é concluído com sucesso e o software está ativo no sistema de destino.
Portanto, o sucesso de um software depende da conclusão bem-sucedida do IQ-OQ-PQ e de quando o software está no ar e pronto para o consumo pelos usuários finais.
Sobre o autor: Este artigo foi escrito por um membro da equipe STH, Gayathri Subrahmanyam. Ela tem mais de 2 décadas de experiência na área de Teste de Software. Durante sua carreira de teste, ela fez muitas avaliações TMMI, trabalhos de industrialização de teste, configurações de TCOE, além de lidar com entregas de teste e implementou a prática de DevOps para um grande envolvimento. Mas de acordo com ela, o aprendizado nunca para ...
Compartilhe suas experiências sobre como realizar o processo de validação e nos informe se tiver alguma dúvida sobre este artigo.
Leitura recomendada
- Curso de Teste de Software: Qual Instituto de Teste de Software devo ingressar?
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Trabalho de assistente de controle de qualidade de teste de software
- Escolhendo o teste de software como sua carreira
- Trabalho de freelancer de redator de conteúdo técnico de teste de software
- Algumas perguntas interessantes da entrevista de teste de software
- Comentários e análises do curso de teste de software
- Programa de Afiliados da Ajuda do Teste de Software!