Como as grandes empresas de desenvolvedores de software verificam se há bugs em seus programas?

Fiquei imaginando como grandes empresas de desenvolvedores de software verificam se há bugs em seus programas.

Eles apenas testam em vários computadores?

Aqui estão algumas das técnicas que o Google usa.

1. Contrate bons desenvolvedores com probabilidade de produzir código confiável.
2. Teste de unidade fortemente.
3. Use a revisão de código .
4. Configure uma construção contínua para detectar problemas de integração.
5. Tenha departamentos de controle de qualidade dedicados. Significa testes de pessoas e programas automatizados (por exemplo, usando Selenium) que simulam usuários finais.
6. Tenha monitoramento na produção para detectar evidências de comportamentos inadequados.

Eu os classifiquei na que eu suspeito ser uma ordem decrescente de eficácia na captura de bugs.

As empresas maiores geralmente têm departamentos completos de perguntas e respostas, responsáveis ​​por testar o código e garantir que ele funcione da maneira que deveria. Geralmente é como você descreveu - um monte de gente testando muitas máquinas. Às vezes, os testes são automatizados, às vezes não. Consulte Garantia de qualidade - Wikipedia

Muitas vezes, os próprios desenvolvedores encontrarão erros durante o processo de desenvolvimento. Além disso, os clientes geralmente são os primeiros a encontrar um bug.

Empresas menores, como uma para quem trabalho atualmente, usam a prática Agile Testing

Eu diria que é sobre a maturidade de uma empresa e não o tamanho :) Existem grandes empresas com práticas de desenvolvimento precárias e pequenas empresas que estão no limite.

Em geral, uma equipe de desenvolvimento madura se envolverá nas seguintes atividades para 1; minimizar a introdução de novos bugs no sistema e 2; encontre bugs no sistema existente.

Teste de unidade: esses são 'mini drivers' para métodos individuais para garantir que um método faça o que ele diz que faz. Estes são sempre testes automatizados.

Teste de integração: Esses testes visam verificar se uma unidade maior de funcionalidade funciona dentro do sistema. Isso pode envolver o teste de integração de banco de dados ou integração com bibliotecas de terceiros. Estes são testes automatizados também.

Teste de aceitação: os testes de aceitação são gravados para testar os requisitos do usuário. Estes geralmente apenas testam o 'caminho feliz'. Na minha equipe, esses testes são projetados para mostrar que, se o usuário usar a funcionalidade como foi projetada para ser usada, eles não terão problemas. Pode ser manual ou automatizado.

Teste funcional: esses testes são semelhantes aos testes de aceitação, mas também testam o 'caminho infeliz'. Esses testes pretendem testar os cenários não tão óbvios. Pode ser manual ou automatizado.

Teste de regressão: usamos esse termo para fazer um 'teste completo' do sistema antes de ser liberado para os clientes. Manual ou automatizado.

Teste de gorila: (somente manual). Esse é o tipo de teste quando seres humanos muito inteligentes tentam intencionalmente interromper o aplicativo.

Teste de desempenho Visa garantir que o desempenho seja aceitável e que não ocorra degradação ao longo do tempo. Geralmente automatizado.

Teste de estabilidade: esses testes foram projetados para garantir que o sistema permaneça estável ao longo do tempo. Automatizado.

Integração Contínua: Este é um sistema que verifica automaticamente seu código, o compila e executa seus testes automatizados. Seus testes mais rápidos (unidade, integração) serão executados toda vez que um desenvolvedor confirmar o código. Alguns outros são executados todas as noites (aceitação, funcional) ou semanalmente (desempenho, estabilidade).

Relatórios de cobertura de código: mostra quanto do seu código foi testado. O código que não possui cobertura de teste tem mais probabilidade de quebrar.

Ferramentas diferentes que analisam o código: geralmente mostram onde o código precisa ser re-fatorado para torná-lo menos propenso a possíveis erros.

Programação em pares: dois desenvolvedores trabalhando juntos para fornecer funcionalidade. "Um par coeso é melhor que a soma de suas partes."

O mais importante a ser levado é: automação e integração contínua .

Depende da empresa e dos produtos que desenvolve.

Primeiro, muitas empresas aplicam práticas de codificação como revisões de código e fiapos obrigatórios (ferramentas automatizadas de detecção de bugs) para reduzir a quantidade de erros que entram no repositório. Muitas empresas também adotaram testes de unidade. É o caso em que trabalho (Google). Quando o código é registrado, os testes são executados contra tudo, para garantir que nenhum novo erro seja introduzido.

Segundo, muitas empresas têm departamentos de controle de qualidade responsáveis ​​pela validação do comportamento. Isso é particularmente comum em Finanças (onde os erros podem ser caros e as regras de validação são complexas), mas também existe em empresas que vendem produtos para usuários onde os recalls podem ser caros (por exemplo, Intel, Microsoft, etc.).

