Mais de 40 perguntas e respostas populares da entrevista com analistas de controle de qualidade (2021 LIST)

40 popular test qa analyst interview questions

Perguntas e respostas mais frequentes da entrevista do analista de teste / garantia da qualidade:

Ao decidir a carreira que deseja seguir, o fator decisivo não é apenas aquela em que você acha que pode gostar de trabalhar.

Mas estar nessa categoria requer muitas habilidades, compreender as responsabilidades, bem como as obrigações de trabalho necessárias para a carreira que você escolheu. O mesmo acontece ao escolher uma carreira como Analista de QA. Não requer apenas que você seja um bom testador, um aprendiz rápido e um pensador extraordinário, mas também um solucionador de problemas complexos.

Embora as qualidades acima mencionadas não sejam alcançadas instantaneamente, obviamente isso requer experiência e dias de trabalho árduo também.

Este artigo cobrirá todos os aspectos cujo conhecimento é obrigatório para ser um Analista de QA. As perguntas e respostas mais frequentes da entrevista do QA Test Analyst, incluídas aqui, darão uma ideia clara da preparação para a entrevista.

Perguntas populares da entrevista com analistas de teste de controle de qualidade

P # 1) Quais são as responsabilidades de um analista de QA?

Responda: Analista de QA é quem garante que todas as medidas possíveis foram tomadas para testar cada recurso da solução de software, tanto funcional quanto tecnicamente.

As principais responsabilidades do Analista de QA podem ser listadas da seguinte forma:

• Executar e gerenciar todas as atividades para cumprir os objetivos do plano de teste.
• Escolha os processos de alta qualidade para desenvolver o produto.
• Deve ser capaz de analisar os requisitos e documentar os procedimentos.
• Documente e verifique novamente todos os defeitos. Defina a prioridade e a gravidade dos defeitos.
• Eles devem ser capazes de criar, documentar e manter casos de teste.
• Análise dos resultados do teste.

P # 2) Qual é o seu entendimento sobre um plano de teste?

Responda: Quando você tem uma ideia clara do que, quando, como e quem, as coisas ficam mais fáceis. O mesmo é o caso com o teste de software também, onde o plano de teste é um documento que consiste em escopo, abordagem, recursos e esboço do projeto de teste, bem como as atividades para rastrear o andamento do projeto.

O plano de teste é um registro de processos que incluem:

• Tarefas de teste
• Ambiente de teste
• Técnicas de design
• Critérios de entrada e saída
• Quaisquer riscos, etc.

P # 3) Aliste a prioridade das tarefas de teste definidas pela equipe de QA no desenvolvimento do produto.

Responda: A prioridade das tarefas de teste são definidas da seguinte forma:

• Um plano de teste é preparado consistindo no esboço e escopo do projeto de teste.
• Os casos de teste são preparados para cobrir todas as funcionalidades principais e secundárias com os dados necessários para o teste.
• Execução dos casos de teste de acordo com as funcionalidades implementadas com as próximas compilações do projeto de teste no ciclo de teste.
• Relatório de defeitos com nova verificação, bem como acompanhamento de seu progresso.
• Preparando o resumo do relatório de execução de teste.

P # 4) Liste alguns dos principais desafios enfrentados durante a execução do Teste de Software.

Responda: Como dizemos que o teste completo nunca pode ser alcançado, há vários desafios envolvidos nele. Seja pequeno ou complicado, existem alguns desafios enfrentados ao realizar o teste de software de qualquer projeto.

Listados abaixo estão alguns desafios principais:

• Falta de testador habilidoso que geralmente enfrenta o problema de conscientização do assunto, bem como a falta de bom conhecimento do negócio do cliente.
• O tempo também é considerado o fator, já que geralmente os testadores se concentram principalmente na cobertura de tarefas, em vez da cobertura de teste com teste de qualidade, quando há uma lista enorme de tarefas a serem concluídas.
• Para decidir qual caso de teste deve ser executado primeiro e com prioridade. Isso geralmente é alcançado pela experiência de trabalho.
• Uma compreensão adequada dos requisitos que pode levar a todos os seus esforços de teste a zero, se o requisito for mal interpretado.
• Indisponibilidade das melhores ferramentas necessárias para concluir o teste com menos tempo e mais eficácia.
• Lidar com o relacionamento entre testadores e desenvolvedores com boa comunicação e habilidades de análise.

