Entenda os 7 princípios do Teste de Software que todo engenheiro de software deve saber

e quais os sete princípios do teste de software quer entender e descobrir quais são eles fica comigo até o final mas antes não se esquece de se inscrever no canal e já deixar o seu joinha porque assim você não perde nenhuma das atualizações e também me ajudou a levar as informação a mais pessoas vamos lá lá meus queridos sejam muito bem vindos eu sou o vinícius pessoal em e hoje a gente vai falar sobre os sete princípios o teste de software e se sete princípios você encontra lá no syllabus ctfl né que é a certificação

de teste mais inicial daí esta que é bem ou na bstqb então nesse syllabus ele traz os 7 princípios do teste de software você precisa saber se vocês princípios para passar na certificação e também para ser um bom profissional de teste e esse sete princípios gente não foram inventados pela o pessoal da cpfl pelo pessoal da best que é esta que b esse sete princípios existem há muitos anos então teste só o presente desde mil novecentos e setenta e esses princípios foram a criados né foram sendo desenvolvidas através dos anos então o pessoal da besta

que vem esta que junto e esses sete princípios e são coisas que a gente precisa saber para ser bom na área de teste então como um bom profissional de teste você precisa saber esse sete princípios tá bom então quais são eles o primeiro deles gente é o teste mostra a presença de defeitos mas não ausência deles esse princípio é muito muito muito importante porque geralmente o pessoal pensa nossa eu vou testar essa aplicação então se eu não achar essa aplicação se eu não achar nenhum defeito nessa aplicação quer dizer que é muito muito boa quer

dizer que ela não tem defeito a gente não pode afirmar isso então por que que a afirmar isso porque testar todas as as combinações de entrada né as combinações de saída do teste do do software é impossível porque podem ter infinitas a possibilidade de entrada e infinitas possibilidades de saída então é essa dificuldade de se testar todos os caminhos possíveis a gente costuma dizer que testar a todos os caminhos possíveis é impossível só é possível para as falta de domínio muito específico muito pequeno então só fez muito pequenininhos q fazem coisas muito específicas aí sim

a gente consegue está em provar matematicamente que esse nosso software funciona mas brasoftware de propósito geral que é o que a gente usa por exemplo os apps do nosso celular os programas o nosso computador o sistema web os sites né pra esse tipo de sofre a gente não consegue fazer os testes exaustivos que significa testar todas as entradas possíveis e todas as saídas é nesse programa então é impossibilidade de fazer testes exaustivos é o segundo princípio então o primeiro princípio é o teste mostra a ausência de defeitos mas nunca falta deles então se você não

encontrar um defeito não quer dizer que sou só pra não tinha defeito quer dizer que você apenas algum defeito até estranho falar isso né poxa a pessoa eu achava que a gente estava para mostrar que não sofre não teve efeito né então é isso primeiro princípio o que leva ao segundo princípio o teste exaustivo então se a gente não consegue testar todas as possibilidades de entrada e todas as possibilidades de saída o segundo o princípio nos diz que o teste exaustivo é impossível tá o terceiro princípio é o teste inicial economiza tempo e dinheiro né

como assim teste inicial pressione a gente chama isso aqui fora vestir lá que é um termo mais a resistente mais significa trazer para as fases mais iniciais do nosso o desenvolvimento de software o teste então o teste tem que estar envolvido desde as fases mais iniciais do processo de desenvolvimento do software se você nunca viu eu tenho um vídeo né que eu explico o que que o teste faz então explica que a gente faz em cada uma das fases do desenvolvimento do software vou deixar o card zinho aqui para vocês então clique olhar assistir esse

vídeo para ver meu colega a gente trabalha né esse tempo de titular é um termo mais atual mas significa isso significa que quanto mais cedo a gente atua né no desenvolvimento do software como tércio então perto aí tem que estar envolvido desde as fases mais iniciais tem que é isso persona é a fase de requisitos é a fase de projeto é a fase de desenvolvimento o teste em si mas está envolvido em todas as camadas e quanto mais cedo a gente está envolvido mais barato se torna corrigir um defeito né então tudo mais cedo a

gente pega o não desenvolvimento mais barato ele é para corrigir então se você tá lá a passou uma função por todas as fases desse nosso desenvolvimento do software colocou esse software em produção né tá lá o seu usuário tá usando lá tentando cadastrar o cliente lá tentando faturar uma venda né tava tentando enviar um e-mail e aí ele pega aquele defeito o custo de correção nesse perfeito é muito maior mas por que isso pessoal por quê que é maior porque pensa né até você o cliente pensou na função é sônia quero colocar no meu novo

software que você tá vendendo para mim que a minha tela pisque quando a venda foi recusada porque assim o cliente sabe que aquela venda foi recusada então o cliente está lá explicando para você o que ele quer daquele sofre essa fase de elicitação de requisitos na fase de pegar aqui isso então isso está envolvido analista de requisitos está envolvido o hauner está envolvido algumas pessoas e aí o cliente gastou até eu vou para você aquela função e aí você gastou um tempão tentar entender o que que ele precisa fazer né porque ele quer realmente e

aí começou a desenvolver aquela aquela função estou aquela função encontrou um monte de feito atualizou o código então gastar um tempo lá na sprint às vezes por semana às vezes mais então vários funcionários várias pessoas precisarão estar envolvidas para desenvolver essa função desde a cabeça do cliente até de faço na produção então gastou-se um tempo gastou-se um esforço gastou-se muito tempo e esforço de vários profissionais para pegar essa função da cabeça da pessoa de colocar até em produção então isso demorou um tempo e vão gastar enorme se a gente consegue pegar um defeito lá na

ele está são os requisitos por exemplo quando um cliente tá explicando para você e se o teste tá participando tava fazendo entre amigos né com aquela técnica que a gente participou junto com piolho controlador tô com sede em a pegar aquele efeito já no início como sem pessoa real é preciso mais inscrito vai dizendo que não direito que deve ser feito né então isso são exemplos de coisas que podem ser feitas antes da gente desenvolver de fato alguma coisa né então pegaram defeito mais nas fases iniciais é mais barato do que mais nas fases finais

então a gente consegui a estar envolvido o mais cedo possível torna esse a correção mais barato então esse é o terceiro o princípio né no teste o quarto dele sente é o agrupamento de defeitos ou a vizinhança dos defeitos ou quer dizer que onde a gente encontra um defeito existe uma grande probabilidade da gente encontrar outros defeitos também né de forma genérica de forma geral existe uma regra que a gente chama o princípio da gente chama de princípio 8020 o princípio de pareto e essa e essa pra o disk algo a se organiza em 80/20

né oitenta por cento dos seus defeitos e está em vinte por cento dos seus da sozinho de código por exemplo aqui no teste mas existem essa mesma manifestação desse princípio em outros lugares do mundo né em outras formas também em outros a ambientes mas para o teste é isso significa se você tá lá testando alguma coisa encontrou um defeito então tem grandes chances de encontrar ou defeitos também a perto daquele defeito que você encontrou então a gente chama isso de agrupamento de defeitos ou vizinhança dos defeitos e esse é o nosso quarto princípio do teste

o quinto deles gente eu tenho um vídeo específico falando para do alto de pesticida vou deixar aqui também um cadinho para vocês caso vocês queiram assistir mais o paradoxo do pesticida tem muito a ver com o primeiro princípio tem muito a ver com se você não encontrou um defeito não quer dizer que não tem defeito mais o paradoxo pesticida diz especificamente sou se você executar o mesmo conjunto de testes de novo de novo de novo né a guerra na guerra na guerra a ie9 encontrar mais efeitos a partir de um tempo isso vem lá mesmo

da biologia na parte de controle de pragas e que se você aplica sempre o mesmo agrotóxico a partir de um tempo as suas praguinhas lara não suas lágrimas traguinho das plantas passam a ser resistentes à ela não morre mais então a gente emprestou esse essa definição lá das partes orgânicas biológicas né para dizer que se a gente tem o mesmo conjunto de testes executa eles sempre a partir do terminal de tempo você não vai encontrar mais novos efeitos aí pessoalmente coisa estranha então veja automatiza teste junto mais o teste mas também tem que evoluir os

testes e sempre da manutenção e sempre eu criar testes novos né a gente conseguir ter um cobertura maior e terá que pegar os defeitos então esse é o nosso quinto princípio os a princípio gente é o teste depende do contexto então para quem a conhece janeiro sofre já leu o novo silver bullet né quer dizer que uma solução não resolve todos os problemas e todos os lugares que estão registradas também essa mesma ideia aqui para o teste o teste de software depende do contexto que que isso quer dizer pessoal isso quer dizer que testes que

eu faço para um sistema bancário são diferentes de teste que eu faço para um joguinho celular que são diferentes de teste que eu preciso fazer para aviônica por exemplo né das próprias embarcados que rodam o avião para softwares que rodam em carro sofre os críticos de aplicativos médicos né de máquinas médicas então são diferentes cada lugar que você vai realizar os seus testes vai ter funcionalidade frente vai ter forma diferente fazer técnica diferente de fazer e não existe uma coisa que funciona sempre para toda essas contextos tá e o 71 dos nossos princípios que é

ausência de erros é uma solução então eu tô falando isso através todos esses princípios né só em um pouco sobre aqui no não tem sítio do paradoxo foi um pouco sobre o primeiro dos princípios mas o sétimo deles é a ilusão da ausência de defeitos se você não encontra defeito no seu código muito provavelmente seus testes não tão bom suficiente sair personne credo mas que sacanagem meus pés estão bons estavão assim comigo é gente se você não tá prestando um só perante um aplicabilidade muito específica que é um sofre formal que a tematicamente provado como

eu disse para vocês esses offer vai ter efeitos você não é perfeito um software muito provavelmente você precisa voltar lá não sei os testes offer né lá no seus casos de testes você não sabe um caso de teste tem um card tempo e também para falar sobre isso lá no seus casos de teste revisar os seus testes viveu que que tá faltando né para você ir é a ao que deixou de ser coberto né o as falhas esse seu software tá bom então esses são sete princípios o teste software muito obrigado por estar comigo hoje

não esquece de curtir esse vídeo deixar esse foi algum comentário se ficou alguma dúvida nos comentários então pergunta aí pessoal eu sempre responde aí sabe que eu respondo compartilha com amigo manda no grupo do whatsapp para quem quiser aprender isso também aqueles amigos quer estudar para ctrl também um abraço para vocês muito obrigado até a próxima tchau tchau