Liberándolos. (a juzgar por las pilas de buggy de ... que salen de las principales instituciones)
Orbling
Tienen una campaña de marketing y ventas muy agresiva, subcontratan el desarrollo a otros países y se saltan con cualquier error que puedan ... hasta que "inesperadamente" pierdan una gran cuota de mercado.
Trabajo
¿Por qué crees que es diferente para las grandes empresas que para las pequeñas?
JohnFx
Respuestas:
30
Estas son algunas de las técnicas que utiliza Google.
Contrata buenos desarrolladores que puedan producir código confiable.
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.
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.
Si bien no es una mala respuesta, utiliza mucha terminología como "QA", "prueba unitaria" y "construcción continua" que probablemente no conozca el tipo de persona que haría una pregunta como esta. Sería mejor si vinculó o dio definiciones.
Gabe
@gabe: agregué punteros a la terminología utilizada.
btilly
3
+1 - En realidad, ese es un orden bastante bueno (1-> 6) de cuándo es MEJOR (es decir, el más barato, en tiempo y complejidad) también detectar errores.
ozz
1
tal vez también las pruebas de usabilidad, antes de que el 90% de las solicitudes de funciones de Word fueran para funciones que Word ya tenía, los usuarios simplemente no podían encontrarlas
jk.
@jk: ¿de quién es esa estadística? cita por favor.
JBRWilkinson
19
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
Sí, y la gente de control de calidad inventa planes de prueba.
Trabajo
+1: Así es exactamente como lo hacemos, el equipo de prueba (en el que estoy) escribe los planes de prueba y escribe todo el código de prueba, con la excepción de las pruebas unitarias triviales (los desarrolladores escriben esos, algunos de los cuales practican TDD pero No es obligatorio). Nos centramos en la aceptación, integración y regresiones. Cuando los desarrolladores encuentren errores, lo registrarán, lo arreglarán y lo probaremos y escribiremos automatización para ello.
Steven Evers
18
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 .
No está de acuerdo sobre la madurez de la empresa: es muy posible que el jefe de desarrollo de software también se preocupe por la calidad en una empresa pequeña / joven, y ese mensaje se transmite de arriba hacia abajo. Madurez de los ingenieros, sí, eso es posible.
JBRWilkinson
1
@JBRWilkinson: Creo que podemos comenzar a hablar sobre lo que significa que una empresa sea 'madura'. No quise sugerir que tiene que ver con la edad, más bien como "sabiduría". Una startup puede ser madura / sabia aunque solo tenga uno o dos años.
c_maker
4
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.
Respuestas:
Estas son algunas de las técnicas que utiliza Google.
Los he clasificado en lo que sospecho es un orden descendente de efectividad en la captura de errores.
fuente
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
fuente
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 .
fuente
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.
fuente
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ó.
fuente
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.
fuente
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.
fuente