O teste de software é realmente realizado em projetos profissionais?

Estive envolvido em muitos projetos em várias empresas porque sou desenvolvedor há muito tempo e sou contratado.

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

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

Duas questões

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

Nota adicional

Como a pergunta de teste metódico pode obter respostas bastante tendenciosas (as pessoas gostam de se gabar de serem superiores às outras), incentivo outros desenvolvedores (aqueles que não estão expostos ao teste metódico) a fornecer sua resposta também, porque, caso contrário, parecerá que o teste é sendo feito em qualquer lugar ... exceto na sua empresa.

O padrão que vi ao testar minha carreira mostra uma forte correspondência com o risco de falha em um projeto. Os grandes projetos têm mais probabilidade de serem testados do que os pequenos, os aplicativos de missão crítica têm mais probabilidade de serem testados do que os sites de marketing externos; os sistemas internos têm menos probabilidade de serem testados do que os voltados para o público.

Dito isto, ainda existem projetos que foram excessivamente testados e aqueles que não foram testados o suficiente, mas esses são a minoria.

Tudo o que produzimos é completamente testado. Se nossa equipe interna de controle de qualidade estiver sobrecarregada, teremos uma equipe offshore que testará os projetos. Eles não são tão bons quanto a nossa equipe interna, mas esse é um tópico diferente.

As três empresas nas quais trabalhei nos últimos 15 anos tiveram testes de unidade que foram executados automaticamente.

Em duas dessas empresas, insisti em apresentá-las.

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

Sim.

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

Os sites geralmente andam com falhas (links quebrados são um defeito).

Os videogames costumam ser de buggy.

O Windows (finalmente) é bastante confiável.

Roteadores são muito confiáveis

Monitores de hospital "não quebram"

Observe que o custo fiscal da falha também está correlacionado à confiabilidade.

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

No meu trabalho atual, temos apenas testes funcionais.

O problema é que ninguém no gerenciamento sabe sobre o teste de código. O departamento de teste nem conhece o teste de código, apenas segue a especificação de alto nível e verifica se cumprimos do ponto de vista comportamental / funcional.

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

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

Aplicamos testes metódicos em todos os aplicativos que criamos. Talvez a qualidade dos testes não esteja de acordo com o padrão, mas nós os empregamos.

Por mais que o purista em mim não queira aceitar que deve haver algum gerenciamento de risco embutido na decisão de quão rigorosamente você testa ou se faz algum teste formalizado. Para aplicativos internos, que eu suspeito serem uma grande porcentagem de projetos de programação, o custo de liberar um bug e corrigi-lo rapidamente depois que ele é percebido às vezes pode ser superado pelo custo de uma equipe de teste completa. Obviamente, isso depende do aplicativo e do custo potencial de falhas.

Dito isto, não acho que o planejamento de gerenciamento de riscos seja a razão da falta de testes formalizados. Eu acho que é mais o resultado de gerentes não técnicos não entenderem o valor que ele oferece e apenas veem o custo.

Minha amostra é muito pequena para deduzir porcentagens, mas aqui vai mesmo assim.

Um deles era uma empresa sem chip + firmware, que fazia testes fanáticos. Testes automatizados 24/7 em dezenas de instalações, cada um 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 com dezenas de concorrentes. Heck, eles até compraram uma instalação de testador de chips de vários milhões de dólares para desenvolver e depurar alguns dos testes executados pelas fábricas quando os chips saem da fundição.

Outro era um banco. Este é um ambiente completamente diferente: não há lançamentos de produtos, mas muitos softwares internos para continuar funcionando continuamente. Esses caras testaram o cr * p de todas as alterações que fizeram. Eles tinham uma separação muito estrita dos ambientes DEV / QA / PROD, testes de regressão automatizados, testes obrigatórios de controle de qualidade assinados pelos usuários finais antes de serem lançados na produção etc.

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

Atualmente, escrevo firmware incorporado 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 reporte diretamente ao CEO. Eu nunca tive meu código tão completamente testado antes por testadores separados (a única vez que se compara é quando eu trabalhava em sistemas de TV via satélite há cerca de 15 anos).

Os resultados de nossos testes são submetidos ao FDA (até agora obtivemos duas autorizações do FDA - cada envio tinha cerca de 500 páginas). 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.

Nota - em meus 25 anos de programação / consultoria de contratos, também trabalhei para muitas empresas que praticamente não fizeram testes formais. A maioria deles não está mais por perto.

Quase todas as empresas em que já 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 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 lado interno quanto para o externo.

Nos últimos vinte anos da minha carreira em mais ou menos oito 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 trabalhei fizeram testes formais. Isso se aplica igualmente às pequenas e médias empresas (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, outras não tinham muitos testes manuais, mas tinham pelo menos um ou outro.

Depende das necessidades do cliente. Em uma situação de contrato, provavelmente existem testes de aceitação. Em casa, geralmente é um tapa-sexo com poucos testes. As coisas de consumo geralmente são altamente cobertas por funcionalidades frequentes, mas são difíceis de contornar.

Resposta curta: Sim

Resposta longa:

1. Não tenho uma boa estimativa para a primeira categoria (provavelmente está a alguma distância de zero, mas quanto?), Mas minha experiência realmente corrobora com a sua segunda estimativa. É difícil fornecer porcentagens significativas, pois a quantidade e o tipo de teste depende do tipo de aplicativo que está sendo desenvolvido, do prazo disponível e 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, pois esse é 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 realizar e realizar qualquer teste ad-hoc possível e oportuno (neste estágio), além do tempo necessário para solucionar problemas e superar o inesperado.

2. Passei por vários projetos com diferentes combinações de fatores mencionados acima:

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

   • muito formal, variando de testes de unidade a planos de teste detalhados que envolvem recursos dedicados de controle de qualidade, testes automatizados (realizados pelos testadores com seu próprio conjunto de ferramentas) e relatórios de cobertura de código. Mas isso nem sempre é significativo para os desenvolvedores e para os gerentes

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