Menu

O que é teste de software? Mais de 100 tutoriais de teste manual gratuitos

what is software testing

Experimente Nosso Instrumento Para Eliminar Problemas

Um guia completo de teste de software com mais de 100 tutoriais de teste manual com definição de teste, tipos, métodos e detalhes do processo:

O que é teste de software?

O teste de software é um processo de verificação e validação da funcionalidade de um aplicativo para descobrir se ele satisfaz os requisitos especificados. É o processo de encontrar defeitos em um aplicativo e verificar onde o aplicativo funciona de acordo com os requisitos do usuário final.

O que é teste manual?

O Teste Manual é um processo no qual você compara o comportamento de um trecho de código desenvolvido (software, módulo, API, recurso, etc.) com o comportamento esperado (Requisitos).

O que você aprenderá:

Lista de tutoriais de teste manual de software

Esta é a série de tutoriais mais aprofundada sobre Teste de Software. Percorra os tópicos mencionados nesta série com cuidado para aprender as técnicas de teste básicas e avançadas.

Esta série de tutoriais enriquece seu conhecimento e, por sua vez, aprimora suas habilidades de teste.

Pratique teste manual de ponta a ponta, treinamento gratuito em um projeto ao vivo:

Tutorial # 1: Noções básicas de teste manual de software
Tutorial # 2: Introdução ao projeto ao vivo
Tutorial nº 3: Escrita de Cenário de Teste
Tutorial nº 4: Escreva um documento de plano de teste a partir do zero
Tutorial # 5: Escrevendo Casos de Teste de Documento SRS
Tutorial # 6: Execução de Teste
Tutorial nº 7: Rastreamento de bug e aprovação de teste
Tutorial # 8: Curso de Teste de Software

Ciclo de vida de teste de software:

Tutorial # 1: STLC

Teste da Web:

Tutorial # 1: Teste de aplicativo da web
Tutorial # 2: Teste Cross Browser

Gerenciamento de caso de teste:

o que é um bom downloader de música grátis

Tutorial # 1: Casos de teste
Tutorial # 2: Modelo de caso de teste de amostra
Tutorial nº 3: Matriz de rastreabilidade de requisitos (RTM)
Tutorial nº 4: Cobertura de teste
Tutorial # 5: Gerenciamento de dados de teste

Gerenciamento de teste:

Tutorial # 1: Estratégia de Teste
Tutorial # 2: Modelo de Plano de Teste
Tutorial nº 3: Estimativa de Teste
Tutorial nº 4: Ferramentas de gerenciamento de teste
Tutorial # 5: Tutorial do HP ALM
Tutorial # 6: Jira
Tutorial nº 7: Tutorial do TestLink

Testes técnicos:

Tutorial # 1: Teste de caso de uso
Tutorial # 2: Teste de transição de estado
Tutorial nº 3: Análise de valor limite
Tutorial nº 4: Particionamento equivalente
Tutorial # 5: Metodologias de teste de software
Tutorial # 6: Metodologia Ágil

Gerenciamento de defeitos:

Tutorial # 1: Ciclo de vida do bug
Tutorial # 2: Relatório de Bug
Tutorial nº 3: Prioridade de Defeito
Tutorial nº 4: Tutorial do Bugzilla

Teste funcional

Tutorial # 1: Teste de Unidade
Tutorial # 2: Teste de Sanidade e Fumaça
Tutorial nº 3: Teste de Regressão
Tutorial nº 4: Teste de Sistema
Tutorial # 5: Teste de aceitação
Tutorial # 6: Teste de integração
Tutorial nº 7: Teste de aceitação do usuário UAT

Teste não funcional:

Tutorial # 1: Teste Não Funcional
Tutorial # 2: Teste de performance
Tutorial nº 3: Teste de Segurança
Tutorial nº 4: Teste de segurança de aplicativos da Web
Tutorial # 5: Testando usabilidade
Tutorial # 6: Teste de Compatibilidade
Tutorial nº 7: Teste de Instalação
Tutorial # 8: Teste de Documentação

Tipos de teste de software:

Tutorial # 1: Tipos de teste
Tutorial # 2 : Teste de caixa preta
Tutorial nº 3: Teste de banco de dados
Tutorial nº 4: Teste de ponta a ponta
Tutorial # 5: Teste Exploratório
Tutorial # 6: Teste Incremental
Tutorial nº 7: Teste de Acessibilidade
Tutorial # 8: Teste Negativo
Tutorial # 9: Teste de Backend
Tutorial # 10: Teste Alfa
Tutorial # 11: Teste beta
Tutorial # 12: Teste Alfa vs Beta
Tutorial # 13: Teste Gama
Tutorial # 14: Teste ERP
Tutorial # 15: Teste Estático e Dinâmico
Tutorial # 16: Teste Adhoc
Tutorial # 17: Teste de localização e internacionalização
Tutorial # 18: Teste de automação
Tutorial # 19: Teste de caixa branca

Carreira de teste de software:

Tutorial # 1: Escolha de uma carreira de teste de software
Tutorial # 2: How to Get QA Testing Job - Complete Guide
Tutorial nº 3: Opções de carreira para testadores
Tutorial nº 4: Switch de teste de software não relacionado a TI
Tutorial # 5: Comece sua carreira de teste manual
Tutorial # 6: Lições aprendidas em 10 anos de testes
Tutorial nº 7: Sobreviver e progredir no campo de teste

Preparação da entrevista:

Tutorial # 1: Preparação de currículo de controle de qualidade
Tutorial # 2: Perguntas da entrevista de teste manual
Tutorial nº 3: Perguntas da entrevista de teste de automação
Tutorial nº 4: Perguntas da entrevista de controle de qualidade
Tutorial # 5: Lidar com qualquer entrevista de trabalho
Tutorial # 6: Obtenha trabalho de teste como um fresco

Testando aplicativo de domínio diferente:

Tutorial # 1 : Teste de aplicativo bancário
Tutorial # 2: Teste de aplicativos de saúde
Tutorial nº 3: Teste de gateway de pagamento
Tutorial nº 4: Sistema de Ponto de Venda de Teste (POS)
Tutorial # 5: Teste de site de comércio eletrônico

Teste de certificação de controle de qualidade:

Tutorial # 1: Guia de certificação de teste de software
Tutorial # 2: Guia de certificação CSTE
Tutorial nº 3: Guia de Certificação CSQA
Tutorial nº 4: Guia ISTQB
Tutorial # 5: ISTQB Avançado

Tópicos de teste manual avançado:

Tutorial # 1: Complexidade ciclomática
Tutorial # 2: Teste de migração
Tutorial nº 3: Teste de nuvem
Tutorial nº 4: Teste ETL
Tutorial # 5: Métricas de teste de software
Tutorial # 6: Serviços web

Prepare-se para dar uma olhada no primeiro tutorial desta série de testes manuais !!!

Introdução ao teste manual de software

O Teste Manual é um processo no qual você compara o comportamento de um trecho de código desenvolvido (software, módulo, API, recurso, etc.) com o comportamento esperado (Requisitos).

E como você saberá qual é o comportamento esperado?

Você saberá lendo ou ouvindo os requisitos com atenção e compreendendo-os completamente. Lembre-se de que compreender os requisitos completamente é muito importante.

gerador de número aleatório 0-1

Pense em você como um usuário final do que você vai testar. Depois disso, você não está mais preso ao documento de requisitos de software ou às palavras nele contidas. Você pode então entender o requisito principal e não apenas verificar o comportamento do sistema em relação ao que está escrito ou dito, mas também em relação ao seu próprio entendimento e em relação a coisas que não foram escritas ou contadas.

Às vezes, pode ser um requisito não atendido (requisito incompleto) ou implícito (algo que não precisa de menção separada, mas deve ser atendido), e você precisa testar isso também.

Além disso, um requisito não precisa ser necessariamente documentado. Você pode muito bem ter conhecimento da funcionalidade do software ou até adivinhar e testar uma etapa de cada vez. Geralmente o chamamos de teste ad-hoc ou teste exploratório.

Vamos dar uma olhada em profundidade:

Primeiro, vamos entender o fato - Esteja você comparando o teste de um aplicativo de software ou qualquer outra coisa (digamos um veículo), o conceito permanece o mesmo. Abordagem, ferramentas e prioridades podem ser diferentes, mas o objetivo central permanece o MESMO e é SIMPLES, ou seja, comparar o comportamento real com o comportamento esperado.

Em segundo lugar - O teste é como uma atitude ou mentalidade que deve vir de dentro. Habilidades podem ser aprendidas, mas você se tornará um testador de sucesso somente quando tiver algumas qualidades dentro de você por padrão. Quando digo que as habilidades de teste podem ser aprendidas, quero dizer educação formal e focada em torno do processo de teste de software.

Mas quais são as qualidades de um testador de sucesso? Você pode ler sobre eles no link abaixo:

Leia aqui => Qualidades de testadores altamente eficazes

Eu recomendo fortemente que você leia o artigo acima antes de continuar com este tutorial. Isso o ajudará a comparar suas características com as que são esperadas na função do Testador de Software.

Para quem não tem tempo para ler o artigo, aqui está uma sinopse:

“Sua curiosidade, atenção, disciplina, raciocínio lógico, paixão pelo trabalho e capacidade de dissecar coisas são muito importantes para ser um testador destrutivo e bem-sucedido. Funcionou para mim e acredito firmemente que funcionará para você também. Se você já tem essas qualidades, então realmente funcionou para você também. ”

Falamos sobre os principais pré-requisitos de tornando-se um testador de software. Agora vamos entender por que o Teste Manual tem e sempre terá sua existência independente com ou sem o crescimento do Teste de Automação.

Por que o teste manual é necessário?

Você sabe qual é a melhor coisa em ser um Testador, que também é um Testador Manual?

É o fato de que você não pode depender apenas do conjunto de habilidades aqui. Você tem que ter / desenvolver e aprimorar seu processo de pensamento. Isso é algo que você realmente não pode comprar por alguns dólares. Você mesmo tem que trabalhar nisso.

Voce terá que desenvolver o hábito de fazer perguntas e você terá que perguntar a eles a cada minuto quando estiver testando. Na maioria das vezes, você deve fazer essas perguntas a si mesmo do que aos outros.

Espero que você tenha lido o artigo que recomendei na seção anterior (ou seja, as qualidades de testadores altamente eficazes). Se sim, você saberia que o teste é considerado um processo de pensamento e o quão bem-sucedido você será como testador depende completamente das qualidades que você possui como pessoa.

Vamos ver este fluxo simples:

  • Você faz algo ( realizar ações ) enquanto você observa com alguma intenção (comparando com o esperado). Agora seu observação habilidades e disciplina para realizar coisas entra em cena aqui.
  • Voila! O que é que foi isso? Você notou algo. Você percebeu porque estava dando perfeito atenção aos detalhes na sua frente. Você não vai deixar pra lá porque você é curioso . Não estava em seu plano que algo inesperado / estranho acontecesse, você notará e investigará mais a fundo. Mas agora você está fazendo isso. Você pode deixar para lá. Mas você não deve esquecer.
  • Você está feliz, você descobriu a causa, as etapas e o cenário. Agora você comunicará isso de maneira adequada e construtiva para a equipe de desenvolvimento e outras partes interessadas em sua equipe. Você pode fazer isso por meio de alguma ferramenta de rastreamento de defeitos ou verbalmente, mas você tem que ter certeza de que está comunicá-lo de forma construtiva .
  • Ops! E se eu fizer assim? E se eu inserir um inteiro adequado como entrada, mas com espaços em branco à esquerda? E se? … E se? … E se? Não termina facilmente, não deve terminar facilmente. Você irá Imagine muitas situações e cenários e, de fato, você ficará tentado a executá-los também.

O diagrama abaixo representa a vida de um testador:

Vida de um testador

Leia os quatro pontos mencionados acima mais uma vez. Você percebeu que eu o mantive bem curto, mas ainda destaquei a parte mais rica de ser um testador manual? E você notou o destaque em negrito em algumas palavras? Essas são precisamente as qualidades mais importantes de que um testador manual precisa.

Agora, você realmente acha que esses atos podem ser completamente substituídos por qualquer outra coisa? E a tendência atual - ela pode ser substituída por automação?

Em SDLC com qualquer metodologia de desenvolvimento, poucas coisas sempre permanecem constantes. Como testador, você consumirá os requisitos, convertendo-os em cenários de teste / casos de teste. Em seguida, você executará esses casos de teste ou os automatizará diretamente (sei que algumas empresas fazem isso).

Quando você o automatiza, seu foco é constante, que é automatizar as etapas escritas.

Vamos voltar à parte formal, ou seja, executar os casos de teste escritos manualmente.

Aqui, você não se concentra apenas na execução dos casos de teste escritos, mas também realiza muitos testes exploratórios ao fazê-lo. Lembre-se, você está curioso? E você vai imaginar. E você não será capaz de resistir, você realmente fará o que imaginou.

A imagem abaixo mostra como a escrita de casos de teste é simplificada:

Escrita de Caso de Teste Simplificada

Estou preenchendo um formulário e não estou mais preenchendo o primeiro campo. Estou com preguiça de usar o mouse para mudar o foco para o próximo campo. Eu apertei a tecla ‘tab’. Eu terminei de preencher o próximo e último campo também, agora preciso clicar no botão Enviar, o foco ainda está no último campo.

Ops, eu acidentalmente apertei a tecla 'Enter'. Deixe-me verificar o que aconteceu. OU há um botão enviar, vou clicar duas vezes nele. Não satisfeito. Eu clico várias vezes, muito rápido.

Você notou? Existem tantas ações de usuário possíveis, tanto as intencionais quanto as não intencionais.

Você não conseguirá escrever todos os casos de teste que cobrem 100% do seu aplicativo em teste. Isso tem que acontecer de forma exploratória.

Você continuará adicionando seus novos casos de teste à medida que testa o aplicativo. Estes serão casos de teste para bugs que você encontrou para os quais não havia caso de teste escrito. Ou, enquanto você está testando, algo acionou seu processo de pensamento e você obteve mais alguns casos de teste que gostaria de adicionar ao seu conjunto de casos de teste e executar.

Mesmo depois de tudo isso, não há garantia de que não haja bugs escondidos . Software sem bugs é um mito. Você só pode ter como alvo levá-lo perto de Zero, mas isso simplesmente não pode acontecer sem uma mente humana almejando continuamente o mesmo, semelhante, mas não limitado ao processo de exemplo que vimos acima.

Pelo menos até hoje, não há software que pense como uma mente humana, observe como um olho humano, faça perguntas e responda como um humano e então execute ações intencionais e não intencionais. Mesmo que tal coisa aconteça, cuja mente, pensamentos e olhos ela imitará? Seu ou meu? Nós, humanos, também não somos iguais. Todos nós somos diferentes. Então?

Necessidade de teste manual quando há automação:

O Teste de Automação tem sua própria parcela de glória atualmente e terá ainda mais nos próximos anos, mas ele simplesmente não pode substituir o teste manual de controle de qualidade (leia teste humano / exploratório).

Você deve ter ouvido antes- ' Você não automatiza os testes, automatiza a verificação ’. Esta frase fala muito sobre onde está o teste de controle de qualidade manual com os testes de automação. Muitos grandes nomes em todo o mundo escreveram e falaram sobre este tópico, então não vou enfatizar muito isso.

A automação não pode substituir o Teste Humano porque:

  • Exige julgamentos de tempo de execução sobre tudo o que acontece na frente de seus olhos (enquanto você testa) e em alguns casos nos bastidores também.
  • Exige observação clara e constante.
  • Exige questionando.
  • Exige uma investigação.
  • Exige raciocínio.
  • Exige ações não planejadas conforme necessário durante o teste.

O teste pode ser substituído por uma ferramenta / máquina que será capaz de absorver os detalhes, processá-los, comandar ações e executá-las como uma mente humana e humana, e tudo isso em tempo de execução e em todos os contextos possíveis. Esta ferramenta novamente deve ser como todos os humanos possíveis.

Resumindo, o teste humano não pode ser substituído. Talvez algum filme de ficção científica de Hollywood em alguns anos se pareça com isso, mas na vida real, eu não posso ver isso por algumas centenas de anos, isso eu posso imaginar. Não vou descartá-lo para sempre, pois acredito em possibilidades infinitas.

Por outro lado, mesmo que realmente aconteça depois de algumas centenas de anos, a imagem que posso imaginar é a de um mundo assustador, com certeza. Age of Transformers. :)

= >> Leitura Recomendada - Melhores empresas de serviço de teste manual

Como a automação complementa o teste manual?

Eu disse antes e estou repetindo que a automação não pode mais ser ignorada. No mundo onde integração contínua, entrega contínua e implantação contínua estão se tornando coisas obrigatórias, o teste contínuo não pode ficar ocioso. Temos que descobrir maneiras de como fazer isso.

Na maioria das vezes, implantar mais e mais força de trabalho não ajuda a longo prazo para essa tarefa. Portanto, o Testador (Líder de Teste / Arquiteto / Gerente) deve decidir cuidadosamente sobre o que automatizar e o que ainda deve ser feito manualmente.

Está se tornando extremamente importante ter testes / verificações muito precisos escritos para que possam ser automatizados sem qualquer desvio da expectativa original e possam ser usados ​​durante a regressão do produto como parte do ‘Teste Contínuo’.

Observação: A palavra contínua do termo 'Teste Contínuo' está sujeita a chamadas condicionais e lógicas semelhantes aos outros termos que usamos acima com o mesmo prefixo. Contínuo neste contexto significa cada vez mais, mais rápido do que ontem. Embora tenha significado, pode muito bem significar a cada segundo ou nanossegundos.

Sem ter uma combinação perfeita de Testadores Humanos e verificações automatizadas (testes com etapas precisas, resultado esperado e critérios de saída do referido teste documentados), alcançar o Teste Contínuo é muito difícil e isso, por sua vez, tornará a integração contínua, entrega contínua e implantação contínua mais difícil.

Usei propositalmente o termo critério de saída de um teste acima. Nossos trajes de automação não podem mais ser semelhantes aos tradicionais. Precisamos ter certeza de que, se eles falharem, falharão rapidamente. E para fazê-los falhar rapidamente, os critérios de saída também devem ser automatizados.

Exemplo:

Digamos que há um defeito no bloqueador em que não consigo fazer login no Facebook.

A funcionalidade de login deve ser sua primeira verificação automatizada e seu conjunto de automação não deve executar a próxima verificação em que o login é um pré-requisito, como postar um status. Você sabe muito bem que está fadado ao fracasso. Portanto, faça com que falhe mais rápido, publique os resultados mais rapidamente para que o defeito possa ser resolvido mais rapidamente.

A próxima coisa é algo que você deve ter ouvido antes - Você não pode e não deve tentar automatizar tudo.

Selecione casos de teste que, se automatizados, se beneficiarão consideravelmente para Testadores Humanos e tem um bom retorno do investimento. Por falar nisso, existe uma regra geral que diz que você deve tentar automatizar todos os seus casos de teste de Prioridade 1 e, se possível, de Prioridade 2.

A automação não é fácil de implementar e é demorada, por isso é aconselhável evitar a automação dos casos de baixa prioridade pelo menos até o momento em que terminar com os de alta. Selecionar o que automatizar e focar nisso melhora a qualidade do aplicativo quando usado e mantido continuamente.

Conclusão

Espero que agora você já tenha entendido por que e como os testes manuais / humanos são necessários para entregar Produtos de Qualidade e como a automação os complementa.

Aceitar a importância do teste manual de controle de qualidade e saber por que ele é especial é o primeiro passo para ser um excelente testador manual.

Em nossos próximos tutoriais de teste manual, cobriremos uma abordagem genérica para fazer o teste manual, como ele coexistirá com a automação e muitos outros aspectos importantes também.

Tenho certeza de que você adquirirá imenso conhecimento sobre Teste de Software assim que ler toda a lista de tutoriais desta série.

converter ascii para int c ++

Gostaríamos muito de ouvir de você. Sinta-se à vontade para expressar suas idéias / sugestões na seção de comentários abaixo.

Leitura recomendada

^