P # 5) Defina o teste de caso de uso.

Responda: O teste de caso de uso pode ser definido como a técnica de teste de caixa preta funcional que captura a série de interações que ocorreram entre os 'atores' e o 'sistema'. Aqui, 'Atores' são representados pelos usuários e suas interações.

As características do teste de caso de uso são listadas abaixo:

• Os requisitos funcionais do projeto são organizados.
• Registra o caminho ou cenários do início ao fim.
• Pode cobrir defeitos de integração, ou seja, os defeitos que ocorreram como resultado da interação entre diferentes componentes.
• Ele descreve os fluxos principais, bem como o fluxo excepcional dos eventos.
• Todas as pré-condições exigidas para o caso de uso funcionar devem ser especificadas anteriormente.

Q # 6) Defina a estratégia de teste.

Responda: Um conjunto de diretrizes ou abordagens de teste que geralmente são realizadas pelo gerente de projeto para determinar o design do teste e a abordagem geral de teste é definido como Estratégia de Teste. Ele é encontrado como uma pequena seção do plano de teste e é usado por vários projetos.

Diferentes abordagens de teste são seguidas com base em fatores como natureza e domínio do produto, risco de falha do produto, experiência em trabalhar com as ferramentas propostas, etc.

Essas abordagens são ainda categorizadas da seguinte forma:

• Abordagem proativa , onde a abordagem dos designs de teste começa antes da criação do build. Assim, ajuda a encontrar e corrigir os bugs antes da construção.
• Abordagem reativa , onde a abordagem de teste é iniciada após a conclusão do design e da codificação do teste.

P # 7) Explique a diferença entre controle de qualidade e garantia de qualidade.

Responda: 'Controle de qualidade' e 'Garantia da Qualidade' são os dois principais termos usados ​​em relação a qualquer projeto ou produto de teste. Normalmente, os testadores, que são novos neste campo, não entendem a diferença real entre os dois.

Vamos entender a diferença com a ajuda da tabela abaixo.

P # 8) De acordo com você, quando é o bom momento para iniciar o controle de qualidade em um projeto?

Responda: De acordo com o Ciclo de Vida de Desenvolvimento de Software (SDLC), a fase de Teste é executada após a conclusão da fase de ‘Implementação e Codificação’. Mas no cenário de hoje, para obter os melhores resultados, é necessário iniciar o controle de qualidade do projeto ou produto no início do projeto.

Seguir esta abordagem levará às principais vantagens fornecidas abaixo:

• Planejamento inicial do processo para atender às expectativas de qualidade do cliente.
• Comunicação boa e saudável entre as equipes.
• Fornece bastante tempo necessário para configurar o ambiente de teste.
• Permite a revisão e aprovação antecipada dos planos de teste.

Q # 9) Diferencie os processos de verificação e validação.

Responda: Os processos de verificação e validação são geralmente determinados por duas perguntas famosas, ou seja, “ Estamos construindo o sistema certo? ” e “Estamos construindo o sistema certo?” .

Vamos ver a outra diferença entre esses dois processos na tabela abaixo:

P # 10) Explique os benefícios dos testes destrutivos.

Responda: O teste destrutivo é definido como a forma de teste que é realizada pela equipe de teste para determinar o ponto de falha do produto sob diferentes cargas, ou seja, para avaliar o desempenho estrutural da aplicação para determinar sua resistência, tenacidade, dureza ou, digamos, robustez.

Listados abaixo estão os benefícios dos testes destrutivos:

• A fraqueza do design do aplicativo é determinada.
• Determine a vida útil do aplicativo.
• Ajuda a reduzir custos e falhas.

Q # 11) Como o reteste é diferente do teste de regressão?

Responda: Existem várias diferenças entre reteste e teste de regressão.

Isso pode ser facilmente compreendido na tabela abaixo:

P # 12) O que você sabe sobre testes orientados a dados?

Responda: É muito claro para cada testador de automação que os scripts de teste de automação cobrem apenas a área do aplicativo a ser testada com uma sequência registrada de ações do usuário. Normalmente, essas ações não produzem nenhum erro, pois apenas os dados de entrada são obtidos nas condições que inserimos durante a gravação.

O teste baseado em dados entra em cena aqui, onde queremos que o aplicativo funcione conforme o esperado para qualquer tipo de valor de entrada. Para este propósito, os dados necessários para o teste orientado a dados não são codificados, mas os scripts de teste obtêm seus dados de fontes de dados como arquivos CSV, fontes ODBC, etc.

Para resumir, o teste baseado em dados executa as seguintes ações no loop:

qual é o melhor removedor de spyware

• Pega dados de teste de entrada do armazenamento.
• Dados inseridos no aplicativo para realizar ações.
• Verifique os resultados reais com os esperados.
• Repita novamente as mesmas etapas com novos dados de teste de entrada.

Q # 13) O que é a matriz de rastreabilidade? É necessário para todos os projetos?

Responda: A matriz de rastreabilidade em qualquer projeto é o meio de acompanhar o andamento do projeto no que diz respeito à implementação de novas funcionalidades, melhoria das funcionalidades existentes, etc. Através de uma matriz de rastreabilidade, você pode sempre acompanhar o andamento do projeto com todos os aspectos mantidos de acordo com a data.

A matriz de rastreabilidade de requisitos consiste nos parâmetros mencionados abaixo que, na verdade, estão de acordo com o documento de especificação de requisitos.

Os parâmetros da matriz de rastreabilidade de requisitos incluem:

• Cada seção do documento de requisitos é um ponto a ser coberto no RTM (Matriz de Rastreabilidade de Requisito).
• O título de cada ponto é o título de cada seção na especificação de requisitos.
• Correspondendo a cada ponto, ids de caso de teste são mencionados, os quais são escritos para aquela seção particular.
• BUG / New Feature ID também é mencionado em cada seção.
• O ponto mais importante é que o rastreamento do recurso também é mantido no qual a construção do projeto e seu recurso foram implementados.
• Outro parâmetro inclui se a seção foi totalmente testada ou ainda está em status de teste.

Q # 14) Descreva os benefícios do teste Agile.

Responda: Sendo um testador, o foco passa a ser entregar o produto de qualidade em menos tempo, entendendo os requisitos do usuário final e, o mais importante, sem defeitos do lado do usuário final. Aqui, o teste Agile entra em cena, que segue o princípio do desenvolvimento ágil de software e valida rapidamente os requisitos do cliente.

Mencionados abaixo estão os benefícios do teste Agile:

• Uma equipe multifuncional ágil é incluída no teste, que por sua vez entrega os resultados em intervalos frequentes.
• Economiza muito tempo e dinheiro.
• Inclui menos documentação e feedback periódico do usuário final.
• Não apenas o testador, mas toda a equipe, incluindo o gerente, o cliente e o desenvolvedor, estão envolvidos na comunicação face a face.
• Como resultado das reuniões diárias, os problemas podem ser bem determinados com antecedência.
• Aumento da produtividade da equipe e um melhor entendimento dos aspectos técnicos do projeto.

P # 15) O que é teste negativo?

Responda: O teste negativo é o método de garantir que a estabilidade de um produto ou aplicativo seja mantida ou, digamos, não falhe quando uma entrada inesperada é fornecida. O objetivo principal desta forma de teste valida o aplicativo em relação a quaisquer dados de entrada inválidos possíveis.

Esta forma de teste também é conhecida como 'Teste de falha' ou 'teste de caminho de erro' e seu objetivo principal é verificar a confiabilidade da função do aplicativo em cenários negativos. Ele também expõe fraquezas do software, identifica as falhas e dá uma ideia clara da corrupção de dados.

P # 16) Diferencie o teste ad-hoc do teste exploratório?

Responda: Existem várias diferenças entre o teste Ad-hoc e o teste Exploratório.

Vamos ver as diferenças na tabela abaixo:

P # 17) Por que o teste de automação é preferido ao teste manual?

Responda: Bem, os testes de automação e os testes manuais têm sua importância e existência no mundo dos testes.

A seguir são apresentados alguns aspectos importantes devido aos quais o Teste de Automação é preferível ao Teste Manual:

• O mesmo script de teste pode ser usado todas as vezes para executar o teste, portanto, o teste de automação é considerado o mais confiável e eficiente.
• Principalmente preferido no caso de teste de regressão e execução repetida.
• Os testes de automação são considerados econômicos no caso de execução de longo prazo e, portanto, garantem uma melhor qualidade do software.
• Os scripts de teste são reutilizáveis, rápidos e todos podem ver os resultados.
• As ferramentas usadas para testes de automação são mais rápidas e confiáveis ​​quando comparadas à abordagem manual.

Embora, mais alguns fatores determinem que o teste de automação é preferível ao teste manual. O acima mencionado são os principais fatores.

P # 18) O que você entende por 'eficácia do teste' e 'eficiência do teste'?

Resposta: Teste de Eficiência pode ser definido como o cálculo do número de recursos e código de teste consumido para realizar ou, digamos, executar uma função específica. Ele também determina o número de recursos utilizados na criação do produto de software.

Isso pode ser determinado pela fórmula:

Eficiência de teste = (Número de defeitos resolvidos / número total de defeitos enviados) * 100

Eficácia do teste pode ser definido como a medida de avaliação do ambiente de teste e seu efeito no aplicativo de software. Aqui, a resposta do cliente é avaliada quando o requisito do aplicativo é atendido.

Isso pode ser determinado pela fórmula:

Eficácia do teste = (Número de defeitos encontrados / Número de casos de teste executados)

Q # 19) Explique o processo de Adaptação do Projeto.

Responda: A adaptação do projeto é um processo consistente e contínuo que garante que o desempenho do projeto esteja correto e de acordo com os requisitos do negócio. Todo o processo inclui a revisão e modificação dos dados do projeto de acordo com a necessidade operacional atual da organização.

O processo de revisão é feito no nível organizacional, mas a implementação dos planos de adaptação é feita no nível do projeto. O objetivo principal e os requisitos da organização, bem como o relacionamento com o cliente e o usuário, são os dois principais fatores que devem ser considerados no processo.

Alguns aspectos de acordo com as metas organizacionais no processo de adaptação são:

• Abordagem do projeto
• Estratégias
• Controles e processos envolvidos
• Papéis e responsabilidades

Q # 20) Como você diferencia entre Prioridade e Gravidade do defeito dentro do projeto?

Responda: Tanto a 'Prioridade' quanto a 'Gravidade' são atribuídas ao bug para categorizar os problemas / bugs de acordo com a ordem em que eles devem ser corrigidos. Estes são baseados em vários fatores.

Vamos entender mais junto com suas diferenças na tabela abaixo:

P # 21) Por que o teste de desempenho é necessário para ser feito para qualquer aplicativo?

Responda: Em uma linguagem simples, o teste de desempenho é feito para determinar o comportamento e a resposta de um aplicativo em várias situações. Isso ajuda a reunir informações sobre estabilidade, escalabilidade, velocidade do aplicativo, etc.

As razões para fazer o teste de desempenho podem ser entendidas a partir dos pontos abaixo:

• Ele determina o tempo de resposta e o desempenho de um componente do aplicativo na carga de trabalho.
• O tempo de resposta da atividade do usuário é calculado.
• Requer programadores experientes com extensa linguagem técnica.
• Determina o comportamento do aplicativo sob carga, ou seja, quando o número do usuário aumenta instantaneamente.

P # 22) O que são testes orientados por especificações?

Responda: Como o próprio nome define, o teste orientado a especificação é feito com base na especificação de requisitos da aplicação, onde as especificações funcionais servem como base para os testes executados.

Esta forma de teste é igual ao 'teste de caixa preta', em que o usuário insere vários dados e, em seguida, a saída é observada. É apropriado em todos os níveis de teste com especificação e plano de teste.

Q # 23) Explique o CMMI.

Responda: CMMI significa Capability Maturity Model Integration. Este modelo foi desenvolvido pelo Software Engineering Institute (SEI). Parte do princípio de que os processos envolvidos na gestão e desenvolvimento de um produto ou sistema determinam a qualidade.

Ele também fornece diretrizes para melhoria de processos para o produto ou mesmo para toda a organização.

O CMMI é dividido em 5 níveis, conforme listado abaixo:

• Nível 1: Inicial
• Nível 2: Gerenciou
• Nível 3: Definiram
• Nível 4: Gerenciado Quantitativamente
• Nível 5: Otimizado

P # 24) Explique as vantagens de implementar o CMMI.

Responda: Existem várias vantagens na implementação do CMMI.

Eles estão listados a seguir:

• Ele fornece cobertura detalhada e relatórios do ciclo de vida do produto e, portanto, ajuda nas melhorias do processo.
• Os padrões existentes da organização, seus processos e procedimentos são aprimorados como parte da implementação do CMMI.
• Como resultado da implementação do CMMI, há um aumento na entrega no prazo e na satisfação do cliente.
• Também leva a um gerenciamento eficaz e maior economia de custos, pois há detecção precoce de erros.

P # 25) Conte com algumas ferramentas de teste de automação.

Responda: Algumas das ferramentas de teste de automação são listadas abaixo:

• Selênio
• agua
• Moinho de vento
• SABÃO
• Telúrio

P # 26) Podemos fazer testes de regressão em testes de unidade?

Responda: Com certeza. O teste de regressão serve para testar o defeito indesejado que pode ter sido introduzido no código como um efeito colateral da correção de outros defeitos. O teste de unidade é a execução de teste de execução de uma pequena parte independente e individual do código.

O teste de regressão pode ser feito em qualquer nível, desde o teste de unidade até o teste de integração e, finalmente, o teste de aceitação. O teste de regressão é um teste baseado em perspectiva, enquanto o teste de unidade é a abordagem de nível (Bottom Up, Top-down).

Q # 27) Qual é a diferença entre o teste de fumaça e o teste de sanidade?

Responda:

• O teste Smoke é o teste dos antigos recursos proeminentes ou recursos existentes do build, enquanto o teste Sanity é a validação de módulos recém-adicionados, defeitos corrigidos no build.
• O teste de fumaça acontece primeiro e depois é seguido pelo teste de Sanidade.
• O teste de fumaça cobre o teste de funcionalidades críticas fornecidas pelo software, de forma que se estende por todo o software. Os testes de sanidade, por outro lado, são restritos apenas aos módulos adicionados recentemente e são testados em profundidade.

Q # 28) Quais são suas atividades diárias como testador manual em seu escritório?

Manual: A primeira coisa que verifico em meu sistema é atualizar o painel para o status dos requisitos / aprimoramentos ou bugs na iteração atual. Ele é seguido por chamadas e relatórios diários de scrum, discussões e sessões de brainstorming para definir cenários de teste e casos de teste.

Esses casos são executados depois de reformulados de acordo com a revisão. O contato com clientes para requisitos não funcionais também é uma das principais atividades em meu prato.

Q # 29) Quais são suas atividades diárias como membro do testador de automação em seu escritório?

Automação: Meu dia começa com uma reunião diária de status que discute os resultados da automação de ontem, caso eu tenha disparado um lote de casos de teste na nova compilação.

O ciclo de execução pode ser chamado de Verificação de Saúde, para ver o quão saudável está a compilação.

É seguido por relatórios de defeitos com base nas falhas de script, alterações de design na funcionalidade; manter os scripts / bibliotecas ou funções, automatizar e fazer o check-in em um novo script para os novos requisitos e, se necessário, uma nova função na biblioteca de funções.

Às vezes, os scripts de teste precisam ser reexecutados individualmente para encontrar defeitos de regressão por meio da automação e adicioná-los ao conjunto de testes também.

P # 30) Como você diferencia entre um requisito, um defeito e uma melhoria?

Responda : PARA requerimento é uma história de usuário que é essencial para ser implementada, testada e entregue.
A Aprimoramento é um recurso adicionado ou improvisado ao existente.
PARA defeito é um desvio completo das histórias de usuário esperadas.

Além disso, se um defeito descobrir uma determinada área de um requisito que não é declarado, a menos que de outra forma na especificação, ele também pode ser chamado como um requisito ou parte dele.

Q # 31) O que você faz quando seu desenvolvedor nega ter corrigido um bug que você registrou?

Responda : Um fator importante que decide a correção de um defeito é a “Prioridade” que lhe é atribuída. Se o defeito for de alta prioridade, um bloqueio de exibição, que bloqueia uma funcionalidade principal e é reproduzido de forma consistente, então é necessário consertar na compilação.

O mesmo deve ser transmitido aos desenvolvedores de forma eficaz, pois, juntos, testadores e desenvolvedores contribuem para a qualidade do produto a ser enviado.

Outros aspectos que podem ajudar a convencer o desenvolvedor a consertar um bug em um curto período são os relatórios de qualidade do bug e fazer os desenvolvedores entenderem o fato de que a correção do bug é de primordial importância no lançamento.

