CodeGym /Cursos /All lectures for PT purposes /Testes na vida de um programador

Testes na vida de um programador

All lectures for PT purposes
Nível 1, Lição 315
Disponível

Por que os programadores precisam de testes?

Os próximos níveis serão dedicados a testes da maneira que os programadores precisam . Mas primeiro, vamos descobrir o que é o teste e por que ele é necessário.

Com relação ao software, podemos dizer que a tarefa do teste é verificar se o programa:

  • faz o que ela tem que fazer
  • não faz o que não deveria fazer

O segundo ponto, aliás, não é menos importante que o primeiro, mas mais sobre isso depois.

Vamos começar com o primeiro ponto. O que significa "o programa faz o que deveria fazer"?

Primeiro, alguém precisa fazer uma lista de todos os casos de uso do programa. Em segundo lugar, eles precisam descrever como o programa deve funcionar, como o usuário deve se comportar e quais resultados são esperados. Você não pode continuar mais.

Assim que escrevemos “como o usuário deve se comportar”, toda a ideia de escrever uma boa documentação se desfez. Pessoas não são máquinas, além disso, muitas vezes as pessoas se comportam com o software como bem entendem . Ninguém começa a se familiarizar com a tecnologia estudando as instruções. É um fato.

Portanto, obtemos uma novidade: a peculiaridade do software é que ele possui muitos cenários de trabalho diferentes. Alguns deles são óbvios, outros podem ser documentados, outros podem ser presumidos, outros podem ser adivinhados e os outros 50% nem sequer ocorrerão a você.

Do ponto de vista do programador, a maioria dos bugs não são bugs. Um erro é quando um programa não funciona como deveria ou como esperado. E há muitas situações em que não está claro como o programa deve funcionar, ou cenários que se contradizem ...

Há um número infinito de cenários e sempre haverá casos no produto em que o programa não se comporta conforme o esperado (o programador escreveu o código para apenas algumas dezenas de cenários). Portanto, pode-se argumentar que sempre há bugs em qualquer programa e qualquer produto pode ser melhorado indefinidamente .

Depois disso, tudo se resume a conveniência. Primeiro, o programador corrige os bugs maiores, depois os bugs menores e assim por diante. E, por fim, chega uma fase em que o dono do produto acredita que não é economicamente viável continuar trabalhando nele.

Mas voltando aos erros que todos reconhecem como erros: o programa obviamente faz algo errado, caiu, quebrou algo, etc. Esses erros podem ser divididos condicionalmente em 3 categorias: grandes, médios e pequenos.

E muitas vezes acontece que um programador está trabalhando na correção de bugs médios ou até pequenos, embora ainda haja muitos problemas mais sérios no projeto. Ele simplesmente não os encontrou , então está trabalhando nos maiores que conhece.

Portanto, em qualquer projeto deve haver testadores. Essas pessoas aprendem especificamente a olhar para o produto de diferentes ângulos. Então você pode ver mais cenários do programa. A tarefa deles é encontrar erros e anotá-los (para não encontrar o mesmo erro várias vezes).

O teste é um processo que visa encontrar erros. Esses bugs devem ser encontrados, descritos e priorizados. Somente após a priorização dos erros é que podemos falar em um processo de melhoria de software eficaz.

Lembre-se, o primeiro passo para resolver um problema é reconhecer que existe um problema . Você não pode corrigir um erro que não conhece.

Automação de teste

Acho que todos concordamos que o teste é importante, então vamos olhar para o teste como programadores. Como os programadores veem os testes? Os programadores automatizam o trabalho de outras pessoas. A última profissão a desaparecer será a profissão de programador.

Automatizamos todos os processos que encontramos. Portanto, os testes precisam ser automatizados. E como automatizar a busca de erros? Resposta curta: não. Mas aqui novamente o fato de sermos programadores vem em nosso auxílio.

O processo de desenvolvimento de software consiste em constantes mudanças no mesmo. apenas no processo de fazer alterações constantes, os programadores muitas vezes quebram algo que funcionou bem até recentemente.

E os testadores, em vez de procurar novos erros, são obrigados a verificar constantemente se quebramos algo que funciona bem há muito tempo. O chamado teste de regressão. É esse tipo de teste que pode e deve ser automatizado.

Aqui todo o software pode ser dividido em duas partes:

  • o programa interage com a pessoa
  • programa interage com outro programa

A primeira opção é mais difícil de automatizar, requer testadores automatizados especiais, também chamados de QA Automation ou Software Test Engineer.

Mas a segunda opção pode e deve ser automatizada de forma independente. Se você tiver um software que:

  • funciona bem
  • ja testei
  • implementado como um módulo separado ou bloco lógico
  • não planeja mudar
  • outros módulos ou programas dependem dele
  • falha funcional é cara

Eu recomendo reservar um tempo para escrever testes que capturem os principais aspectos de sua funcionalidade atual. Seria razoável alocar 5% do seu tempo de trabalho para isso , ou 1 dia por mês.

Não há necessidade de escrever testes por causa dos testes.

Ninguém apoiará seus testes. Nem outros programadores, nem você mesmo. Ninguém faz isso. 99% de todos os testes escritos são abandonados e/ou desativados. Se você não pode escrever testes - não escreva. Escreva apenas se você absolutamente não puder passar sem eles.

Tipos de teste

Cada programador, se não passou por um treinamento especial, poderá dizer com suas próprias palavras o que é testar: verificar se o programa faz o que deveria. No entanto, os profissionais neste campo distinguem áreas inteiras (tipos) de testes.

Todos os testes realmente giram em torno da confiabilidade e disponibilidade do software, mas para entender melhor a direção do teste, vejamos alguns exemplos.

Digamos que você esteja testando uma loja online típica. Em seguida, as áreas de teste podem ser divididas nos seguintes tipos: teste de desempenho, teste funcional, teste de integração e teste de unidade.

Se o proprietário do site decidir lançar uma campanha publicitária séria, muitos usuários acessarão o site ao mesmo tempo. Pode ser que o site não caia, mas algumas de suas seções podem ficar lentas ou até parar de funcionar.

Para evitar que isso aconteça, você precisa identificar esses problemas com antecedência e tomar medidas para eliminá-los. Isso é feito usando o teste de carga ou também é chamado de teste de desempenho.

Você também pode querer testar como sua API de back-end funciona e testar cada função dela: registro, login, adicionar ao carrinho, processamento de pagamento, gravações de banco de dados, etc. Tudo deve funcionar de acordo com o TOR. Nesse caso, você precisa realizar testes funcionais .

Sua loja online provavelmente está integrada a serviços de terceiros: envio de cartas e SMS, sistemas de pagamento, bate-papos de suporte online, coleta de feedback de usuários, sistemas de publicidade etc. .

Finalmente, produtos complexos são frequentemente divididos em módulos independentes. A partir desses módulos, você pode montar o produto final, como de um construtor. Se você estiver desenvolvendo tal módulo ou interagindo com tais módulos, precisará fazer testes de unidade .

Resumindo, podemos dizer que o teste funcional é necessário para testar cada função individual do site. Integração - para testar a interação de grandes módulos e sistemas do seu produto. Modular - para testar um módulo separado, bem, teste de desempenho - para verificar o funcionamento do seu site sob carga.

Pode haver ainda mais tipos de testes: quanto mais complexo o produto, mais aspectos de seu desenvolvimento precisam ser controlados.

Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION