Sou estudante do meu BE (CS) e minha pergunta é a seguinte:

1. É necessário testar no campo de software?
2. Se criamos um software com muito cuidado, por que devemos testar?
3. Após o teste, podemos ter certeza de que alcançamos esse objetivo (o produto / software funciona conforme o esperado) porque o testamos ? É possível?

Minha pergunta: É necessário testar o software ?

Sim. Porque não importa o quão bom você seja, você não consegue pensar em tudo.

• Você também será solicitado a fazer com que seu software faça coisas que você nunca pretendeu.
• Você também nunca terá requisitos tão claros que poderá pensar em todas as possibilidades para garantir que o código não seja quebrado.
• Você também trabalhará com o software e as APIs de outras pessoas que nem sempre funcionarão como planejado, mas presumirá que isso funcione ou deva levar a defeitos no seu caso "perfeito".

sim

Pela mesma razão que um chef prova sua comida enquanto cozinha.

Eu trabalho com alguém que pensa assim, ele pensa que, por ser um programador sênior, não precisa mais testar seu código. A empresa não entende o quão perigosa é essa atitude e, em vez de demiti-lo, eles contrataram mais programadores para lidar com a lista de pendências de bugs. Sem saber de onde vem esse atraso, eles acham que faz parte do que é a programação. Basicamente, temos 3 programadores que trabalham nesse modo e uma equipe de 20 pessoas que nada mais faz do que testar e corrigir os erros que esses três criam.

AUSÊNCIA DE ADEQUADO TESTE MATA .

Então, a menos que você seja DEUS ou qualquer versão de algum ser que tudo saiba (agora é isso que eu gostaria de ver) ou a menos que você queira ativamente ser demitido muito rápido, sugiro fortemente que você comece a testar.

O software é escrito por pessoas.

As pessoas são imperfeitas e cometem erros.

À medida que a complexidade de uma empresa aumenta, aumenta o número potencial (e o impacto) de erros, omissões ou coisas esquecidas - geralmente exponencialmente.

Então, sim, é necessário testar. Traz equilíbrio e perspectiva.

Você embarcará em um voo que executa um sistema operacional que você sabe que usou no seu laptop e lhe deu uma tela da morte na sua cor favorita? Pense nisso.

Nenhum codificador é perfeito. Muito, muito, muito longe disso realmente. Você precisa testar, e os testadores geralmente trazem uma perspectiva (também conhecida como casos de uso) que os desenvolvedores estavam ausentes.

Faça uma pesquisa nos bugs de software mais famosos do Google para saber o que quero dizer.

E no nível da faculdade, leia sobre desenvolvimento orientado a testes, testes de unidade e práticas ágeis para saber onde estão as coisas no momento.

O teste é uma necessidade absoluta para qualquer aplicativo não trivial (em tamanho ou função) que deve ser realmente usado. Você não encontrará um único desenvolvedor que se preocupe com seu ofício (como evidenciado pela visita a este site) que responderá e dirá que o teste não é necessário.

Além do que já foi publicado, ter um conjunto completo de testes de unidade automatizados em qualquer aplicativo dará a você mais confiança em futuras alterações de código. Essa confiança mais alta (como os testes de unidade fornecem uma grande rede de segurança) resultará em alterações mais rápidas do código nos aplicativos existentes (devido a menos retorno / verificação dupla)

Errare humanum est

Não existe software livre de erros.

O desenvolvedor mais habilidoso escreve código com bugs. Mesmo se um desenvolvedor perfeito existisse, ainda haveria erros devido a discrepâncias entre:

• documentos de necessidades e especificações do usuário
• especificação e design
• ambientes reais e esperados de hardware e software
• ontem e hoje verdade: tudo listado acima está sujeito a alterações que não são perfeitamente relatadas em todas as etapas do processo de desenvolvimento.

O desenvolvedor perfeito é apenas uma parte de tudo. E desenvolvedores perfeitos não existem.

A maioria dos programas da vida real:

a) contém centenas de linhas de código ou mais, espalhadas por vários arquivos;
b) são desenvolvidos por mais de um programador;
c) usado em ambientes diferentes do ambiente do desenvolvedor

Portanto, se você não verificar como o programa funciona na situação da vida real, a chance de que ele não funcione seria de quase 100%.

Além de todas as outras ótimas respostas, mesmo que você saiba que é perfeito e sem erros, pense nos outros programadores que precisam lidar com seu código no futuro. Eles não saberão como você e confiarão nos seus testes para garantir que não quebraram nada depois de fazer uma alteração. Isso também se aplica a você mesmo depois de não ter visto seu código há um ano!

SIM.

Aqui está outra perspectiva um pouco mais sutil que ainda não foi totalmente abordada:

Nunca subestime a necessidade de "verificação independente" . É a mesma razão pela qual é bom ter alguns editores independentes revisando seu trabalho antes de enviar uma grande parte da redação para publicação. Não importa quão bom você seja um escritor, você ocasionalmente fará um peido cerebral - e escreverá algo como "no" no lugar de "it", ou algo assim. Se você reler você mesmo, mesmo com bastante cuidado, ainda assim sentirá falta, porque seu cérebro aceita automaticamente o fluxo do processo de pensamento como correto e encobre o erro. Para um novo conjunto de olhos, esse tipo de erro geralmente é bastante evidente.

Você obtém a mesma coisa na programação: é muito fácil entrar em um fluxo em que o seu código ou o seu "teste de desenvolvimento" básico do seu próprio código - parece correto, porque você está testando e usando uma determinada maneira. Mas então, quando outro par de mãos aparece e clica nas coisas de uma maneira ou ordem ligeiramente diferente, tudo desaba.

Agora, é claro, você poderia, em teoria, seguir o caminho de verificar formalmente todas as possibilidades e ramificações lógicas do seu código, mas para softwares não triviais, isso será muito mais caro e demorado do que fazer com que alguém se intrometa. código para você. E você provavelmente ainda sentirá falta de coisas nas quais nunca pensou.

O que ainda não foi tocado: mesmo que seu código seja perfeito, você ainda não está seguro. Os compiladores têm bugs que podem fazer com que o código perfeito se comporte incorretamente após a compilação. Os sistemas operacionais possuem bugs que podem fazer com que um binário perfeito se comporte incorretamente ao executar. O hardware possui bugs que podem causar problemas.

É também por isso que testar em uma máquina não é suficiente para produtos comerciais. Eles precisam ser testados com o maior número possível de combinações de hardware e software que puderem encontrar na natureza.

O líder da equipe que escreveu o software para o ônibus espacial voou antes de cada lançamento para assinar que o software não prejudicaria o ônibus espacial.

O que você acha que lhe deu confiança para fazer isso?

Você está constantemente testando o código apenas compilando e usando-o. Em alguns IDE, você recebe verificações de sanidade enquanto digita. A menos que você nunca execute seu código, você está realizando testes.

O quanto você testa é realmente a raiz desse tipo de pergunta e a resposta a ela se resume a risco. Você testa o quanto faz sentido do ponto de vista do gerenciamento de riscos. Testar tudo ou nada é geralmente impossível. Testar quase nada é geralmente uma má jogada. Tudo no meio é um jogo justo, dependendo do nível de risco e da exposição do seu produto final.

Cheira como uma pergunta de lição de casa.

É necessário testar no campo de software?

Sim. Absolutamente. Em todos os níveis. Fora de alguns domínios especializados, ainda não estamos em um estágio em que possamos provar matematicamente que nosso código está correto em relação a erros específicos (pelo menos não em um período de tempo razoável); portanto, precisamos atirar pedras nele para ver se e onde quebra.

Se criamos um software com muito cuidado, por que devemos testar?

Testar não é apenas encontrar erros de codificação. É também garantir que você atendeu a todos os seus requisitos e que o sistema geral funcione conforme o esperado. Se eu tiver um requisito de que uma transação com falha retorne um código de erro específico, preciso escrever um teste para verificar se a funcionalidade existe e se funciona corretamente.

E tudo isso pressupõe que a especificação e o design sejam completos, corretos e consistentes internamente, o que geralmente não é o caso. Mesmo que você atenda às especificações conforme a letra e siga o design até o último ponto e ponto e vírgula, se a especificação ou o design estiver ruim, haverá problemas no momento da integração. Freqüentemente, o teste do sistema ou da integração ocorre quando você descobre que a especificação em si é defeituosa e precisa ser revisada (veja a história de guerra abaixo).

Após o teste, podemos ter certeza de que atingimos esse objetivo (o produto / software funciona conforme o esperado) porque o testamos? É possível?

