ti-enxame.com

O teste de software é realmente feito em projetos profissionais?

Já estive envolvido com muitos projetos em várias empresas, pois já sou desenvolvedor há muito tempo e sou empreiteiro.

Eu estimo que menos de 20% dos projetos são testados metodicamente. Com testado metodicamente, quero dizer qualquer teste além do teste ad-hoc sem plano.

Eu também estimo que menos de 10% dos projetos são completamente testados metodicamente onde eles têm testadores dedicados como parte da equipe, documento de plano de teste, onde os desenvolvedores escrevem testes automatizados e então eles também rastreiam a cobertura do teste e medem resultados.

Duas questões

  1. Quais são suas estimativas de porcentagem sobre este problema?
  2. Qual é a sua experiência profissional em testes de software?

Nota adicional

Uma vez que a questão do teste metódico pode obter respostas bastante tendenciosas (as pessoas gostam de se gabar de ser superior aos outros) eu incentive outros desenvolvedores (aqueles que não estão expostos a testes metódicos) para fornecer suas respostas também, porque caso contrário, parecerá que o teste está sendo feito em todos os lugares ... exceto em sua empresa.

27
Robert Koritnik

O padrão que vi com testes ao longo de minha carreira mostra uma forte correspondência com o risco de fracasso em um projeto. É mais provável que grandes projetos sejam testados do que pequenos, aplicativos de missão crítica são mais prováveis ​​de serem testados do que um fora de sites de marketing, sistemas internos são menos prováveis ​​de serem testados do que aqueles voltados ao público.

Dito isso, ainda existem projetos que foram testados excessivamente e aqueles que não foram testados o suficiente, mas estes são minoria.

11
Martin Brown

Tudo o que produzimos é totalmente testado. Se nossa equipe interna de QA estiver sobrecarregada, temos uma equipe offshore que testa os projetos. Eles não são tão bons quanto nossa equipe interna, mas esse é um tópico diferente.

6
Ali

Sim.

A quantidade de testes é proporcional à confiabilidade exigida do aplicativo, bem como à maturidade da cultura do programador.

Os sites estão freqüentemente caminhando em buracos de bugs (links quebrados são um defeito).

Os videogames costumam apresentar erros.

O Windows (finalmente) é bastante confiável.

Os roteadores são muito confiáveis

Monitores de hospital "não quebram"

Observe que o custo fiscal do fracasso também está relacionado à confiabilidade.

4
Paul Nathan

Em 10 anos, nunca trabalhei em um projeto com teste formal de código.

Em meu trabalho atual, temos apenas testes funcionais.

O problema é que ninguém na gerência está ciente dos testes de código. O departamento de testes nem sabe sobre o código de teste - em alto nível, eles apenas seguem as especificações de alto nível e verificam se as cumprimos, do ponto de vista comportamental/funcional.

Não temos um líder de software qualificado que nos obriga a codificar bem. O resultado é um código espaguete, muitas regressões, cronogramas perdidos e assim por diante ...

4
Wizard79

Minha amostra é muito pequena para deduzir porcentagens, mas aqui vai de qualquer maneira.

Uma era uma empresa sem fábrica de chips + firmware, que fazia testes fanáticos. Testes automatizados 24 horas por dia, 7 dias por semana em dezenas de instalações, cada uma testando dezenas de unidades em paralelo. Equipes de software dedicadas ao desenvolvimento de software de teste. Equipes de hardware dedicadas à construção de plataformas de teste. Teste de compatibilidade contra dezenas de concorrentes. Caramba, eles até compraram uma instalação de testador de chips multimilionária para desenvolver e depurar alguns dos testes que as fábricas executam quando os chips saem da fundição.

Outro era um banco. Este é um ambiente completamente diferente: nenhum lançamento de produto, mas muitos e muitos softwares internos para continuar funcionando continuamente. Esses caras testaram o cr * p de cada alteração que fizeram. Eles tinham uma separação muito estrita de ambientes DEV/QA/PROD, teste de regressão automatizado, teste de QA obrigatório assinado pelos usuários finais antes de lançar em produção, etc.

