¿Cómo verifican las grandes empresas de desarrolladores de software los errores en sus programas?

Me preguntaba cómo las grandes compañías de desarrolladores de software buscan errores en sus programas.

¿Simplemente lo prueban en varias computadoras?

Estas son algunas de las técnicas que utiliza Google.

1. Contrata buenos desarrolladores que puedan producir código confiable.
2. Prueba unitaria en gran medida.
3. Usar revisión de código .
4. Configure una compilación continua para detectar problemas de integración.
5. Tener departamentos dedicados de control de calidad. Es decir, tanto las pruebas de personas como los programas automatizados (por ejemplo, utilizando Selenium) que simulan a los usuarios finales.
6. Tenga monitoreo en la producción para detectar evidencia de mal comportamiento.

Los he clasificado en lo que sospecho es un orden descendente de efectividad en la captura de errores.

Las compañías más grandes generalmente tienen departamentos enteros de preguntas y respuestas que son responsables de probar el código y asegurarse de que funcione de la manera en que se supone que debe hacerlo. Por lo general, es tal como lo describiste: un grupo de personas probando muchas máquinas. Algunas veces las pruebas son automáticas, otras no. Ver Garantía de calidad - Wikipedia

Muchas veces, los propios desarrolladores encontrarán errores durante el proceso de desarrollo. Además, los clientes son con frecuencia los primeros en encontrar un error.

Las empresas más pequeñas, como una para la que estoy trabajando actualmente, utilizan la práctica Agile Testing

Diría que se trata de la madurez de una empresa y no del tamaño :) Hay grandes empresas que tienen malas prácticas de desarrollo y pequeñas empresas que están a la vanguardia.

En general, un equipo de desarrollo maduro participará en las siguientes actividades a 1; minimizar la introducción de nuevos errores en el sistema y 2; encontrar errores en el sistema existente.

Pruebas unitarias: estos son 'mini controladores' para métodos individuales para garantizar que un método haga lo que dice que hace. Estas son siempre pruebas automatizadas.

Pruebas de integración: estas pruebas tienen como objetivo verificar que una unidad de funcionalidad más grande funcione dentro del sistema. Esto puede implicar probar la integración de la base de datos o la integración con bibliotecas de terceros. Estas son pruebas automatizadas también.

Pruebas de aceptación: las pruebas de aceptación se escriben para evaluar los requisitos del usuario. Estos generalmente solo prueban el 'camino feliz'. En mi equipo, estas pruebas están diseñadas para mostrar que si el usuario usa la funcionalidad tal como fue diseñada, no tendrá problemas. Puede ser manual o automatizado.

Pruebas funcionales: estas pruebas son similares a las pruebas de aceptación, pero también prueban la 'ruta infeliz'. Estas pruebas significan probar los escenarios no tan obvios. Puede ser manual o automatizado.

Pruebas de regresión: utilizamos este término para hacer una 'prueba completa' del sistema antes de que se lance a los clientes. Manual o automatizado.

Prueba de gorila: (solo manual). Este es el tipo de prueba cuando humanos muy inteligentes intentan intencionalmente romper la aplicación.

Pruebas de rendimiento Tiene como objetivo garantizar que el rendimiento sea aceptable y no se degrade con el tiempo. Generalmente automatizado.

Pruebas de estabilidad: estas pruebas están diseñadas para garantizar que el sistema permanezca estable con el tiempo. Automatizado.

Integración continua: este es un sistema que comprueba automáticamente su código, lo compila y ejecuta sus pruebas automatizadas. Sus pruebas más rápidas (unidad, integración) se ejecutarán cada vez que un desarrollador confirme el código. Algunos otros se ejecutan todas las noches (aceptación, funcional) o semanalmente (rendimiento, estabilidad).

Informes de cobertura de código: muestra la cantidad de código que se prueba. El código que no tiene cobertura de prueba es más probable que se rompa.

Diferentes herramientas que analizan el código: por lo general, muestran dónde se debe refactorizar el código para que sea menos propenso a posibles errores.

Programación en pareja: dos desarrolladores trabajando juntos para ofrecer funcionalidad. "Un par cohesivo es mejor que la suma de sus partes".

Lo más importante para llevar es: automatización e integración continua .

Depende de la empresa y de los productos que desarrolle.

Primero, muchas compañías aplican prácticas de codificación como revisiones de código y linting obligatorio (herramientas automatizadas de detección de errores) para reducir la cantidad de errores que ingresan al repositorio. Muchas compañías también adoptaron pruebas unitarias. Este es el caso donde trabajo (Google). Cuando se registra el código, las pruebas se ejecutan contra todo, para asegurarse de que no se introduzcan nuevos errores.

En segundo lugar, muchas empresas tienen departamentos de control de calidad que son responsables de validar el comportamiento. Esto es particularmente común en Finanzas (donde los errores pueden ser costosos y las reglas de validación son complejas), pero también existe en compañías que venden productos a usuarios donde los retiros pueden ser costosos (por ejemplo, Intel, Microsoft, etc.).

En tercer lugar, siempre que sea posible, las empresas hacen Dogfooding (sus propios usuarios usan el producto internamente) y luego lanzan versiones beta limitadas. Muchos errores se detectan en esta etapa. Por ejemplo, las personas que trabajan en Microsoft usan versiones internas más nuevas de Office y Windows y DevStudio que las que tiene afuera. Luego, grupos limitados de usuarios o empresas contratadas pueden probarlo. Del mismo modo, en Google utilizamos versiones internas de GMail y Docs antes del lanzamiento. Las compañías de juegos organizan betas abiertas para probar sus productos y la carga en los servidores, etc.

Por supuesto, la respuesta es "Espera", pero daré una muestra de mi proyecto más grande hasta ahora, en el que había alrededor de 50 desarrolladores involucrados.

La configuración básica: un software de back-end para procesar grandes cantidades de datos con BizTalk.

La primera línea de defensa son las pruebas unitarias. En nuestro caso, estos se ejecutaron diariamente para todo lo que se verificó en el control de origen y, por lo general, algunos de ellos fueron ejecutados manualmente por el desarrollador antes del check-in. Las pruebas unitarias fueron escritas principalmente por los desarrolladores, pero a veces se modificaron con pruebas adicionales por parte de los evaluadores.

El siguiente paso fue una compilación semanal de Virtual PC, donde los probadores realizaron una serie de pruebas de principio a fin principalmente automatizadas en el flujo de datos basadas en los documentos de especificación para cada componente.

Después de eso, la misma PC virtual se enriqueció con algunos datos comerciales bastante cercanos a los reales y se probó nuevamente con algunos casos de uso específicos.

Luego, la PC virtual se unió con otros componentes del sistema (también en su mayoría virtuales) de otros departamentos a un ciclo de prueba de integración basado en pruebas de extremo a extremo del usuario que ingresa los datos al final del flujo de datos.

En otra pista, los paquetes de instalación fueron probados por el proveedor de sistemas para ver si se instalaron correctamente en un entorno similar a la producción y si podrían deshacerse si algo fallaba.

Después de la instalación en el entorno similar a la producción, realizamos pruebas de carga y estrés allí para probar la estabilidad general (no es algo que se deba tomar a la ligera cuando se ejecuta en 10 servidores BizTalk, 8 servidores SQL y un montón de otro hardware especializado como un acelerador XML y un archivo dedicado, todos agrupados, por supuesto).

Cuando estuvimos satisfechos con todas las pruebas, el código se puso en producción. Obtiene una latencia bastante grande para corregir errores en el código (como 4-6 semanas para todo el ciclo de prueba), y es costoso hacer todas estas pruebas, pero la estabilidad general fue bastante buena. De hecho, el mejor que he visto hasta ahora. Nuevamente, eso es bastante importante en un sistema que procesa varios millones de dólares por día. Sus requisitos pueden variar, pero así es como lo hemos hecho y funcionó.

La pregunta original parece más conceptualmente genérica que la mayoría de las respuestas altamente detalladas que se proporcionaron.

Veámoslo desde un nivel superior (menos detallado). El software está desarrollado para atender las necesidades específicas de alguien (persona, empresa, lo que sea).

Esas necesidades deben asignarse a las historias / requisitos individuales que se implementarían últimamente (en una fase de construcción) en el código fuente.

Tener las historias / requisitos bien definidos es esencial para que el equipo de Control de calidad (QA) (los probadores de software reales) valide el código final, cuando se ejecuta, atiende las demandas de esas historias y requisitos. Entonces, para ese propósito, el equipo de control de calidad crea "casos de prueba" para hacer esa validación.

El código, una vez lanzado al equipo de control de calidad, se probará y se identificarán los errores. Errores de diferentes tipos y severidades. Se rastrean esos errores y los desarrolladores los asignan para finalmente solucionarlos.

El uso de máquinas virtuales, hoy en día, permite que un probador ejecute diferentes entornos en un mismo hardware real. Pero a veces terminas necesitando algunas computadoras dedicadas a la fase de control de calidad.

Espero que esto te ayude a comprender (aproximadamente) el proceso general.

Bueno, odio ser cínico, pero con la cantidad de errores abiertos en un determinado sistema operativo de 'dispositivo' parece que cuanto más grande y rica es la empresa, más errores son capaces de crear y entregar al usuario final. Si el software funciona y se ve bien, simplemente lo lanzan de todos modos. Si los gerentes piensan que está listo, entonces está listo. Es entonces cuando los errores realmente desagradables comienzan a salir de la carpintería, y los usuarios finales llegan a ser conejillos de indias. Diez años más tarde, la mayoría de los errores se habrán solucionado (y algunos se agregaron por si acaso) y la compañía estará lista para pasar a la próxima gran idea.