Não, não para 100%. Não podemos testar todas as combinações concebíveis de entradas ou caminhos de execução, a não ser no código mais simples. Não podemos responder por todos os fatores ambientais. Não podemos imaginar todos os modos de falha possíveis.

Podemos testar a um ponto onde nós estamos razoavelmente certo de que não existem quaisquer grandes problemas. Novamente, é por isso que precisamos testar em todos os níveis. Escreva um conjunto de testes para garantir que seu código lide adequadamente com as condições de borda (entrada incorreta, resultados inesperados, exceções etc.). Teste de unidade para verificar se seu código atende aos requisitos. Teste do sistema para verificar o processamento de ponta a ponta. Teste de integração para verificar se todos os componentes se comunicam corretamente. Faça testes de usabilidade para garantir que tudo funcione de maneira que os clientes não queiram atirar em você.

Cenário do mundo real - Eu estava trabalhando em um sistema de back-end que ocasionalmente enviava atualizações para um serviço de GUI para exibição em uma tabela na tela. Durante o projeto, foi adicionado um requisito para adicionar filtragem à exibição (por exemplo, o operador pode escolher exibir um subconjunto das entradas na tabela). Erro de design # 1 - a filtragem deveria ter sido feita pelo serviço da GUI (eu tenho essa noção antiquária de que as funções de gerenciamento de exibição devem ser de responsabilidade do software de gerenciamento de exibição), mas devido à política e à minha incapacidade de reconhecer problemas antes que eles se tornem problemas , esse requisito foi colocado no serviço de back-end. Bem, tudo bem, não há problema, eu posso fazer isso. Filtre as alterações de estado, recebo uma mensagem e, em seguida, envio uma mensagem de criação ou exclusão paracada linha da tabela, porque é assim que a interface funciona (erro de design nº 2 - não há como enviar atualizações para várias linhas em uma única mensagem; não conseguimos enviar uma única mensagem "limpar" ou "excluir" para limpar a tabela inteira).

Bem, tudo funciona bem durante o desenvolvimento; os testes de unidade, sistema e integração mostram que eu envio as informações corretas e manejo as alterações de filtro corretamente. Em seguida, chegamos aos testes de usabilidade, e tudo fica mais difícil , porque o volume de dados era esmagador. A latência da rede entre o meu serviço de back-end e a GUI estava na ordem de 0,15 a 0,25 segundos. Nada mal se você precisar enviar atualizações para uma dúzia de linhas ou mais. Mortal quando você precisa enviar atualizações para várias centenas. Começamos a receber relatórios de erros de que a GUI estava congelando após alterar o estado do filtro; bem, não, o que estava acontecendo era que estava levando na ordem de vários minutos para atualizar a exibição porque o protocolo de mensagem de atualização de uma linha de cada vez não suporta um cenário do mundo real.

Observe que tudo isso poderia ter sido e deveria ter sido antecipado por todos, desde o contratante principal até a minha antiguidade, se tivéssemos nos dado o trabalho de fazer a análise mais básica antes. A única defesa que vou oferecer é que estávamos encerrando o segundo ano de um projeto de seis meses que seria descartado quase imediatamente após a entrega, e estávamos todos desesperados para ver o que estava por trás.

O que nos leva à razão final para testar - CYA. Projetos do mundo real falham por uma variedade de razões, muitas delas políticas, e nem todos agem de boa fé quando as coisas dão errado. Os dedos são pontudos, as acusações são feitas e, no final do dia, você precisa apontar para um registro que mostre que pelo menos as suas coisas funcionaram como deveria.

Os testes sempre serão feitos e os erros sempre serão encontrados. É apenas que o teste será realizado internamente pela sua equipe ou o usuário final será o testador. O custo de um bug encontrado pelo usuário final é tremendamente mais alto do que se tivesse sido encontrado durante o teste.

Eu sugeriria fazer um bom curso de computação tolerante a falhas. O design cuidadoso do software é apenas um dos pilares para obter robustez no seu produto de software. Os outros dois pilares são testes suficientes e design redundante. A intenção básica é acomodar um número exponencial de condições de falha desconhecidas e priorizar o tratamento com alguns dos conhecidos:

1.) elimine o maior número possível de falhas através do design e implementação adequada 2.) elimine falhas imprevistas da fase de design e implementação incorreta através de várias formas de teste (unidade, integração, aleatória) 3.) lide com as falhas restantes por redundância ( temporal => recompute, tente novamente ou espacial => mantenha cópias, paridade)

Se você eliminar a fase de teste, ficará com apenas as fases de design e redundância para solucionar falhas.

Além disso, do ponto de vista do produto, suas partes interessadas (por exemplo, gerência, usuários, investidores) desejam algum tipo de garantia de que seu produto atende a determinadas especificações, critérios de qualidade e segurança, etc. Além de tudo isso, você não testou o software que você construiu apenas para ter um 'teste de sanidade'? Todos esses motivos tornam os testes de software mais atraentes.

Todos os programas têm erros, pelo menos para começar.

Houve alguns estudos que convergem em cerca de 1 bug a cada cinco linhas de código não testado.

Uma lição de história:

Na década de 1960, a IBM precisava de um programa "NOP" para poder executar alguma funcionalidade na JCL sem realmente executar um programa. Os desenvolvedores criaram um programa assembler de uma linha no qual todo o código estava contido em seu nome "IEFBR14", sendo o código real:

       BR 14 * brach to return address in register 14

Durante seu longo período de espera, este programa de uma linha foi sujeito a 2 relatórios de bugs e cinco alterações.

A refatoração de código é muito mais rápida quando você faz testes de unidade. Um teste de unidade também mostra o uso simples da função concreta, para que você tenha um pequeno "howto" que pode ser realmente útil em grandes projetos nos quais os programadores não conhecem exatamente todo o código.

Quando você está desenvolvendo com TDD (desenvolvimento orientado a teste), você não tem getter / setters desnecessários etc. Você apenas cria o que precisa.

Para responder à terceira pergunta:

Sendo programador e testador de software, sim, você pode ter certeza de que está cumprindo os requisitos do software durante o teste.

{colocando o controle de qualidade}

Quão? Você pode fazer isso rastreando seus testes do código de teste aos critérios de aceitação, critérios de aceitação para recursos e recursos para requisitos. Se você rastrear todos os testes da cadeia de design e eles mapearem para um ou mais requisitos, pode ter certeza de que seus testes estão sendo usados ​​para garantir que o código atenda aos requisitos (embora isso traga a noção de cobertura de teste adequada, que é uma outro assunto). Se você não pode rastrear um teste na cadeia de design, provavelmente está testando coisas que não são necessárias, e isso é uma perda de tempo. Os critérios de aceitação também podem incluir a verificação de comportamentos indesejados - você também pode testá-los, o que o aproxima um passo da liberação de qualidade.

{Controle de qualidade}

Nenhum código é livre de bugs, apenas menos dispendioso ao longo do tempo, quando mais esforço é gasto na avaliação de sua qualidade durante o desenvolvimento.

Sou testador de software há 3 anos. Inicialmente, eu próprio era cético em relação à necessidade de testar, pois pensei que se o departamento de desenvolvimento e o gerenciamento de projetos fizessem seu trabalho, nenhum erro de software deveria ocorrer.

MAS este não é o caso. ++++++++

Erros acontecem frequentemente, alguns deles críticos para a operação de um projeto. Também há testes entre navegadores (que significam testes em diferentes navegadores existentes, como SAFARI, FIREFOX, CHROME e Internet Explorer) e trabalhei no projeto em que botões simples da interface, como SIM e NÃO, em uma janela de pesquisa em que não funcionam apenas em todos os navegadores alguns deles.

Eu trabalhei no teste de páginas da internet, e estava testando simples TEXT CHANGES e pensei comigo mesmo que de maneira alguma poderia haver defeitos nesse trabalho simples, mas não acontece.

Também vi quando novos desenvolvedores ingressam na equipe e recebem uma atualização de um formulário de aplicativo de Internet complexo existente com várias ligações / chamadas para páginas externas. Ocorreu um erro devido à falta de comunicação entre antigos e novos desenvolvedores, por várias razões (sem tempo para educar, sem vontade de educar e assim por diante).

SIM

Imagine que seu software é apenas uma função lógica AND (b1, b2) onde b1 e b2 são apenas bits. Com isso, você precisa de 4 casos de teste para garantir que seu software esteja livre de erros, se o ambiente ao redor fornecer exatamente o que eles foram especificados.

Agora, seu sistema é composto por muitas funções cuja mais simples é muito mais complicada do que essa função lógica. Como você se certifica de que está livre de erros?

(continua)