Então, sim, as pessoas fazem testes metódicos. Mas como você pode ver, nunca trabalhei em um lugar que enviasse seu software GUI típico para o usuário de computador típico.

3
Roman Starkov

Atualmente, escrevo firmware embarcado para uma pequena empresa iniciante que fabrica dispositivos médicos sem fio. Somos obrigados a fazer testes rigorosos e ter um departamento de qualidade completamente separado chefiado por alguém que se reporta diretamente ao CEO. Eu nunca tive meu código testado tão completamente antes por testadores separados (a única vez que se compara, é quando eu estava trabalhando em sistemas de TV por satélite, há cerca de 15 anos.)

Nossos resultados de teste são enviados ao FDA (até agora, obtivemos duas autorizações do FDA - cada envio tinha cerca de 500 páginas). Ambas as nossas metodologias de desenvolvimento e teste estão sujeitas a auditorias periódicas.

Portanto, não são apenas as grandes empresas que fazem muitos testes formais.

Observação - em meus mais de 25 anos de programação/consultoria de contrato, também trabalhei para muitas empresas que praticamente não fizeram nenhum teste formal. A maioria deles não está mais por perto.

3
tcrosley

As três empresas para as quais trabalhei nos últimos 15 anos, todas tinham testes de unidade executados automaticamente.

Em duas dessas empresas, pressionei para apresentá-los.

3
sbi

Nos últimos 9 anos, basicamente só cumpri os testes de aceitação/regressão. Houve apenas alguns testes de unidade.

3
LennyProgrammers

Somos uma empresa offshore de médio porte no sul da Ásia. No entanto, sempre fazemos projetos baseados nos EUA e trabalhamos diretamente com os requisitos enviados pela empresa nos EUA.

Aplicamos testes metódicos em cada aplicativo que construímos. Talvez a qualidade dos testes não esteja de acordo com o padrão, mas nós os empregamos.

2
Shamim Hafiz

Por mais que o purista em mim não queira aceitar que tem que haver algum gerenciamento de risco embutido na decisão de quão rigorosamente você testa ou se você faz testes formalizados. Para aplicativos internos, que eu suspeito que sejam uma grande% dos projetos de programação, o custo de lançar um bug e corrigi-lo rapidamente após ser percebido pode às vezes ser superado pelo custo de uma equipe de teste completa. Claro que depende do aplicativo e do custo potencial das falhas.

Dito isso, não acho que o planejamento de gerenciamento de risco seja a razão para a falta de testes formalizados. Eu acho que é mais o resultado de gerentes não técnicos não entenderem o valor que isso agrega e ver apenas o custo.

2
JohnFx

Nos últimos vinte ou mais anos de minha carreira em oito ou mais empresas, nunca trabalhei em um projeto que não fizesse testes. A quantidade de testes diferia em cada empresa, mas todos os projetos de desenvolvimento profissional em que já trabalhei realizavam testes formais. Isso se aplica igualmente a empresas de pequeno e médio porte (onde "pequeno" significa menos de 10 funcionários e "médio" significa alguns milhares de funcionários ou menos).

Algumas empresas não tinham muitos testes automatizados, algumas não tinham muitos testes manuais, mas tinham pelo menos um ou outro.

0
Bryan Oakley

Quase todas as empresas em que fiz testes metódicos. Minha empresa atual tem alguns testes básicos de estilo de unidade e isso não é suficiente. Tivemos alguns problemas de qualidade devido a isso. Eu recomendo altamente testes completos independentes em qualquer projeto que será usado por qualquer pessoa além de você. O dinheiro gasto valerá a pena. Aplicativos que não funcionam não são usados. Isso vale tanto para o rosto interno quanto para o externo.