Q # 32) O que você faz quando seu desenvolvedor nega que o que você registrou É UM BUG?

Responda : A fase mais importante do ciclo de vida do defeito é ‘Rejeitado’, o que significa que o relatório de incidente registrado não é válido. O documento de requisitos de negócios que declara os requisitos pode ajudar a entender o software e, portanto, a natureza do incidente relatado.

Analise o bug e exponha suas descobertas sobre o bug ao desenvolvedor e à equipe. Se for um defeito, nunca deixe de registrá-lo. Às vezes, os testadores precisam fornecer uma análise de lacunas e apresentá-la aos desenvolvedores. Se isso não resolver os conflitos, o pessoal sênior da equipe deve contribuir.

Q # 33) O que vem primeiro Re-teste ou teste de regressão?

Responda : O reteste vem primeiro, pois é uma nova execução do código, em termos mais simples, é uma execução repetida de etapas predefinidas. Não precisa ser necessário após corrigir um código. Mas um teste de regressão serve para avaliar os efeitos colaterais de um defeito resolvido.

Certamente, resolver um defeito e adicionar outro ao código não é o propósito do processo de teste. As melhores descobertas e melhores capturas dos testadores são geralmente defeitos de regressão. Um build nunca deve ser lançado sem ser testado por regressão.

Q # 34) Qual é uma alternativa ao teste beta?

Responda : O teste beta é realizado no local do cliente com o mínimo de envolvimento dos desenvolvedores, registrando as falhas no ambiente de produção real. Se tal prática não for realizada por uma empresa, uma ideia mais segura pode ser enviar o produto primeiro para os clientes que não estão na fila para obter a última construção.

Por alguns dias, certos consultores de serviço nas instalações dos clientes podem usar o software, registrar e monitorar as atividades que garantem a estabilidade da versão em seu ambiente, de modo que mesmo que um grande bug seja deixado de fora para ser corrigido possa ser testado antes entregando-o ao cliente-alvo. Outra abordagem é a troca de testes dos requisitos dentro de uma equipe para testes imparciais.

Q # 35) Quais são as desvantagens da implementação / metodologia Agile que você enfrentou?

Responda : As desvantagens são as seguintes:

1. Sprints geralmente são muito limitados em prazos.
2. A documentação não é a prioridade
3. Alternar entre PBIs (Itens do Backlog do Produto) pode ser frequente.

Q # 36) Por que a análise de impacto é importante?

Responda : Para praticar com base em riscos, a análise de impacto deve ser feita. Ao fazer isso, os casos de teste podem ser projetados de forma que todos os bugs graves, críticos do ponto de vista do cliente, possam ser resolvidos antes do tempo. Deve-se cuidar de um bom estudo do negócio, da necessidade do cliente e do uso do software.

Por exemplo, o risco mais importante associado ao software no domínio bancário é a segurança. Qualquer novo formulário adicionado ao software já existente pode ser vulnerável. Uma boa quantidade de testes de segurança é aconselhável adicionando links apropriados, redirecionamento e navegação para a página apropriada, instalando proxy se necessário.

Q # 37) Com a ajuda de um exemplo, cada teste de desempenho, teste de estresse e teste de carga?

Responda : O melhor caso aqui que pode ser obtido é um site ao vivo.

Teste de performance é feito para verificar as falhas no sistema quando submetido a uma condição semelhante a um cenário em tempo real. Não é necessário ser executado sob condições de estresse. Os resultados dos testes de desempenho ajudam a estabelecer se o sistema está pronto para entrar em produção.

Para um fluxo simples de reserva de bilhetes, um problema de desempenho pode ter causado lentidão. Por exemplo, algumas consultas que usam joins são um pouco mais lentas, pois implementaram cláusulas desnecessárias ou armazenamento de dados de forma inadequada no banco de dados.

Teste de estresse é um tipo de teste de desempenho executado colocando o software em condições extremas (cargas pesadas e não distribuídas, recursos computacionais limitados, alta simultaneidade).

Se um sistema exibe certo comportamento, como dados perdidos ou corrompidos, recurso utilizado mesmo após a remoção do estresse, irresponsividade ou exceções não tratadas, isso significa que falhou no teste de estresse. Às vezes, falha de disco, um aumento desnecessário das contagens GDI também pode ser o resultado.

Por exemplo, Se o site hospedado em uma máquina que já está consumindo muita memória ou bombardeando com solicitações repetidas, não deve travar ou fazer logout.

Teste de carga está observando o comportamento do sistema enquanto aumenta constantemente a carga no sistema até que um limite seja alcançado. Modelos de carga de trabalho, métricas e níveis de carga geralmente são a entrada para o teste de carga.

Por exemplo, o tempo para buscar a disponibilidade de assento para um trem aumenta gradualmente quando o tempo de reserva da cota Tatkal se aproxima, já que o número de usuários então conectados ao sistema aumenta com o tempo de reserva Tatkal se aproximando das 10h00 ou 11h00.

Q # 38) Qual foi um de seus maiores desafios ao fazer o teste de regressão?

Responda : Pode haver vários desafios ao realizar o teste de regressão.

• Reexecutar testes repetidamente pode não ser tão empolgante para os testadores.
• É demorado, já que às vezes esse tipo de teste precisa de pensamento fora da caixa.
• Valor de negócio comprometido.
• A seleção inadequada de casos de teste de regressão pode ignorar um defeito de regressão importante a ser encontrado.
• Reproduzir o defeito na produção, portanto, torna-se inconsistente.
• Grande suíte para executar.

Q # 39) Se você for solicitado a documentar cenários de teste, casos de teste, planos de teste, estratégia de teste, o que você começará e em que sequência seguirá o restante?

Responda : A sequência será Estratégia de Teste, Plano de Teste, Cenários de Teste e finalmente Casos de Teste.

Q # 40) E se eu deixar de documentar qualquer um dos itens acima? Dizer que sinto falta de documentar o plano de teste e quais serão as consequências?

Responda : Se perdermos a documentação do plano de teste, haverá um vazio para o escopo do teste de sua abordagem objetiva e ênfase no teste. Então, será difícil determinar os recursos a serem testados, as técnicas de teste, os critérios de aprovação ou reprovação e, em última análise, o principal risco associado ao teste.

Q # 41) Como você começaria a testar a construção que obteve recentemente: existe alguma abordagem que você segue, por exemplo, primeiro comece o teste de fumaça, depois o teste de sanidade?

Responda : Teste de fumaça> Teste de sanidade> Teste exploratório> Teste de funcionalidade> Teste de regressão e validação do produto final.

Q # 42) Explique o formato do relatório de bug que você seguiu?

Responda :

Um relatório de bug deve conter as seguintes informações:

• Id do Bug
• Mapeamento para requisito / aprimoramento / bug existente
• Resumo / título do bug
• Uma versão do produto
• Prioridade
• Configuração (especificações do sistema)
• Pré-requisitos
• Degraus
• Resultado esperado
• Resultado real
• Histórico. Instantâneos, videoclipes
• Status
• Outras observações

Q # 43) Como você seleciona casos de teste de regressão ou forma o conjunto de testes de regressão?

Responda : Sim. Este é um resultado da análise de impacto. É um mapeamento simples dos recursos usados ​​ou acessados ​​em diferentes áreas que você está testando, sua integração com outros recursos e como um sistema de ponta a ponta ou teste de fluxo.

Você também pode selecionar defeitos previamente arquivados para a mesma funcionalidade em compilações anteriores. Idealmente, um defeito deve ser testado por regressão usando pelo menos cinco casos de teste diferentes que usam a funcionalidade.

Q # 44) Você pode vir com um exemplo dos seguintes defeitos

• Defeito de baixa prioridade e alta gravidade
• Defeito de alta prioridade e baixa gravidade

Responda : Um defeito que trava o aplicativo quando reproduzido apenas em um determinado carimbo de data / hora em um sistema operacional específico pode ser de Alta Severidade e um defeito de baixa prioridade.

Um defeito apresentado em uma visualização que não abre com um clique duplo, mas com um clique com o botão direito, pode ser um defeito de alta prioridade e baixa gravidade.

Q # 45) Escreva um caso de teste eficaz para testar se um determinado artigo é um white paper?

Responda: Se a cor da tinta de origem com a qual você escreve no papel branco permanecer a mesma, o papel é branco. Por exemplo, se você escrever em um papel branco com tinta vermelha, a cor da tinta permanece vermelha na caneta e aparece vermelha no papel também.

Observação: Existem muitas outras respostas para esta pergunta. Você pode chegar a pensar em qualquer resposta válida com uma lógica subjacente.

Q # 46) O que são testes de fretamento?

Responda: Um teste de sessão realizado com base nas metas e agendas listadas em um regulamento antes de começar o teste é conhecido como teste de regulamento.

O teste aqui é feito em um intervalo de tempo fixo com menos foco na documentação e mais foco apenas no teste. É uma variante diferente de teste exploratório em que os engenheiros de teste verificam o software em um período de tempo ( Por exemplo, apenas 2 horas) com base em algumas heurísticas desenvolvidas.

Q # 47) Qual é a sua abordagem quando você tem um lançamento de alta prioridade para ser entregue em um tempo muito curto?

Responda: Durante esses casos, um plano bem elaborado pode ser benéfico.

O seguinte pode ser feito para auxiliar o teste em um cenário de escassez de tempo: -

• Usando scripts de automação atualizados existentes para executar testes de regressão.
• Testar cenários baseados em fluxo de ponta a ponta.
• Executar casos de teste de alta prioridade e, se o tempo permitir, alternar para os casos de prioridade mais baixa.
• Testando novamente os bugs de alta prioridade arquivados em versões anteriores.
• Teste rápido de software
• Os desenvolvedores podem ser solicitados a executar testes de unidade para obter mais cobertura nos testes.

Q # 48) Escreva casos de teste em qualquer dispositivo / objeto presente ao redor (exemplo: uma cadeira)?

Responda: Um conselho aqui seria: Sempre comece reunindo requisitos. Mostra sua maturidade em relação ao Ciclo de Vida de Desenvolvimento de Software. Sinta-se à vontade para fazer perguntas após selecionar o objeto.

Nesse caso:-

• Que tipo de cadeira é? Cadeira de escritório, cadeira de mesa de estudo, cadeira de sofá, cadeira de mesa de jantar, cadeira confortável?
• Que material é usado para fazer a cadeira - madeira, aço, plástico, estofamento?
• Pergunte sobre as dimensões (altura, peso com base no tipo de cadeira).
• Solicite disponibilidade. E com base nisso comece a esboçar seus casos.

Os casos de teste seriam diferentes para cada tipo de cadeira, o que é melhor deixar para sua capacidade de raciocínio ( Por exemplo, finalidade da cadeira, dimensões de acordo com o tipo de cadeira, portátil-não potável, peso leve, opções de compra).

Para cada cadeira, um O caso de teste de desempenho pode ser: para derivar a resistência à tração ou a capacidade máxima de suporte de peso.

Q # 49) Tudo pode ser automatizado?

Responda: - Até certo ponto sim. Mas as ferramentas de automação, como outros softwares, têm suas limitações. Além disso, o software em teste ou o aplicativo em teste continuarão sendo atualizados.

Portanto, não há garantia de que os testes de software possam ser executados sem intervenção manual. Afinal, uma ferramenta é tão inteligente quanto o testador. É apenas um teste de software de outro software. É o código / scripts / bibliotecas que precisa ser inteligente o suficiente para testar e encontrar defeitos.

Conclusão

Espero que este exercício o ajude a se aquecer com algumas perguntas e dê um ótimo começo para suas entrevistas e refine sua confiança ao responder às perguntas. Além disso, pode haver outras questões baseadas em cenários, aquelas que podem surgir de seu currículo / perfil.

Portanto, é sempre aconselhável praticar uma entrevista simulada com a própria mão, de modo que a entrevista seja uma situação ganha-ganha para o entrevistador e o candidato. Lembre-se de que um analista de qualidade é mais do que um engenheiro de teste, cujo feedback é importante não apenas para a qualidade do produto, mas também para o processo seguido para testar o software.

Obrigado e boa sorte com as entrevistas!

Leitura recomendada

• Perguntas e respostas da entrevista
• Mais de 25 perguntas e respostas mais populares da entrevista ADO.NET
• 25 melhores perguntas e respostas da entrevista para testes ágeis
• Perguntas da entrevista de Spock com respostas (mais populares)
• Perguntas e respostas da entrevista de teste de ETL
• 20 perguntas e respostas mais populares da entrevista TestNG
• Mais de 30 perguntas e respostas populares para entrevistas com pepinos
• As 50 perguntas e respostas mais populares da entrevista do CCNA