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.