0
Bill Leeper

Depende das necessidades do cliente. Em uma situação de contrato, provavelmente existem testes de aceitação. Em casa é geralmente um tapa com poucos testes. As coisas do consumidor são geralmente altamente cobertas por funcionalidades frequentes, mas ásperas nas bordas.

0
anon

Resposta curta: Sim

Resposta longa:

  1. Não tenho uma boa estimativa para a primeira categoria (provavelmente está um pouco distante de zero, mas quanto?), Mas minha experiência na verdade corrobora com sua segunda estimativa. É difícil fornecer porcentagens significativas, pois a quantidade e o tipo de teste dependem do tipo de aplicativo que está sendo desenvolvido e do prazo disponível, bem como do conjunto de habilidades dos desenvolvedores e de como o projeto é executado. Na prática, o obstáculo mais importante para os desenvolvedores seria o teste de aceitação, uma vez que é um marco importante para fins de cobrança. Mas também é o momento em que o inesperado pode acontecer (mais requisitos) e os desenvolvedores podem ser pressionados a entregar e sobreviver com qualquer teste ad hoc que seja possível e oportuno (nesta fase), além do tempo necessário para solucionar problemas e superar o inesperado.

  2. Já passei por uma variedade de projetos com diferentes combinações dos fatores mencionados acima:

    • sem testes de unidade formais, apenas testes de integração e, principalmente, testes ad hoc

    • muito formal, variando de testes de unidade a planos de teste detalhados envolvendo recursos de QA dedicados, testes automatizados (conduzidos pelos testadores com seu próprio conjunto de ferramentas) e relatórios de cobertura de código. Mas nem sempre são significativos para os desenvolvedores tanto quanto para os gerentes

No nível individual, procuro manter um entendimento de minhas opções quando se trata de escrever testes apropriados para a tecnologia com a qual estou lidando e exercitá-los a meu próprio critério. Basicamente as coisas que são realmente significativas e benéficas para o meu trabalho, e não tanto gerar números.

0
prusswan

Considere, por exemplo, a biblioteca CPAN que é o núcleo do software contribuído para a linguagem de programação Perl ...

Toda vez e cada vez você instala um pacote desta [vasta ...] biblioteca, um conjunto automatizado de testes fornecido pelo autor do pacote é executado sua máquina. Se algum desses testes falhar, o pacote não será instalado.

E então, há "CPANTS". https://cpants.cpanauthors.org/

CPANTS é um serviço de teste para distribuições CPAN. Um de seus objetivos é fornecer algum tipo de medida de qualidade chamada Kwalitee. Embora pareça e soe como qualidade, uma pontuação Kwalitee mais alta nem sempre significa que uma distribuição é mais útil para você. Tudo o que pode garantir é que é menos provável que você encontre problemas na instalação, no formato dos manuais, licenciamento ou talvez na portabilidade, já que a maioria das métricas CPANTS são baseadas nas questões anteriores do conjunto de ferramentas/QA que você pode ou não lembrar.

Sim ... este serviço automatizado testa constantemente novos lançamentos de pacote CPAN, em todos os tipos de plataformas de hardware e software amplamente diferentes (que o pacote supostamente suporta ...) e testa se realmente o faz.

Claro, esta não é a única biblioteca (ou linguagem) que faz isso rotineiramente.


Muito tempo atrás, percebi o valor pessoal do "desenvolvimento orientado a testes". Escreva uma classe e, em seguida, faça um teste para ela. Conforme você continua adicionando ao sistema, execute constantemente todos os testes.

"Suh-prêmio !!"

Uau ... como quebramos isso? ... bem, com certeza estou feliz por termos pegado aquele mais cedo! Teria sido muito desagradável se tivesse chegado à produção !!

Uh huh. Depois de aprender essa lição por si mesmo - mesmo quando você é o único desenvolvedor no projeto - você não a esquece.

0
Mike Robinson