Terceiro, sempre que possível, as empresas fazem Dogfooding (seus próprios usuários usam o produto internamente) e depois lançam betas limitados. Muitos erros são detectados nesta fase. Por exemplo, as pessoas que trabalham na Microsoft usam versões internas mais recentes do Office e Windows e DevStudio que as que você possui fora. Em seguida, grupos limitados de usuários ou empresas contratadas podem experimentar. Da mesma forma, no Google, usamos versões internas do GMail e Docs antes do lançamento. As empresas de jogos organizam betas abertos para testar seus produtos e a carga nos servidores, etc.

É claro que a resposta é "Isso depende", mas darei uma amostra do meu maior projeto até agora, que teve no horário de pico cerca de 50 desenvolvedores envolvidos.

A configuração básica: um software de back-end para processar grandes quantidades de dados com o BizTalk.

A primeira linha de defesa são os testes de unidade. No nosso caso, eles eram executados diariamente para tudo verificado no controle de origem e, geralmente, alguns deles eram executados manualmente pelo desenvolvedor antes do check-in. Os testes de unidade foram escritos principalmente pelos desenvolvedores, mas algumas vezes foram alterados com testes adicionais pelos testadores.

O próximo passo era uma compilação semanal do Virtual PC, onde os testadores executavam uma série de testes de ponta a ponta principalmente automatizados no fluxo de dados, com base nos documentos de especificação de cada componente.

Depois disso, o mesmo PC virtual foi enriquecido com alguns dados comerciais bastante próximos do real e testado novamente com alguns casos de uso específicos.

Em seguida, o Virtual PC foi montado com outros componentes do sistema (também virtuais) de outros departamentos para um ciclo de teste de integração com base nos testes de ponta a ponta do usuário inserindo os dados no final do fluxo de dados.

Em outra trilha, os pacotes de instalação foram testados pelo provedor de sistemas para verificar se foram instalados corretamente em um ambiente semelhante à produção e se poderiam ser revertidos se algo falhar.

Após a instalação no ambiente de produção, executamos testes de carga e estresse para testar a estabilidade geral (algo que não deve ser levado em consideração quando você executa em 10 servidores BizTalk, 8 servidores SQL e vários outros hardwares especializados, como um acelerador XML e um arquivo dedicado - todos agrupados, é claro).

Quando ficamos satisfeitos com todos os testes, o código foi colocado em produção. Você obtém uma latência bastante grande para corrigir erros no código (como 4-6 semanas para todo o ciclo de teste), e é caro fazer todos esses testes, mas a estabilidade geral foi muito boa. Na verdade, o melhor que eu já vi até agora. Novamente, isso é muito importante em um sistema que processa vários milhões de dólares por dia. Seus requisitos podem variar, mas foi assim que fizemos e funcionou.

A pergunta original parece mais conceitualmente genérica do que a maioria das respostas altamente detalhadas fornecidas.

Vamos olhar de um nível superior (menos detalhado). O software é desenvolvido para atender a necessidades específicas de alguém (pessoa, empresa, qualquer que seja).

Essas necessidades precisam ser mapeadas nas histórias / requisitos individuais que seriam ultimamente (em fase de construção) implementados no código-fonte.

Ter as histórias / requisitos bem definidos é essencial para a equipe de Garantia da Qualidade (QA) (validadores de software reais) validar o código final, quando executado, atende às demandas dessas histórias e requisitos. Portanto, para esse objetivo, a equipe de controle de qualidade cria "casos de teste" para fazer essa validação.

O código, uma vez liberado para a equipe de controle de qualidade, será testado e os erros serão identificados. Erros de diferentes tipos e severidades. Esses bugs são rastreados e os desenvolvedores os designam para finalmente consertá-los.

Atualmente, o uso de máquinas virtuais permite que um testador execute ambientes diferentes em um mesmo hardware real. Mas, às vezes, você acaba precisando de alguns computadores dedicados à fase de controle de qualidade.

Espero que ajude você a entender (aproximadamente) o processo geral.

Bem, eu odeio ser cínico, mas com o número de bugs abertos em um determinado sistema operacional de 'dispositivo' parece que quanto maior e mais rica a empresa, mais bugs eles são capazes de criar e entregar ao usuário final. Se o software funcionar e parecer legal, ele será liberado de qualquer maneira. Se os gerentes pensam que está pronto, então está pronto. É quando os bugs realmente desagradáveis ​​começam a sair da madeira, e os usuários finais passam a ser cobaias. Dez anos mais tarde, a maioria dos bugs já foi resolvida (e alguns foram adicionados por uma boa medida) e a empresa estará pronta para avançar para a próxima grande idéia.