O teste de software é realmente realizado em projetos profissionais?


25

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.


Ótima pergunta, obrigado por reservar um tempo para reformular!

@ Mark Trapp: Obrigado. I kindda acho que é bastante básico, mas posso perguntar alguns mais (com base no conjunto anterior de perguntas)
Robert Koritnik

Respostas:


8

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.


Eu editei minha pergunta um pouco. Você poderia fornecer suas estimativas também?
Robert Koritnik

Quase todos os projetos (mais de 80%) em que estive envolvido foram metodicamente testados, mas depois fiz quase exclusivamente aplicativos corporativos de missão crítica.
Martin Brown

Eu trabalho para empresas farmacêuticas. Eu diria que 80% dos aplicativos são testados por testadores e desenvolvedores profissionais. Esses 20% são aplicativos de baixo risco, como apresentações promocionais no iPad. mas mesmo este é verificado ad-hoc por alguém.
yoosiba

5

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.


Eu editei minha pergunta um pouco. Você poderia fornecer suas estimativas do mercado profissional de desenvolvimento. Porque seus projetos são examinados. E seus testes são automatizados ou não?
Robert Koritnik

Quem é essa equipe offshore? Você daria a eles uma recomendação?
Martin Brown

Geralmente, grandes empresas possuem centros de pesquisa e desenvolvimento em outros países (principalmente na Ásia). Onde o desenvolvimento offshore é feito. O objetivo do desenvolvimento offshore é reduzir o custo do desenvolvimento (parte dele).
Nipuna

2

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.


Eu editei minha pergunta um pouco. Você também poderia fornecer suas estimativas sobre testes de software no mercado profissional?
Robert Koritnik

@ Robert: Eu não tenho sido o suficiente para dar uma estimativa geral. Pelo pouco que sei, as coisas estão melhorando. Mas então, tinha-me que estava empurrando para testes de unidade automáticas sido em dois dos três casos que lhe falei ...
SBI

Mas você fala com outros desenvolvedores de outras empresas, não é?
Robert Koritnik

2

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


Eu editei minha pergunta um pouco. Você também poderia fornecer suas estimativas de teste de software no mercado profissional?
Robert Koritnik

2

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.


2
Discordo totalmente de você - você nunca viu um roteador falhar? Os jogos Xbox, Playstation e Wii ficam bloqueados? Já teve uma tela azul ou 'O aplicativo não está respondendo' no Windows?
precisa saber é o seguinte

@JBRWilkinson Acho que você está perdendo seus modificadores de gravidade, bem como possivelmente entrando na grande maioria dos jogos de PC que, como Paul diz, costumam estar com erros. De qualquer forma, a lista provavelmente poderia usar alguma melhoria, mas o sentimento está correto: a confiabilidade geralmente se correlaciona com as perdas fiscais associadas à falha.
Jay Carr

1

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 ...


Obrigado pela sua resposta honesta. Quais são suas estimativas (verifique minha pergunta editada)?
Robert Koritnik

Minha estimativa para a Itália é inferior a 10% dos testes formais de código. Talvez quase apenas código de missão crítica.
usar o seguinte comando

Eu trabalhei na Irlanda, Inglaterra, Escócia e Eslovênia e, ao que parece, a Itália não parece diferente.
Robert Koritnik

1

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.


Esses testes seriam automatizados ou principalmente manuais? Eu editei minha pergunta um pouco. Você também poderia fornecer suas estimativas de teste de software no mercado profissional?
Robert Koritnik

A maioria dos nossos testes é feita manualmente.
Shamim Hafiz

1

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.


2
Eu ouvi o que você está dizendo, mas é difícil justificar. Estudos demonstraram que quanto mais tempo um bug passa despercebido, mais custa exponencialmente. O custo dos bugs para chegar ao cliente é enorme, e o patch geralmente causa novos bugs, se uma estrutura de teste de unidade não estiver em vigor (um cenário provável quando esse tipo de mentalidade de "corrigir e consertar" está presente). Conseqüentemente, o uso criterioso de ferramentas e metodologias de teste pode ser muito mais barato que o patch and fix.
Robert Harvey

3
Estou ficando cada vez mais cético em relação a esse dogma, especialmente como ele é aplicado universalmente. Tenho certeza de que isso acontece algumas vezes, mas nem todos os bugs são criados da mesma forma, nem todos os aplicativos. Acho muito difícil entender que um bug em um aplicativo interno usado por 10 pessoas é significativamente mais caro para corrigir se for encontrado durante o teste de unidade em comparação com o lançamento de um patch. Pode ser exponencialmente mais embaraçoso, mas não mais dispendioso, a menos que você ignore os custos reais do tempo que um testador passa encontrando o bug.
JohnFx 15/09

2
Também me pergunto se essas estatísticas não eram mais aplicáveis ​​aos grandes projetos (por exemplo, sistemas operacionais) dos quais foram criadas e não se traduzem nos aplicativos do tipo CRUD que a maioria de nós constrói para viver.
precisa saber é o seguinte

Eu concordo com vocês dois e já vi os dois casos. Mas certamente pareço minha parcela dos custos exponenciais que Robert está descrevendo, principalmente quando há um erro no software há tanto tempo que outros recursos realmente começam a quebrar se forem corrigidos. Com uma codificação frenética o suficiente com pessoas trabalhando em torno de problemas por tempo suficiente e erros que permanecem dentro de um período de tempo suficiente, 1 + 1 não é 2. São 7. E se não for 7, tudo vai desmoronar.

1

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.


1

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.


Também estou em uma empresa de dispositivos médicos, e a introdução ao GMP (Boas Práticas de Fabricação, da FDA - para um processo controlado de projeto / teste) foi bastante surpreendente para mim. Ele me fez um melhor engenheiro (e docbook especialista infelizmente)
Bill Gribble

0

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.


Eu editei minha pergunta um pouco. Você também poderia fornecer suas estimativas de teste de software no mercado profissional?
Robert Koritnik

@ Robert: Eu não entendo sua pergunta "estimativas de teste de software". Você está perguntando minha opinião sobre quantas empresas testam? Minha estimativa seria talvez 90% ou mais com base no que vi com meus próprios olhos. O teste é uma parte comum do desenvolvimento profissional.
Bryan Oakley

0

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.


0

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.


0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.