Este post fue originalmente publicado en el blog de PractiTest. PractiTest, simplifica tu manejo y administración de Testing. Aprende más. Regístrese para empezar una prueba gratuita.
¿Confiarías en un programador para hacer el testing de tu aplicación? Sería como pedirle a un zorro que cuide el gallinero, ¿verdad?
Bueno, a veces no tienes otra alternativa, o la única que tienes es lanzar la aplicación sin hacerle el testing…
Como parte de una actividad de consultoría de testing Ágil que estoy realizando en la compañía de un amigo, ayer comencé a brindar unas breves sesiones de entrenamiento para programadores que necesitan aprender a hacer un mejor testing. No es que dicha compañía no tenga testers, ¡los tiene y muy buenos! Pero, como en cualquier otro equipo de desarrollo ágil, tienen muchas más tareas de testing que testers disponibles, y por tanto quieren que también haya programadores que participen al menos en algunas de sus tareas de testing.
¡Los programadores no son buenos haciendo testing!
Un par de meses atrás, escribí un artículo en el que explicaba por qué yo pienso que los programadores son malos para el testing, y todavía creo que, de alguna forma, es como pedirle a un perro que vuele (dale una ojeada a la foto tan ilustrativa que aparece en ese artículo :) ). Por otro lado, también pienso que con buenas intenciones, trabajo duro y perseverancia, se le puede enseñar a un perro a tomar la suficiente distancia y entonces saltar sobre grandes obstáculos.
De la misma manera, nunca va a ser posible transformar mágicamente y de la noche a la mañana a un programador en un buen tester, pero sí que puedes comenzar a trabajar con ellos en sus debilidades y entonces enseñarles algunas técnicas de testing, simples pero efectivas. Con buenas intenciones, un poco de práctica, algo de apoyo, y retroalimentación constante, obtendrás una buena ayuda en el testing de tu proyecto.
Paso 1 – entender las limitaciones y debilidades de un programador
Comencé mi sesión de ayer repasando los puntos explicados en mi artículo anteriormente mencionado que describe a los programadores como “no tan excelentes testers”:
– Sentimientos paternalistas hacia su propio código.
– La dirección de su atención puesta principalmente en escenarios positivos, en vez de estar buscando activamente los errores.
– Tendencia a ver un “problema complejo” como una colección de “casos aislados, más pequeños y simples”.
– Menos orientado al End-to-End y a la Perspectiva del Usuario.
– Menos experiencia con y conocimiento de los errores e inconvenientes más comunes en las aplicaciones.
Algo que resultó muy acertado durante la sesión fue que no solamente se listaron las debilidades, sino que también se habló sobre por qué cada una de ellas está necesariamente presente en los programadores, dada la naturaleza de su trabajo, su conocimiento y entrenamiento.
Paso 2 – cómo planificar el testing
He visto que muchos (¿la mayoría?) programadores tiene la idea de que el testing requiere muy poca o ninguna planificación.
Tal vez nosotros, los testers, seamos los culpables de esa concepción errónea por no hacerlos formar parte de nuestro proceso de planificación del testing tanto como deberíamos, pero lo cierto es que cuando les pedimos que hagan testing, ellos automáticamente toman el mouse y comienzan a presionar todos los botones sin medir ni pensarlo mucho.
La planificación es un aspecto esencial del buen testing, así que les di un par de ideas y principios de planificación:
1. ¡NO HAGAS EL TESTING A TU PROPIO CÓDIGO!
Cuando, como equipo, se les pide que hagan testing, deberían asegurarse de dividir las tareas de tal forma que cada uno haga testing a algún código que haya sido desarrollado por otros programadores, en la medida de lo posible.
2. Trabaja con tu equipo de testing para crear sets de testing.
Este equipo en particular está usando PractiTest (la plataforma de Administración de Testing y QA en línea que mi compañía está desarrollando), pero puede ser cualquier otra herramienta o formato (¡hasta word y excel!). Deberían sentarse con sus testers y definir qué casos de testing deberán ser ejecutados, reusando los scripts de testing que ya estén disponibles en sus repositorios.
3. Expande tus escenarios haciendo “Listas de Testing”
- Funcionalidades que fueron creadas o modificadas (directa o indirectamente)
- Perfiles de usuario y escenarios a ser verificados.
- Diferentes entornos / configuraciones / conjuntos de datos a ser testeados
Estas listas cumplen un doble propósito.
Te ayudan a tener una idea más clara de qué es lo quieres testear mientras ejecutas tus scripts manuales de testing, pero también sirven como una lista de verificación que deberá ser consultada hacia el final del testing, cuando ya estés en la búsqueda de ideas adicionales o quieras asegurarte de que no te esté faltando nada relevante.
4. Heurísticas en el Testing – SFDEPOT (léase San Francisco Depot)
El uso de (buenas) heurísticas mejora y mucho la calidad de tu testing. Les conté a los programadores sobre la primera vez que aprendí la heurística que aún me sirve hasta el día de hoy. Hace unos años ya, leí a James Bach escribiendo sobre SFDEPO(T); puedes ver una de las fuentes en el sitio de James.
SFDEPOT se refiere a:
eStructura (qué es el producto)
Función (qué hace el producto)
Datos (qué procesa)
Plataforma (de qué depende)
Operaciones (cómo será usado)
Tiempo (cuándo será usado)
Y puedes encontrar más heurísticas y mnemotecnias por Internet...
Paso 3 – qué hacer al ejecutar testing
Hablamos mucho sobre diferentes trucos que nos ayudan a llevar a cabo buenas sesiones de testing.
1. Tener un cuaderno a mano.
Donde puedas tomar notas sobre asuntos tales como ideas para el testing que te gustaría probar más tarde, errores con los que te encuentres, pero en esos casos en que prefieres reportarlos más tarde, para que “no corten tus pensamientos sobre esta sesión de testing”, etc.
2. Trabajar con datos extremos.
Grandes archivos vs. pequeños archivos
Clases equivalentes de entrada [ -10 ; 0 ; 1 ; 10,000,000 ; 0.5 ; not-a-number ]
Fechas: Ayer, ahora, dentro de 10 años
etc.
3. Piensa en escenarios negativos.
- ¿Cómo usaría tu software Mr. Bean?
- ¿Cómo intentaría explotar tu sistema un hacker?
- ¿Y qué pasaría si... ? (apagón, quedarse sin espacio, excepciones, etc.)
- ¿Y qué si tu pequeño de 2 años secuestra el teclado en medio de una operación?
- etc.
4. Centrarse y Descentrarse.
(¡Gracias, Ayal, por enseñarme este año este principio!)
Usé esta técnica para explicarles que durante el proceso de testing, es necesario que hagan un esfuerzo consciente para nunca olvidarse de ver las cosas desde una perspectiva global (aplicación, sistema, proceso) y no únicamente centrarse en la función específica que están probando.
5. Luchar contra la “ceguera por falta de atención”.
Usé el siguiente video de muchachos pasándose la pelota para explicar el concepto de ceguera por falta de atención... ¡y funcionó de maravillas!
Éramos 8 personas en la sala, y yo era el único que había visto antes el video. De los 7 participantes, uno trabaja actualmente como tester, otro trabajó como tal y ahora de desempeña como programador, mientras que el resto son “programadores comunes”.
Lo interesante es que los únicos que vieron el gorila la primera vez fueron los 2 testers... ¿crees que quedó claro el punto?
Paso 4 – qué hacer cuando (tú piensas que) ya terminaste el testing
También conversamos sobre cómo aun cuando tú piensas que terminaste el testing, siempre es necesario que te asegures de que no haya nada más que debas probar, y sobre qué técnicas pueden usar para identificar estos lugares adicionales:
1. Sacar a pasear al perro
Tomarte un descanso de tus pruebas, hacer otra tarea por 30 a 60 minutos, y después volver a revisar qué tests hiciste y qué encontraste. Este descanso frecuentemente ayuda a refrescar la mente y venir con más ideas.
2. Hacer un recorrido en una sesión de ensayo repasando los tests hechos.
La mayor parte de las veces, vas a obtener más ideas si explicas a tus compañeros los tests que acabas de hacer.
La parte más cómica de ello es que varias de dichas ideas van a venir de ti mismo, y de aquello en lo que pienses cuando expliques en voz alta tus tests a los demás.
3. Pedir ideas a otros desarrolladores o testers.
Tal como suena, así de sencillo, acude a otros miembros de tu equipo y pídeles que te tiren ideas de otros asuntos que ellos crean que tú puedes testear. Puede que el 90 % de ellas, ya lo hayas testeado, ¡pero puede que el otro 10 % también te sea de ayuda!
Al fin y al cabo, es una cuestión de mentalidad y motivación
Una de las cosas que más me gusta de los equipos de desarrollo ágil (y otros que no son ágiles pero sí que son equipos astutos de desarrollo) es que ellos definen a la Calidad como una responsabilidad de todo el equipo, y no solamente de los muchachos del testing que realizan pruebas al final del proceso.
Mis palabras finales para el grupo consistieron en recomendarles que recuerden que todo empieza con ellos mismos, y su capacidad de comprender que el testing no es una tarea nimia, ni mucho menos un rezongo por hacer mal el trabajo o por terminar sus tareas antes de tiempo. Y lo que es más, estoy convencido de que una vez que estos muchachos comiencen a hacer un mejor testing y a cobrar una perspectiva de su aplicación más similar a la del tester, también van a comenzar a desarrollar un software aún mejor.
Ahora tengo 3 equipos más de desarrollo para entrenar.
Vamos a ver cómo nos va con ellos :)
Sobre PractiTest
PractiTest es una solución end-to end de Administración de Testing y QA diseñada para ayudarte a controlar tu proceso de desarrollo y testing, centrándote en cómo manejar tu proyecto y su información, y en cómo comunicar los resultados de tu testing a todos dentro de la organización.
Este software te permite organizar tus requisitos, crear y ejecutar tests, identificar errores, etc. Es posible integrarlo con las más renombradas herramientas de administración de errores, como por ejemplo: JIRA, Bugzilla RedMine y Pivotal Tracker, así como con herramientas de automatización tales como Sellenium, JUnit, SoapUI, QTP, Jenkins y muchas más http://www.practitest.com/