 Schaefer, Hans. What a Tester Should Know, At Any Time, Even After Midnight. En: Testing Experience, The Magazine for Professional Testers (en línea), Marzo 2008, vol. 1, Berlin, Alemania, Díaz & Hilterscheid Unternehmensberatung GmbH. p. 40 - 48. (citado 04 de mayo 2009). Disponible en Internet: http://www.testingexperience.com/
Puedes hacer el testing necesario, sólo como un trabajo. Esto no es ni suficientemente bueno ni motivador para el tester. Alternativamente, puedes invertir "un poco más", por ejemplo haciendo un mejor trabajo. En este artículo, trataré de definir que significa "un poco más". Es un hecho la idea de que el tester es "el abogado del diablo" en la persecución de defectos potenciales y reales; en la necesidad de dar prioridad por riesgo y beneficio o por importancia; en el uso de información respecto de los defectos, tales como su desigual distribución. Sin embargo, a fin de hacer un buen trabajo, el tester debe requerir calidad del producto a testear. Para ello existe la Declaración de derechos del Tester (1). Finalmente está la necesidad de continuamente aprender: Acerca de defectos, aplicaciones, desarrollo de software, métodos de test y herramientas. De esta manera, el testing se convierte en un trabajo interesante y gratificante; y el tester contribuye al proyecto efectiva y eficientemente.
El testing sistemático de software o sistemas puede ser aprendido, como cualquier otra disciplina ingenieril. Los testers disponen de planes para la certificación de conocimientos (ISTQB, ISEB, GTB)(2), libros (Myers 79, Beizer 95, Kaner 99, Copeland 2004) y estándares (ISTQB Glossary, BS 7925, IEEE 829, 1008, 1012)(3). Al menos los libros y la mayoría de los estándares han estado a nuestro alrededor durante mucho tiempo, y muchas técnicas están ampliamente aceptadas. Esto significa que actualmente el testing puede ser estudiado y luego ejecutado de una manera sistemática. Esto no significa que los típicos métodos de testing descritos en este material son ampliamente practicados (Schaefer 2004). Pero al menos es posible hacer testing "siguiendo el libro". Para un tester o ingeniero de pruebas, hay dos grandes actividades: Diseñar casos de prueba, y ejecutar los casos de prueba observando y analizando los resultados. Si los resultados no son lo esperado, las desviaciones deben ser reportadas y se debe llevar un seguimiento de las mismas. Adicionalmente, los métodos modernos, como el testing exploratorio, incluyen tareas como la automatización, y la gestión del tiempo de testing en la lista de tareas del test. La manera normal de llevar a cabo el trabajo de tester es aprender algunas técnicas, seguirlas, ejecutar el test y concluir el trabajo con un reporte acerca del test ejecutado. La típica descripción de tareas le dice a la gente que "pruebe el sistema", sin definir ningún otro detalle. Algunos libros describen la tarea como "obtener información sobre la calidad" o "medir la calidad" (Hetzel). Como la ejecución del test es una de las últimas actividades en el proyecto, es muy común hacerlo bajo un presupuesto austero y tiempos limitados. Esto significa que los testers tienen una motivación oculta o explícita de comprometerse con la minuciosidad de su trabajo. Por ejemplo, dado que la detección de defectos siempre atrasará tanto el testing como la entrega o aceptación del producto, hay una presión oculta de no encontrar defectos, o al menos de que si se los encuentra no sean demasiado serios. El testing es algo que solo "se hace". Así, el trabajo se convierte en algo no muy motivador, la inversión en aprendizaje se hace escasa, el tester trata de buscar un trabajo diferente y el testing como actividad no mejorará con el tiempo.
Glenford Myers, en 1979, definió el testing de una forma diferente: el objetivo del testing es encontrar defectos. El utilizó esta definición porque motivaba a la gente. Tener un enfoque negativo, tratando de romper el producto, conduce a encontrar defectos cada vez más serios, no solo a chequear que el producto "funcione". Mucha gente hace lo que le dicen hacer. Si se les pide encontrar la mayor cantidad de defectos posible, tratarán de hacer eso. Si se les pide que terminen su trabajo (y explicita o inherentemente reciben el mensaje de que los defectos retrasan el progreso), tratarán de no encontrar defectos, o dejarán pasar demasiados. Entonces, la primer regla es definir claramente el propósito del testing, y hacerlo perfectamente claro para toda la gente. Esto se discutirá en el próximo punto. Hay un problema adicional a cualquier trabajo, no sólo al testing: El mundo se está desarrollando, especialmente en lo que se refiere a software. Nuevas tecnologías, métodos y herramientas están disponibles o son utilizadas en diseño. Los productos de software están cada vez más integrados entre sí y se hacen cada vez más complejos. El enfoque de los requerimientos está cambiando, por ejemplo, haciendo más hincapié en la seguridad, la interoperabilidad y la usabilidad. Esto conduce a cambiar los requerimientos del trabajo de testing. Entonces, un tester debería tratar de aprender continuamente. Esto se discutirá en el punto 4. El próximo problema es la mentalidad de las personas. Algunas personas rápidamente aceptan la información que ven o las reglas que les son dadas. Otras personas son críticas, investigan y preguntan. Como uno de los propósitos del testing es encontrar problemas y defectos, una mentalidad que no acepte sin preguntar, sin solicitar más detalles, sin obtener más información o pensar; nos conducirá a un mejor testing. Esto será discutido en el punto 5. Parte de la tarea de un tester es reportar defectos. Esto no es simple. La mayor parte de la literatura leída por los testers solo describe los tipos de errores y el manejo de defectos, por ejemplo: el ciclo de vida de los defectos que incluye reportarlos, darles prioridad y gestionarlos. Pero esto es sólo el "trabajo ordinario". Actualmente, hay mucho más por hacer. Puede ser comparado con la tarea de un usuario frustrado cuando llama al servicio técnico: Describir el problema de una manera tal que el otro lado lo acepte como suficientemente importante como para hacer algo con él. Significa recolectar más información sobre el problema, pero también pensar acerca de cómo "vender" el reporte del error a la persona responsable de solucionarlo. Este es el tema central del punto 6. Finalmente, un tester tiene ciertos derechos. No deberíamos limitarnos a testear todo lo que se nos arroje sobre la pared. Si la información que necesitamos no esta disponible, o si el producto a testear es demasiado malo, el testing será de cualquier manera una pérdida de recursos. Debe existir algún criterio de entrada a testing, alguna "Declaración de Derechos del Tester" (Gilb 2003). Esto será discutido en el punto 7. Todo esto debe ser hecho con la filosofía de testing. Pero existen ciertas herramientas, algunas reglas básicas para hacer el trabajo. Existe mucha controversia acerca de lo que es básico, pero me atreveré a incluir algo acerca de eso de un discurso dado en un conferencia (Schaefer 2004). Este será el tema del punto 8. Hay definitivamente más que esto. Un tester debe estar siempre en la perspectiva por más retos en el campo del testing. Este artículo es solo el comienzo de lo que puedes tener en cuenta.
Otra objetivo del testing es el de tratar de crear confianza en el producto. Sin embargo, es mejor construir la confianza tratando de destruirla (y no teniendo éxito al intentarlo). Es como el trabajo científico: Alguien propone una nueva teoría, y todos los especialistas del área tratan de demostrar que es equivocada. Luego de haber intentado derribarla sin éxito durante algún tiempo, la nueva teoría es lentamente aceptada. Este punto de vista es el que utiliza Myers en su definición de testing: ¡Encontrar defectos! Es un enfoque pesimista. El pesimista cree que "esto probablemente no funcione" e intenta demostrarlo. Cada defecto encontrado entonces es un éxito. La motivación hace que la gente funcione. La definición de testing como la búsqueda activa de defectos es motivadora, y las personas de esta forma encuentran más defectos. Funciona de dos maneras: Por un lado, definiendo más casos de prueba destructivos o simplemente sólo definiendo más casos de prueba. Por el otro, teniendo una mirada más cercana de los resultados, analizando detalles que un tester desmotivado dejaría pasar. En el último de los casos puede significar analizar los resultados que no son directamente visibles en la pantalla, pero que se pueden encontrar en archivos, bases de datos, buffers u otros lugares de la red. Un tester debe intentar encontrar defectos. Los defectos pueden aparecer donde uno no los vea fácilmente; es decir, no sólo en la salida gráfica que uno ve por pantalla. ¡Pero es más que esto! "Los defectos son como criaturas sociales: tienden a agruparse juntos." (Dorothy Graham, comunicación privada). Son como los mosquitos: si ves y matas uno, ¿piensas que es el último que anda dando vueltas por el área? Entonces, podemos efectuar una búsqueda de defectos más profunda en áreas donde ya hemos detectado alguno. Los testers deberían tener una idea de donde buscar más. Deberían estudiar los indicadores de calidad, y los reportes acerca de los mismos. Los indicadores pueden ser la actual distribución de defectos, la falta de comunicación interna en el proyecto, la complejidad, los cambios, las nuevas tecnologías, las nuevas herramientas, los nuevos lenguajes de programación, las novedades y cambios en el staff del proyecto, los conflictos entre sus integrantes, etc. El problema es que alguno de estos indicadores a veces apuntan en la dirección incorrecta. Los defectos pueden haber sido encontrados en áreas "casi limpias", sólo porque la distribución de los casos de prueba ha testeado especialmente bien dichas áreas. La comunicación en el proyecto puede parecer espantosa; quienes deberían comunicarse pueden estar lejos unos de otros. De cualquier forma estas personas pueden comunicarse bien, de una manera informal o desconocida; o la interfase entre las partes, de las que son responsables, pudo haber sido especialmente bien definida, casi a "prueba de idiotas" (4). Áreas complejas pueden estar llenas de errores. Existen estudios que demuestran que distintos indicadores de complejidad pueden predecir la distribución de defectos. Sin embargo, siempre hay anomalías. Por ejemplo, las personas más experimentadas pueden trabajar con las partes más complejas. Los cambios introducen defectos o pueden ser el síntoma de áreas que no han sido bien analizadas o entendidas. Pero los cambios también pueden haber sido bien pensados e inspeccionados. En algunos proyectos, existen "muertos"(5) en áreas centrales que nadie quiere levantar. Estas áreas, entonces, están mal especificadas, mal entendidas y puede que completamente podridas. Pero como nadie quiere "hacerse cargo del muerto" (6) no hay solicitudes de cambio. La nueva tecnología también es un riesgo, en parte porque la nueva tecnología conduce a nuevas amenazas; y en parte porque usarla es una novedad para la gente. La gente no conoce cuales son sus desafíos. Lo mismo es aplicable a los testers. Muy poco es conocido acerca de los límites de la tecnología y las herramientas. Sin embargo, puede funcionar de la manera inversa: La nueva tecnología puede mitigar algunos defectos, o simplemente hacerlos imposibles. Finalmente podemos echar un vistazo en la gente involucrada. Son las personas quienes introducen los defectos. Estudios han demostrado que "buenos" y "malos" programadores tienen una amplia diferencia de productividad y tasa de errores. Sin embargo, los defectos no solo son el resultado de la programación. Al menos un factor casi siempre tiene un impacto negativo: la rotación. Si las personas asumen el trabajo de otras, muy a menudo no obtendrán la imagen completa, porque el conocimiento tácito no es transferido. Esto es especialmente cierto si no hay superposición de responsabilidades entre las personas. Así, hay muchos indicadores que nos pueden conducir hacia más defectos, pero debemos usarlos con cuidado. Los defectos se agrupan juntos: ¡son sociales! Los defectos a menudo tienen una causa común. Intenta buscar las causas comunes, y luego ¡síguelas! Donde encuentres defectos, ¡busca en profundidad! Otra definición de testing es medir el riesgo. Esto significa, sencillamente, que el testing es una especie de reducción del riesgo, que forma parte de la gestión de riesgos. Los testers deben tener una idea acerca del riesgo de un producto, así como de la gestión de riesgos. En el peor de los casos, los testers deben hacer preguntas acerca del riesgo de un producto, especialmente si ningún otro las hace. Un método básico para lograrlo es buscar en los perfiles de uso, y en los posibles daños que pueden ocasionar. Un tester debería preguntarse lo que una clase de usuario podrá hacer y cuan seguido lo hará. ¿Cómo usarán los diferentes usuarios el sistema? ¿Cómo variará su uso a lo largo del tiempo? Y es muy importante no olvidarse acerca de las entradas incorrectas y el uso indebido del sistema. La gente tiene problemas al teclear, y la interfaz de los sistemas errores. De esta forma, no sólo se usara el sistema con entradas correctas, sino también con entradas incorrectas. Hay tres clases de tests: El test "bueno", el test "malo" y el test "feo". En el "bueno" todo está bien, en el "malo" las entradas son incorrectas. En el "feo" el infierno se vino abajo (7): Alguien reinicia el server mientras hacemos una reserva y al mismo tiempo estable incorrectamente la fecha del equipo, ... El otro factor de riesgo es el posible daño, que puede ser difícil de analizar. Un comienzo es preguntarse uno mismo: "¿Qué es lo peor que puede pasar si esta función, característica o solicitud falla?". El testing es la reducción de riesgos. ¿Qué determina el riesgo? ¿Qué sucederá si alguna entrada es incorrecta? Como resumen, es mejor si el tester es un pesimista (siendo un pesimista un optimista con experiencia). Si algo no funciona, es una buena noticia, porque nadie sufrirá el defecto luego. El efecto positivo se sentirá a largo plazo. Los mejores tests fuerzan a los desarrolladores a hacer un mejor trabajo, informan acerca de la gestión de riesgos, y conducen a bajar los costos (de reparación). Los testers traen malas noticias, pero ese es su trabajo. ¡No nos gustan los controles de velocidad en las autopistas! Pero hacen que nuestras carreteras sean más seguras, y todos nos beneficiamos. Un pesimista es un mejor tester.
Un tester necesita experiencia en programación. Hay un montón de errores de programación, incluso después de realizadas las pruebas unitarias por los programadores. (De cualquier manera, a menudo, el testing unitario se hace mal). El tester debería tener una idea de que es difícil de hacer con el lenguaje de programación utilizado. Por ejemplo, los bucles y sus contadores son difíciles en la mayoría de los casos, resultando en errores del tipo off-by-one (8). Si el tester no tiene idea acerca de este tipo de errores, no verificará bucles con cero, uno, el máximo y más que el máximo de iteraciones, o no verificará que objeto individual es seleccionado. Así, este tipo de errores serán encontrados sólo de casualidad. El tester necesita tener experiencia como diseñador. Gran parte del diseño tiene que ver con los contratos y la comunicación. ¿Qué módulo dentro de cuales constantes? y ¿con qué reacciones deben hacerse qué tareas? Y, ¿dónde están esos módulos? ¿cómo se comunican y resuelven los conflictos? Si el tester no tiene idea acerca de las arquitecturas y sus problemas inherentes, tendrá problemas al planear las pruebas (de integración). El tester necesita experiencia de campo o dominio. Probar un sistema trata sobre implementar la mejor solución, haciendo lo que exige el dominio. ¿Puedes probar un sistema interrelacionado de ferrocarriles? (eh, por cierto, ¿qué significa interrelacionado?). Al menos, es necesario contar con cierta experiencia de campo, y/o comunicación con los diferentes interesados en la solución (o stakeholders). El problema es que todo lo anterior no es suficiente. Cuando se hace testing es importante obtener la información correcta de la gente correcta. Entonces, es interesante aprender técnicas de entrevistas. ¡Obtienes más información si sabes cómo entrevistar a la gente! Los nuevos sistemas interactúan con otros de una manera más intrincada. Y hay cada vez más interacciones inesperadas. Por ejemplo, alguien puede integrar tu servicio web en su sitio web, junto con otros servicios web. O tu servicio web al trabajar de una manera completamente distinta a la manera en que lo hacen los servicios web de otras personas, deja de ser atractivo (o se hace más atractivo de lo esperado). Que significa todo esto: que hacer las pruebas para los actuales interesados en la solución definitivamente puede no ser suficiente. Hay maneras totalmente nuevas en que tu sistema puede ser usado, maneras totalmente nuevas en que puede ser visto, y tu deberías al menos anticiparte en parte a estas novedades. Un tester debería tratar de encontrar nuevas formas de ver el objeto que esta bajo prueba, nuevos enfoques, nuevos puntos de vista. Y finalmente: Necesitamos que los testers utilicen los más nuevos enfoques y tecnologías. Como tester, debe aprenderlos. ¡Leyendo libros, buscando y aprendiendo a utilizar nuevas herramientas, leyendo publicaciones sobre el tema, participando en grupos de discusión, intercambiando opiniones con colegas, y yendo a conferencias sobre testing! ¡Aprende más, acerca de todo! ¡Programación, arquitecturas, nuevos dominios, usuarios, herramientas, todo! "Estoy utilizando tres cosas para tirar de mi equipaje: perros, perros y perros" . (Roald Amundsen) (9) Para un tester las tres cosas son: aprendizaje, aprendizaje y aprendizaje.
El problema es: creer es fácil. No requiere trabajo creer. Sólo creemos, porque algo es como lo esperábamos, o porque algo es más fácil. Piensa en lo escrito en el periódico. ¿Es realmente cierto? ¿Dónde estaban las armas de destrucción masiva? Mirar televisión, ¿es realmente peligroso para los chicos? Alguna gaseosa, ¿es realmente buena para ti? La respuesta: es más fácil no preguntar. Y si te cuestionas todo, nunca llegarás a ningún lado. Así, en nuestra vida diaria, estamos acostumbrados a no preguntar, y a tomar un montón de cosas por sentadas. ¡Creer o asumir, y no hacer preguntas! Como tester, no asumas nada. ¡Puede ser incorrecto! Los diseñadores, quienes especifican y los programadores asumen un montón de cosas. Preguntar puede ser complicado porque al hacerlo podemos quedar como estúpidos. O quienes deberían responder a nuestras preguntas pueden estar lejos o pueden no estar disponibles. Ni siquiera piensas que puede existir otra interpretación, o la otra parte no lo sabe, o recibes una respuesta sarcástica si intentas saberlo. Usando un punto de vista pesimista, puedes asumir que cualquier hipótesis es probablemente incorrecta. ¡No asumas! ¡Pregunta! Hay formas de superar el problema de que tú parezcas estúpido. Formas tales como aprender a tratar con la gente, aprender a entrevistar, aprender a tener confianza en uno mismo. (Aprendizaje, ver el punto anterior). Preguntarle a otro, también puede ayudar. Lee, revisa, "duerme" sobre el material disponible y trata de encontrar diferentes interpretaciones. Quizá necesites tener la mentalidad de un abogado. Sino recibes una respuesta, agrega la pregunta a tu lista de cuestiones. ¡Pero no asumas nada! ¡No des nada por sentado! Especialmente, no creas en la frase "el sistema probablemente es correcto". Ha existido, al menos, un sistema bancario que pagó mal los intereses. Después de todo, es algo difícil de verificar... Existen sistemas de reservas aéreas que nos informan incorrectamente los vuelos disponibles; y así muchos más ejemplos. ¡Si nadie hace la pregunta correcta, tú quizá podrías hacerla! Piensa en nuevas posibilidades, en problemas desconocidos, y en las cosas que aprendes. ¡Piensa en algo fuera de lo común!
Como tester, la mayor parte de lo que reportas son malas noticias. (En algunos casos no habrá malas noticias, porque todo funcionará tal como esperas; pero esa es otra historia). Las malas noticias son los errores, o cuestiones si los queremos llamar de una manera más neutral. Los libros de texto tratan el tema de los errores correctamente. Hablan acerca del reporte, registro, manejo y remoción de errores; así como también de las pruebas de regresión y de las repruebas luego de la corrección de un error. Todos sabemos eso. Pero hay algo más por saber, y no lo encontramos indicado en los libros muy a menudo: 1) Para un tester, un defecto sólo es interesante si es aceptado como tal y reparado. 2) Hay defectos, que son el resultado de ejecutar muchos casos de prueba en un orden específico. El primer problema tiene que ver con el arte de vender y la disciplina. Como tester, uno tiene un trabajo de ventas. Nadie está interesado en perder dinero en reparar defectos. Sólo serán reparados aquellos defectos si son suficientemente importantes. De esta forma, como tester debes reportar un defecto de tal manera que un desarrollador entienda que debe ser reparado. El daño debe lucir severo, la probabilidad de que ocurra alta, y el error debe ser fácilmente reproducible. El tester no debería sólo escribir el error en su lista de errores. El tester debe pensar: ¿Existen escenarios en que este problema podría ser peor? ¿Hay más interesados en el mismo? ¿Este es el problema real o hay algo más? Nuevamente, se trata de pensar fuera de lo común. Pero también significa inventar y ejecutar algunos casos de prueba más. (Ver el material sobre este tema de Cem Kaner). Finalmente, están las cuestiones humanas: diplomacia, cortesía, etc. Un tester, cuando reporta un error, debe estar seguro de no herir personalmente a nadie. Alguien dijo: "La diplomacia es el arte de mandar al diablo a alguien de manera tal que disfrute iniciar el viaje". ¡Investiga más acerca de cada cuestión (o defecto)! ¡Reporta el error como un riesgo! ¡El reporte de defectos es un trabajo de ventas! ¡Se diplomático cuando reportas errores! El segundo problema es peor: Muchas veces experimentamos fallas, que luego no podemos recrearlas. Por ejemplo, un problema ocurre, y luego no es posible volver a reproducirlo. Estos errores son llamados "errores intermitentes". Es especialmente difícil tener registro de los mismos si introducen errores fatales. Luego de reiniciar el sistema, cualquier dato dañado en memoria puede ser eliminado, destruyendo la evidencia. En muchos casos, los errores intermitentes son el resultado del daño a largo plazo de algunos recursos y de la memoria. Un ejemplo son los fallos de memoria. Algunas funciones de un programa que al finalizar no retornan la memoria sin uso. Sin embargo, al disponer de una gran cantidad de memoria, esto puede pasar inadvertido por mucho tiempo; hasta que la memoria se agota. Es todavía peor si no ocurre siempre, sino en determinadas situaciones. Otros recursos, también pueden agotarse. Por ejemplo, la Mars Explorer dejó de funcionar luego de 18 días debido a demasiados archivos acumulados. (Afortunadamente la NASA pudo descargar el nuevo software). En muchos sistemas de tiempo real, las tareas son reiniciadas cada cierto tiempo a fin de evitar la posible corrupción de recursos. El problema es que cualquier recurso compartido puede dañarse. Es cuestión de verificar las salidas que no son fácilmente visibles, como lo es la salida gráfica por pantalla: Archivos, punteros de memoria, buffers, bases de datos, mensajes a sistemas remotos, registros, cualquier cosa. Puede ser incluso resultado de una condición de carrera (10), que depende de la coordinación exacta de ciertas tareas paralelas. Es fácil ver la salida por pantalla; todo lo demás requiere del uso de herramientas o acciones extras por parte del tester. Puede ser mucho trabajo a realizar todo el tiempo. Además, los errores intermitentes normalmente requieren ejecutar una secuencia completa de casos de prueba, no simplemente una entrada y salida. Finalmente, pueden estar en alguna parte del sistema operativo, en las librerías, en cosas de las que no somos culpables. Sin embargo, si ocurren errores intermitentes, es una buena idea volver a ejecutar la misma secuencia de casos de prueba, quizá también con la misma coordinación, y haciendo más verificaciones que antes. James Bach (Bach 2005) tiene una buena guia para investigar estos problemas: Analiza incluso los errores intermitentes. Registra lo que hagas cuando pruebes. Registra todo lo que ves, y mira en los detalles más remotos. ¡Haz que sea posible poder volver a ejecutar tus pruebas, con más herramientas de registro y análisis encendidas! Un problema final: tú puedes estar equivocado. Errores humanos. Los testers son humanos. Significa que pasas por alto errores, mal interpretas salidas, y alguno de los problemas que piensas haber encontrado no son en realidad problemas. Se auto-crítico: algunas veces es tu culpa. Deberías desconfiar de tu memoria. Es restringida. Lo que significa que es mejor que tomes notas, para registrar lo que hiciste, lo que hizo el sistema, lo que esta instalado, etc. Puedes confiar más en las notas que en tu memoria. Podrías estar equivocado: ¡no confíes en ti mismo al 100%! Toma nota de lo que haces.
El testing a veces es mal utilizado por otros para limpiar el desorden. En lugar de pensar de antemano, los defectos son construidos en el sistema y los testers deben encontrarlos. Esto es tanto una pérdida de tiempo como de esfuerzo. Un defecto encontrado por testers cuesta muchas veces el esfuerzo, que lo habría prevenido, si hubiera sido prevenido. También conduce a extender los plazos de entrega. Los testers no deberían limpiar el desorden; sí medir la calidad y reportar riesgos. Es claramente el trabajo incorrecto. ¡Un tester no es una aspiradora! La respuesta al problema consiste en utilizar un criterio de entrada. Significa forzar a quienes hacen el trabajo previo a hacerlo bien. Hay al menos dos trabajos donde la Declaración de derechos del tester ha sido publicada: Lisa Crispin habla acerca de los testers en su libro "Extreme Programming Projects". Los más importantes derechos del tester son estos tres: · Tú tienes el derecho de hacer y actualizar tus propias estimaciones (...). · Tú tienes derecho a las herramientas que necesites para hacer tu trabajo (...). · Tú tienes el derecho a esperar que tu equipo de proyecto, no sólo tú, sea responsable de la calidad. Tom Gilb (Gilb 2003) desarrolló esta lista de derechos del tester (citada con el consentimiento del autor): Declaración de derechos del Tester: 1) Los testers tienen el derecho de probar las entradas de su proceso, y rechazar trabajos de mala calidad (ninguna entrada). 2) Los testers tienen el derecho a requerimientos claros, sin ambigüedades. 3) Los testers tienen el derecho a una prueba evolutiva tan pronto como el sistema se incrementa. 4) Los testers tienen derecho a integrar la especificación de sus pruebas con las otras especificaciones técnicas. 5) Los testers tienen el derecho de ser parte del ajuste de los niveles de calidad, de lo que luego probarán. 6)Los testers tienen derecho a recursos adecuados para hacer su trabajo profesionalmente. 7) Los testers tienen derecho incluso a una carga de trabajo, y a tener una vida. 8) Los testers tienen derecho a especificar las consecuencias de productos a los que no se les ha permitido poner a prueba correctamente. 9) Los testers tienen derecho a revisar cualquier especificación que pueda afectar su trabajo. 10) Los testers tienen derecho a centrarse en las pruebas de productos que tengan la calidad acordada, y enviar el trabajo mal hecho devuelta a sus fuentes. El último de los derechos es la verdadera clave: ¡Los tester deben enviar el trabajo mal hecho devuelta a sus fuentes!
¿Cómo debería trabajar un tester? ¿Qué debería tener siempre en mente un tester cuando trabaja? Uno de los principales problemas es probar "todo". Eso es, por lejos, demasiado. Nunca podrá ser logrado. Pero el tester debe tener una idea de lo que es probado y lo que no; o lo que se prueba más o menos. Esto hace referencia a la cobertura de una prueba. En resumen, hay tres conceptos básicos de cobertura, y pueden aplicarse a cualquier notación, como lo es un diagrama. Por ejemplo un diagrama de flujo de control, un diagrama de flujo de datos, un diagrama de transición, un gráfico de llamadas o un caso de uso. Un tester debe ser capaz de exponer la cobertura que ha logrado una prueba. Luego, el tester debe seguir el perfil de uso del objeto a probar. Esto es difícil, especialmente en las pruebas de módulos y subsistemas. Pero como tester, uno debe al menos intentar tener una idea de cómo será utilizado el objeto bajo prueba . Si no se puede decir nada, la prueba debe dirigirse a cualquier uso, probando la robustez. Esto significa que los casos de prueba, en que las entradas son incorrectas, son de importancia. Si es posible, ¡sigue los perfiles de uso! Si no es posible, prueba la robustez contra entradas incorrectas. Una técnica es la base de la mayoría de las pruebas de caja negra: la partición por clases de equivalencia(11). Ayuda a ahorrar esfuerzo, y puede ser aplicada para derivar otras técnicas de prueba. Como tester, deberías conocerla, pero también ten en cuenta que tiene sus salvedades: las pruebas de caja negra pueden dejar fuera aspectos importantes. También deberías ser consciente que la combinación de pruebas (utilizando diferentes técnicas) es interesante. Lee Copeland (Copeland 2004) ha publicado una buena introducción sobre el tema. La partición por clases de equivalencia es una buena técnica básica. Recuerda ¡la combinación de pruebas! Finalmente, esta todo el material para hacer las pruebas. El peor escenario es en el que el tester admite que las pruebas no pudieron ser ejecutadas o han sido ejecutadas incorrectamente. Un gran problema es el ambiente de pruebas, que debe ser preparado y probado por anticipado. Esperar por un ambiente de pruebas para trabajar puede matar cualquier esfuerzo de test (y todos los demás señalarán con sus dedos!). Luego de eso, un defecto puede no estar en el objeto bajo prueba, sino en los datos de prueba o en el análisis de salida. Se auto-crítico! Verifica bien el ambiente de test, ¡antes de ejecutar las pruebas!. ¡Verifica tus datos de prueba! Finalmente, existe la automatización de las pruebas. Un producto de software debe ser blando, es decir, fácil de cambiar. El cambio, sin embargo, es un riesgo. Entonces, es necesario probar luego de cada cambio. Volver a ejecutar las pruebas o realizar un test de regresión puede ayudar. Ejecutar los test utilizando robots automáticos puede ayudar en las pruebas regresión. Pero la automatización de pruebas es más que eso: las herramientas pueden leer las especificaciones y generar automáticamente los casos de prueba. Las herramientas pueden automáticamente crear ambientes, o pueden ser usadas para gestionar el esfuerzo y material de prueba. ¡Automatiza tareas de test! ¡Ten en cuenta que hay automatización más allá del uso de los robots de prueba! ------------------------------------------------------------- ------------------------------------------------------------- (1) Tester's Bill of Rights. (2) ISTQB: International Software Testing Qualifications Board. ISEB: Information Systems Examinations Board. GTB: German Testing Board. (3) BS 7925: BS 7925-1 (Glossary of Software Testing Terms) y BS 7925-2 (Software Component Testing Standard). Sponsored by the BCS (British Computer Society Specialist Interest Group in Software Testing). IEEE: The Institute of Electrical and Electronics Engineers. (4) Idiot-proof. (5) Dead dogs. (6) Wake the sleeping dog. (7) All hell break loose. (8) Un error del tipo off-by-one, en programación, es un error evitable en el cual un bucle itera un par de veces, o demasiadas veces más que las deseadas. Usualmente este problema surge cuando un programador no tiene en cuenta que una secuencia comienza en uno en lugar de cero, o cuando comete errores tales como utilizar en una comparación "es menor que" donde "es menor o igual a" debería haberse utilizado. (9) Roald Amundsen: explorador noruego. Quiso ser el primero en conquistar el Polo Norte pero no pudo. Luego, gracias a la preparación física y técnica de la expedición, basada en el uso de trineos tirados por perros y la participación de esquiadores experimentados, así como en amplios conocimientos del terreno; consiguió ser el primero en alcanzar el Polo Sur (diciembre de 1911) e izó allí la bandera Noruega. (10) Race condition: o condición de carrera, expresión utilizada en programación concurrente. Describe el error que se produce en programas o circuitos lógicos cuando no han sido diseñados adecuadamente para su ejecución simultánea con otros. (11)Partición por clases de equivalencia: Es un proceso sistemático que identifica un conjunto de clases de pruebas representativas de grandes conjuntos de otras pruebas posibles; la idea es que el producto bajo prueba se comportará de la misma manera para todos los miembros de la clase. |
martes, 8 de marzo de 2011
Lo que un tester debe saber, en cualquier momento, incluso despues de la medianoche
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario