O que é teste de software? 100+ Tutoriais de Teste Manual Gratuitos

Um Guia Completo de Teste de Software com 100+ Tutoriais de Teste Manual com Definição, Tipos, Métodos e Detalhes do Processo de Teste:

O que é Teste de Software?

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 uma aplicação e verificar onde a aplicação funciona de acordo com os requisitos do usuário final.

O que é teste manual?

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

Lista de tutoriais de testes manuais de software

Esta é a série mais aprofundada de tutoriais sobre testes de software. Percorra os tópicos mencionados nesta série cuidadosamente para aprender as técnicas básicas e avançadas de testes.

Esta série de tutoriais enriqueceria o seu conhecimento e, por sua vez, melhoraria as suas habilidades de teste.

Practice End-to-End Manual Testing Free Training on a Live Project:

Tutorial #1: Basics of Manual Software Testing
Tutorial #2: Live Project introduction
Tutorial #3: Test Scenario Writing
Tutorial #4: Write a Test Plan Document from Scratch
Tutorial #5: Writing Test Cases from SRS Document
Tutorial #6: Execução de Teste
Tutorial #7: Rastreamento de Bug e Sinal de Teste
Tutorial #8: Curso de Teste de Software

Ciclo de Vida de Teste de Software:

Tutorial #1: STLC

Teste Web:

Tutorial #1: Teste de Aplicações Web
Tutorial #2: Teste de Cross Browser

Test Case Management:

Tutorial #1: Casos de Teste
Tutorial #2: Modelo de caso de teste
Tutorial #3: Matriz de Rastreabilidade de Requisitos (RTM)
Tutorial #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 #3: Estimação de teste
Tutorial #4: Ferramentas de gerenciamento de teste
Tutorial #5: Tutorial HP ALM
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Técnicas de teste

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

>

Gerenciamento de efeitos:

Tutorial #1: Ciclo de vida do bug
Tutorial #2: Relatório de erros
Tutorial #3: Prioridade de defeitos
Tutorial #4: Tutorial Bugzilla

Testes funcionais

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

>

Teste não funcional

Tutorial #1: Teste não funcional
Tutorial #2: Teste de desempenho
Tutorial #3: Teste de segurança
Tutorial #4: Teste de segurança de aplicações Web
Tutorial #5: Teste de usabilidade
Tutorial #6: Teste de Compatibilidade
Tutorial #7: Teste de Instalação
Tutorial #8: Teste de Documentação

Testes de Software Tipos:

Tutorial #1: Tipos de Testes
Tutorial #2: Teste da caixa preta
Tutorial #3: Teste da base de dados
Tutorial #4: Teste do fim ao fim
Tutorial #5: Teste exploratório
Tutorial #6: Teste incremental
Tutorial #7: Teste de Acessibilidade
Tutorial #8: Teste Negativo
Tutorial #9: Teste 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 Automatização
Tutorial #19: Testes de Localização e Internacionalização
Tutorial #19: Testes de Localização e Internacionalização White box testing

Tutorial de teste de software

Tutorial #1: Escolhendo uma carreira de teste de software
Tutorial #2: Como obter um trabalho de teste de QA – Guia completo
Tutorial #3: Opções de carreira para testadores
Tutorial #4: Não-IT para Software Testing Switch
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lições Aprendidas de 10 Anos em Testes
Tutorial #7: Sobreviver e Progresso no Campo de Testes

Preparação de Entrevista:

Tutorial #1: Preparação do Currículo de GQ
Tutorial #2: Perguntas da Entrevista de Teste Manual
Tutorial #3: Perguntas da Entrevista de Teste de Automação
Tutorial #4: Perguntas da Entrevista de GQ
Tutorial #5: Lidar com Qualquer Entrevista de Trabalho
Tutorial #6: Obter o Trabalho de Teste como um Fresco

Testando Aplicação de Domínio Diferente:

Tutorial #1: Teste da Aplicação Bancária
Tutorial #2: Teste da Aplicação de Cuidados de Saúde
Tutorial #3: Teste do Portal de Pagamentos
Tutorial #4: Teste do Sistema de Ponto de Venda (POS)
Tutorial #5: Teste do Website de Comércio Eletrônico

Teste da Certificação de Garantia de Qualidade:

Tutorial #1: Guia de Certificação de Teste de Software
Tutorial #2: Guia de Certificação CSTE
Tutorial #3: Guia de Certificação CSQA
Tutorial #4: Guia ISTQB
Tutorial #5: ISTQB Avançado

Tópicos de Testes Manuais Avançados:

>

Tutorial #1: Complexidade Ciclomática
Tutorial #2: Migration Testing
Tutorial #3: Cloud Testing
Tutorial #4: ETL Testing
Tutorial #5: Software Testing Metrics
Tutorial #6: Web Services

Pronto para dar uma olhada no 1º tutorial desta série de Testes Manuais !!!

Introdução ao Teste Manual de Software

Testes Manuais é um processo no qual você compara o comportamento de um código desenvolvido (software, módulo, API, recurso, etc.) com o comportamento esperado (Requirements).

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

Você saberá lendo ou ouvindo atentamente os requerimentos e compreendendo-os completamente. Lembre-se, compreender os requisitos completamente é muito importante.

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

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

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

Vamos ter um In-Depth Look:

Primeiro, vamos entender o facto – Quer esteja a comparar o teste de uma aplicação de software ou outra coisa (digamos um veículo), o conceito permanece o mesmo. Abordagem, ferramentas e prioridades podem ser diferentes, mas o objetivo central continua sendo o SAME e é SIMPLES, ou seja, comparar o comportamento real com o comportamento esperado.

Segundo – Testar é como uma atitude ou mentalidade que deve vir de dentro. Habilidades podem ser aprendidas, mas você só se tornará um testador bem-sucedido quando tiver algumas qualidades dentro de você, por padrão. Quando eu digo que habilidades de teste podem ser aprendidas, quero dizer educação focada e formal em torno do processo de teste de software.

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

Leia aqui =>Qualidades dos testadores altamente eficazes

>

Recomendo vivamente a leitura do artigo acima antes de continuar com este tutorial. Ele irá ajudá-lo a comparar suas características com as que são esperadas no papel do Testador de Software.

Para aqueles que não têm tempo para analisar o artigo, aqui está uma sinopse:

“Sua curiosidade, atenção, disciplina, pensamento lógico, paixão pelo trabalho e capacidade de dissecar coisas importa muito para ser um Testador Destrutivo e Bem-Sucedido. Funcionou para mim e eu acredito firmemente que funcionará para você também. Se você já tem essas qualidades, então, de fato, também tem que funcionar para você”.

Conversamos sobre os pré-requisitos essenciais para se tornar um testador de software. Agora vamos entender porque o Teste Manual tem e sempre teria sua existência independente com ou sem o crescimento do Teste Automático.

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 melhorar o seu processo de pensamento. Isto é algo que você não pode realmente comprar por poucos dólares. Você mesmo tem que trabalhar nisso.

Você terá que desenvolver o hábito de fazer perguntas e você terá que fazê-las a cada minuto quando você estiver testando. Na maioria das vezes você deve fazer essas perguntas a si mesmo do que aos outros.

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

Vejamos este simples fluxo:

• Você faz algo (executar ações) enquanto observa com alguma intenção (comparando com o esperado). Agora suas habilidades de observação e disciplina para executar as coisas entram em cena aqui.
• Voila! O que foi isso? Você notou algo. Você notou porque você estava dando perfeita atenção aos detalhes na sua frente. Você não vai deixar passar porque está curioso. Isto não estava em seu plano que algo inesperado/estranho vai acontecer, você vai notar e vai investigar mais a fundo. Mas agora você está fazendo isso. Você pode deixá-lo ir. Mas você não deve deixar passar.
• Você está feliz, você descobriu a causa, os passos, e o cenário. Agora você vai comunicar isso de forma adequada e construtiva para a equipe de desenvolvimento e para os outros participantes da sua equipe. Você pode fazer isso através de alguma ferramenta de rastreamento de defeitos ou verbalmente, mas você tem que ter certeza de que está comunicando construtivamente.
• Oops! E se eu o fizer dessa forma? E se eu inserir um número inteiro adequado como entrada, mas com espaços brancos à esquerda? E se? … E se? … E se? Não acaba facilmente, não deve acabar facilmente. Você vai imaginar muitas situações & cenários e na verdade você será tentado a realizá-los também.

O diagrama abaixo representa a Vida de um Testador:

Leia os quatro pontos mencionados acima mais uma vez. Vocês notaram que eu mantive muito curto, mas ainda assim realcei a parte mais rica de ser um testador manual? E você notou o realce ousado em algumas palavras? Essas são precisamente as qualidades mais importantes 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 quente de hoje – será que alguma vez pode ser substituída por automação?

No SDLC com qualquer metodologia de desenvolvimento, poucas coisas permanecem sempre constantes. Como testador, você irá consumir os requisitos, convertendo-os em Cenários de teste / casos de teste. Você então irá executar esses casos de teste ou automatizá-los diretamente (eu sei que algumas empresas fazem isso).

Quando você automatiza, seu foco é constante, o que é automatizar os passos escritos.

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

Aqui, você não só foca na execução dos casos de teste escritos, mas também executa um monte de testes exploratórios enquanto faz isso. 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 dos casos de teste é simplificada:

Eu estou preenchendo um formulário, e já terminei de preencher o primeiro campo. Eu sou preguiçoso demais para ir para o mouse para mudar o foco para o próximo campo. Eu carrego na tecla ‘tab’. Estou pronto para preencher o próximo e último campo também, agora eu preciso clicar no botão Submit, o foco ainda está no último campo.

Oops, carreguei acidentalmente na tecla ‘Enter’. Deixe-me verificar o que aconteceu. OU há um botão submeter, eu vou clicar duas vezes nele. Não estou satisfeito. Clico nele várias vezes, muito rápido.

Viu? Há tantas ações possíveis do usuário, tanto intencionais quanto não intencionais.

Você não conseguirá escrever todos os casos de teste que cobrem sua aplicação sob teste 100%. Isto tem que acontecer de forma exploratória.

Você continuará adicionando seus novos casos de teste enquanto você testa a aplicação. Estes serão casos de teste para bugs que você encontrou e para os quais não havia nenhum caso de teste escrito anteriormente. Ou, enquanto você está testando, algo desencadeou seu processo de pensamento e você tem mais alguns casos de teste que você vai gostar de adicionar ao seu conjunto de casos de teste e executar.

Even depois de tudo isso, não há nenhuma garantia de que não há bugs escondidos. Software com zero bugs é um Mito. Você só pode ter como alvo levá-lo para perto de Zero, mas isso não pode acontecer sem que uma mente humana tenha continuamente como alvo o mesmo, semelhante mas não limitado ao processo de exemplo que vimos acima.

No mínimo a partir de 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 depois execute ações intencionadas e não intencionais. Mesmo que tal coisa aconteça, de quem será a mente, os pensamentos e os olhos que ela imitará? A sua ou a minha? Nós, humanos, também não somos o mesmo direito. Todos nós somos diferentes. Então?

Need for Manual Testing when Automation is Around:

Automation Testing tem a sua própria quota de glória nestes dias e terá ainda mais nos próximos anos mas, simplesmente não pode substituir o teste manual de QA (leia-se teste humano/exploratório).

Você deve ter ouvido antes – ‘You don’t automaate testing, you automaate checking’. Esta frase fala muito sobre onde o teste de GQ manual está com o teste de automação. Muitos grandes nomes em todo o mundo escreveram e falaram sobre este tópico, então eu não vou enfatizar muito sobre isso.

Automação não pode substituir os testes em humanos porque:

• Requere os julgamentos de tempo de execução sobre tudo que acontece na frente dos seus olhos (enquanto você testa) e em poucos casos nos bastidores também.
• Requer observação clara e constante.
• Requer questionamento.
• Requer uma investigação.
• Requer raciocínio.
• Requer acções não planeadas conforme necessário durante o teste.

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

Então, em resumo, os testes em humanos não podem ser substituídos. Talvez algum filme de ficção científica de Hollywood em alguns anos pareça próximo a ele, mas na vida real, eu não posso vê-lo chegando por algumas centenas de anos, que eu posso imaginar. Não o escreverei para sempre pois acredito em infinitas possibilidades.

Em uma nota separada, mesmo que isso realmente aconteça após 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ços de Testes Manuais

Como a Automação Elogia os Testes Manuais?

Eu disse antes e estou dizendo novamente que a Automação não pode mais ser ignorada. No mundo onde a integração contínua, a entrega contínua e a implantação contínua estão se tornando coisas obrigatórias, os testes contínuos não podem ficar ociosos. Temos que descobrir maneiras de fazer isso.

A maior parte do tempo, a implantação de mais e mais força de trabalho não ajuda a longo prazo para esta tarefa. Portanto, o Testador (Test Lead/Arquitect/Manager) tem que decidir com cautela sobre o que automatizar e o que ainda deve ser feito manualmente.

Está se tornando extremamente importante ter testes/controles muito precisos escritos para que eles 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’.

Nota: A palavra contínuo 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 mais e mais frequentemente, mais rápido do que ontem. Enquanto que no significado, pode muito bem significar cada segundo ou Nano-segundo.

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

Utilizei propositadamente o termo critério de saída de um teste acima. Os nossos fatos de automação não podem mais ser semelhantes aos tradicionais. Temos que ter certeza que se falharem, devem falhar rapidamente. E para fazê-los falhar rapidamente, os critérios de saída também devem ser automatizados.

Exemplo:

Por exemplo, há um defeito de bloqueio onde, eu não consigo acessar o Facebook.

A funcionalidade de login então tem que ser sua primeira verificação automatizada e sua suíte de automação não deve executar a próxima verificação onde o login é um pré-requisito, como postar um status. Você sabe muito bem que está destinado a falhar. Portanto, faça-o falhar mais rapidamente, publique os resultados mais rapidamente para que o defeito possa ser resolvido mais rapidamente.

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

Selecione casos de teste que se automatizados beneficiarão consideravelmente para os testadores humanos e tem um bom retorno sobre o investimento. Para isso, existe uma regra geral que diz que você deve tentar automatizar todos os seus casos de teste de Prioridade 1 e se possível então Prioridade 2.

Automação não é fácil de implementar e é demorada, por isso é aconselhável evitar automatizar os casos de baixa prioridade pelo menos até o momento em que você terminar com os casos de alta. Selecionar o que automatizar e focar nele melhora a qualidade da aplicação quando usada e mantida continuamente.

Conclusão

Espero que até agora você já tenha entendido porque e quão mal os testes manuais/humanos são necessários para fornecer Produtos de Qualidade e como a Automação os complementa.

Conceber a importância dos Testes Manuais de GQ e saber porque é especial, é o primeiro passo para ser um excelente testador manual.

Nos nossos próximos tutoriais de testes manuais, nós cobriremos uma abordagem genérica para fazer Testes Manuais, como ele irá coexistir com Automação e muitos outros aspectos importantes também.

Eu tenho certeza que você irá ganhar imenso conhecimento de Testes de Software uma vez que você percorrer toda a lista de tutoriais desta série.