Joel on Software

Joel on Software   La Opinión de Joel sobre qué es Software

 

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Las Cinco Principales Razones (Equivocadas) por las Cuales no tienes Ingenieros de Prueba


Por Joel Spolsky
Traducido por Jerry Elizondo
Editado por Dario Vasconcelos
30/4/2000

En 1992, James Gleick estaba experimentando muchos problemas con software defectuoso. Una nueva versión de Microsoft Word para Windows había salido, la cual Gleick, escritor de ciencia, consideraba espantosa. Escribió un largo artículo en la revista dominical del New York Times que sólo podría describirse como despotricante, crucificando al equipo responsable de Word por su falta de respuesta a los pedidos de los clientes y por lanzar un programa enormemente defectuoso.

Después, como cliente del proveedor de servicios de Internet Panix (el cual resulta que también es mi proveedor de Internet), él quería una forma de ordenar y filtrar automáticamente su correo electrónico. La herramienta UNIX para realizar esto se llama procmail, la cual es realmente arcana y tiene la clase de interfase que aún los más fieles adeptos a UNIX admiten es obscura.

De cualquier forma, el Sr. Gleick sin querer escribió mal un comando en procmail lo que borró todo su correo. Furioso, él decidió que crearía su propia compañía de acceso a Internet. Contrató a Uday Ivatury, un programador, y creó Pipeline, que estaba realmente adelantado a su tiempo: era el primer proveedor comercial de acceso a Internet con una interfase gráfica de cualquier tipo.

Ahora bien, Pipeline también tenía sus problemas, desde luego. La primer versión no usaba ningún tipo de protocolo para la corrección de errores así que tenía una tendencia a revolver las cosas o dejar de funcionar. Como todos los programas, tenía defectos. Solicité un trabajo en Pipeline en 1993. Durante la entrevista le pregunté al Sr. Gleick respecto al artículo que él había escrito. “Ahora que está del otro lado de la barrera,” pregunté, “¿tiene usted un poco más de aprecio hacia la dificultad para crear buenos programas?”

Gleick no estaba arrepentido. Negó que Pipeline tuviera defectos. Negó que fuera tan malo como Word. Me dijo: “un día Joel, tú también llegarás a odiar a Microsoft”.  Yo estaba un poco asombrado de que su año de experiencia como creador de un programa, no simplemente un usuario de programas, no le hubieran dado ni una brizna de aprecio por las dificultades de crear programas realmente libres de defectos y fáciles de usar. Así que huí, declinando la oferta de trabajo. (Pipeline fue comprada por PSI, el más extraño proveedor de Internet sobre la tierra, y sin más ceremonia retirado y fusilado.)

Los programas tienen defectos. Las unidades centrales de procesamiento son increíblemente melindrosas. Se rehúsan absolutamente a tener algo que ver con cosas que no les fueron enseñadas explícitamente y tienden a rehusarse en formas completamente infantiles. Cuando uso mi computadora portable fuera de casa, tiende a dejar de funcionar constantemente porque no puede encontrar la impresora de red que generalmente encuentra. Qué nena. Esto probablemente viene de una sola línea de código en algún lugar que tiene un pequeñísimo, casi insignificante, defecto.

Por esto positivamente, absolutamente, debes tener un departamento de Control de Calidad (CC). Vas a necesitar un ingeniero de pruebas por cada dos programadores (más si tus programas necesitan funcionar en complicadas configuraciones múltiples o diferentes sistemas operativos.) Cada programador debe trabajar de cerca con un solo ingeniero de pruebas, facilitándole compilaciones privadas tan frecuentemente como sea necesario.

El departamento de Control de Calidad debe ser independiente y poderoso, no debe reportar al equipo de desarrollo, de hecho, el jefe de CC debe tener poder de veto sobre cualquier lanzamiento de programas que no estén suficientemente libres de defectos.

Mi primer trabajo real creando programas fue con Microsoft; una compañía que no es exactamente famosa por la alta calidad de su código, pero la cual de cualquier manera contrata a grandes números de ingenieros de prueba. Así que asumí que toda operación de desarrollo de programas tendría ingenieros de prueba.

Muchas los tienen. Pero un número sorprendente no. De hecho, muchos equipos de desarrollo ni siquiera creen en hacer pruebas.

Pensaría que después de la manía de la Calidad en los años 80, con toda clase de certificaciones internacionales de “calidad” sin sentido como el ISO-9000 y palabras domingueras como “six-sigma”, los gerentes de hoy habrían entendido que tener productos de alta calidad tiene mucho sentido para los negocios. De hecho, lo han entendido. Pero todavía salen con muchas razones para no tener ingenieros de pruebas, todas las cuales están equivocadas.

Espero poder explicar por qué esas razones son equivocadas. Si tienes prisa, no leas el resto del artículo, y sal a contratar un ingeniero de pruebas de tiempo completo por cada dos programadores en tu equipo.

Aquí están las razones más pazguatas que he escuchado para no contratar ingenieros de prueba:

1. Los defectos son culpa de programadores flojos

“Si contratamos ingenieros de prueba,” dice esta fantasía, “los programadores se volverán descuidados y escribirán código defectuoso. Al evitar a los ingenieros de prueba, podemos forzar a los programadores a escribir el código correcto en primer lugar.”

Caray. Si piensas así, o nunca has escrito código o eres increíblemente deshonesto respecto a lo que es escribir código. Los defectos, por definición, suceden porque los programadores no vieron el defecto en su propio código. Muchas veces sólo se necesita otro par de ojos para ver un defecto.

Cuando estaba escribiendo código en Juno, tendía a ejercitar mi código de la misma manera cada vez... Usaba mis propios hábitos, dependiendo mucho del ratón. Nuestra maravillosa, enormemente sobre-calificada ingeniera de pruebas tenía hábitos diferentes: ella hacía muchas cosas con el teclado (y de hecho rigurosamente probaba la interfase usando cada posible combinación de procesos de entrada.) Esto rápidamente descubría un montón de defectos. De hecho a veces ella reportaba que la interfase simplemente no funcionaba, 100% no funcionaba, aun cuando siempre funcionaba para mí. Cuando la veía reproducir el defecto tenía uno de esos momentos en los que te golpeas la frente. ¡Alt! ¡Estás oprimiendo la tecla Alt! ¿Por qué no probé eso?

2. Mis programas están en Internet. Puedo reparar defectos en un segundo.

¡Ja ja ja! De acuerdo, es verdad, la distribución a través de Internet te permite reparar defectos mucho más rápidamente que en los viejos tiempos de programas de paquete. Pero no desestimes el costo de reparar un defecto, aun en un sitio web, después de que el proyecto ha sido concluido. Para empezar, puede que introduzcas más defectos al reparar el primero. Pero un problema peor es que si miras el proceso que usas para lanzar nuevas versiones, te darás cuenta que puede ser una propuesta muy costosa liberar reparaciones en Internet. Además de la mala impresión que dejarás, lo cual nos lleva a:

3. Mis clientes probarán los programas

Ah, la temida “Defensa Netscape”. Esta pobre compañía hizo una cantidad casi sobrenatural de daño a su reputación a través de su metodología de “pruebas”.

  1. Cuando los programadores están a medio terminar, lanza el programa a través de Internet sin probarlo.
  2. Cuando los programadores digan que ya terminaron, lanza el programa a través de Internet sin probarlo.
  3. Repítelo seis o siete veces.
  4. Nombra una de esas versiones la “versión final.”
  5. Lanza versiones .01, .02, .03 cada vez que se mencione un defecto vergonzoso en c|net.

Esta compañía fue una de las primeras en usar la idea de “betas amplios.” Literalmente millones de personas descargaban de Internet esos lanzamientos sin terminar y defectuosos. Durante los primeros años, casi todos los que usaban Netscape estaban usando una versión de pre-lanzamiento o beta. Como resultado, la mayoría de la gente piensa que los programas de Netscape son muy defectuosos. Aun cuando el lanzamiento final por lo general estaba razonablemente libre de defectos. Netscape tenía tanta gente usando versiones defectuosas que la impresión promedio que la mayoría de la gente tiene del programa es bastante pobre.

Además, el punto central de dejar que “tus clientes” hagan las pruebas es que ellos encuentran los defectos y tú los reparas. Desafortunadamente, ni Netscape ni ninguna otra compañía sobre la tierra tienen suficiente personal para revisar los reportes de 2,000,000 de clientes y decidir qué es realmente importante. Cuando yo reportaba defectos en Netscape 2.0, el sitio web para reportar defectos con frecuencia dejaba de funcionar y no me permitía hacer el reporte (el cual, desde luego, habría terminado en un agujero negro de cualquier manera.) Pero Netscape no aprende. Los “probadores” de su actual versión de “pre-lanzamiento”, la 6.0, han estado quejándose en los sitios de discusión que el sitio para reportar defectos sigue sin permitir que se realicen los reportes. ¡Años después! ¡Mismo problema!

De esos zillones de reportes de defectos, apostaría que casi todos eran acerca de los mismos 5 o 10 defectos realmente obvios, de cualquier forma. Enterrados en ese pajar habría uno o dos defectos interesantes y difíciles de encontrar que alguien se ha tomado el trabajo de reportar pero nadie revisa todos los reportes de cualquier manera, así que se pierde.

Lo peor de esta forma de probar programas es la evidente mala impresión que dejarás de tu compañía. Cuando Userland lanzó su primera versión de su producto estelar Frontier para Windows, lo descargué de Internet y comencé a usar el modo tutor. Desafortunadamente Frontier dejó de funcionar varias veces. Estaba siguiendo literalmente las instrucciones, tal y como estaban impresas en el manual, pero no podía usar el programa por más de un par de minutos. Sentí que nadie en Userland había hecho ni siquiera la más mínima cantidad de pruebas, asegurándose que el modo tutor funcione. La baja calidad percibida por mí de este producto me desilusionó de Frontier durante mucho tiempo.

4. Cualquiera con las calificaciones de un ingeniero de pruebas no quiere trabajar haciendo pruebas

Este es de veras doloroso. Es difícil contratar buenos ingenieros de prueba.

Con los ingenieros de prueba, como con los programadores, los mejores son un orden de magnitud mejores que los promedio. En Juno, teníamos una ingeniera de prueba, Jill McFarlane, quien encontraba tres veces más defectos que los otros cuatro ingenieros, juntos. No estoy exagerando. Yo medí esto. Ella era más de doce veces más productiva que el ingeniero de pruebas promedio. Cuando ella renunció, envié un correo electrónico al Director General diciendo “Prefiero tener a Jill los lunes y los martes que a todo el resto del equipo de control de calidad.”

Desafortunadamente, la mayor parte de la gente que es inteligente tenderá a aburrirse haciendo pruebas todos los días, así que los mejores ingenieros de prueba tienden a durar 3 o 4 meses y entonces irse.

Lo único que se puede hacer respecto a este problema es reconocer que existe y lidiar con ello. Algunas sugerencias:

  • Usa la posición de pruebas como un ascenso de soporte técnico. Tan tedioso como pueda ser probar programas, por seguro es mejor que lidiar con usuarios enardecidos en el teléfono, y esto puede ser una manera de eliminar algo del hervor en el lado de soporte técnico.
  • Permite a los encargados de pruebas desarrollar sus carreras tomando clases de programación y aliente a los más listos para que desarrollen juegos de pruebas automatizadas usando herramientas y lenguajes de programación. Esto es mucho más interesante que probar la misma ventana de diálogo una y otra, y otra y otra vez.
  • Reconoce que tendrás una alta rotación entre tus mejores ingenieros de prueba. Sé agresivo con las contrataciones para mantener un flujo continuo de gente. No dejes de contratar porque temporalmente tienes completa la lista, porque la edad dorada no durará para siempre.
  • Busca trabajadores “no tradicionales”: adolescentes inteligentes, jóvenes universitarios, gente retirada, gente que quiera trabajar medio turno. Puedes crear un excelente departamento de pruebas con dos o tres buenos empleados de tiempo completo y un ejército de chicos del Bronx Science (una escuela preparatoria de alto nivel en Nueva York) que trabajen durante el verano a cambio de dinero para la universidad.
  • Contrata personal temporal. Si contratas unos 10 “temporales” para que vengan y usen tu programa durante unos días encontrarás un tremendo número de defectos. Es posible que dos o tres de esos “temporales”  tengan habilidad para hacer pruebas en cuyo caso vale la pena contratarlos para tenerlos de tiempo completo. Reconoce desde el principio que algunos de los “temporales” no tendrán habilidad para hacer las pruebas; mándalos a casa y sigue tu camino. Para eso existen las agencias de colocación temporal.

Esta es una manera de no lidiar con esto:

  • Ni se te ocurra decirle a los graduados en ciencias computacionales que pueden venir a trabajar contigo pero “todos tienen que cumplir un tiempo trabajado en Control de Calidad antes de poder comenzar a escribir código.” He visto mucho de esto. Los programadores no son buenos para hacer pruebas y perderás un buen programador, el cual es más difícil de reemplazar.

Y finalmente, la razón estúpida número uno para no contratar ingenieros de pruebas:

5. ¡No tengo dinero para contratar ingenieros de prueba!

Esta es la más estúpida y la más fácil de refutar.

No importa qué tan difícil sea encontrar ingenieros de prueba, ellos siguen siendo mucho más baratos que los programadores. Mucho más. Y si no contratas ingenieros de prueba, vas a tener programadores haciendo pruebas. Y si crees que es malo cuando los ingenieros de pruebas se largan, espera a que veas qué tan caro es reemplazar al programador estrella, con un salario de $100,000 dólares al año, quien se cansó de escuchar que debe “pasar unas cuantas semanas haciendo pruebas antes del lanzamiento” y decidió trabajar para una compañía más profesional.  Puedes contratar a tres ingenieros de pruebas por un año sólo con los honorarios que la agencia de colocaciones te cobrará por reemplazar al programador.

Ahorrarse a los ingenieros de pruebas es un ahorro falso tan impresionante que simplemente no puedo creer que la mayoría de la gente no lo entienda.



Esté articulo apareció originalmente en Inglés con el nombre Top Five (Wrong) Reasons You Don't Have Testers  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky