Normalmente, con o sin una metodología formal, el programador estima el número de componentes de software, sus dimensiones aproximadas, el toolkit y lenguaje que va a usar, el estimado de horas en que desarrollará y algunas veces, incluso, algunas de las pruebas que realizará sobre lo que pretende escribir. Un plan general y a veces detallado de las actividades de desarrollo pues.
Si el programa o sistema a desarrollar es grande, seguramente hará un programa más detallado, en el cual incluya detalles de quién potencialmente hará un diseño detallado, quién escribirá el código, de que tamaño va a ser, en que fechas se espera iniciar y terminar... y a veces pondrán una actividad más que diga "pruebas". Esa normalmente no irá detallad.
Un sistema grande en manos de un grupo de desarrollo responsable, seguramente intentará llevar un control aún más riguroso, intentando usar alguna metodología o framework (o ambos) y comenzará a detallar aún más: particionando componentes, actividades, y algunos elementos más, como contingencias, recursos humanos y materiales y a veces "hasta" un plan de pruebas.
La actividad de pruebas muchas veces es ignorada o al menos menospreciada en las metodologías, muchas veces se le resta la formalidad que puede y debe tener.
Demasiadas veces, tratándose de testing, dicha planeación se omite,y las pruebas se van improvisando conforme el sistema crece. Esto, desde luego, representa muchos riesgos, particularmente que las pruebas sean incompletas o incluso que no puedan ser realizadas en absoluto por falta de planeación.
¿Qué requiere un buen plan de pruebas para incrementar las probabilidades de que sea exitoso?
Afortunadamente el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) ha publicado un estándar que nos guía en términos generales por el camino correcto, el estándar IEEE 829 "Estándar para documentación de Pruebas".
Como todos los documentos de IEEE es extensivo y detallado, y además existen literalmente docenas de plantillas en Internet de donde podemos escoger aquella que resulte más adecuada para nuestros proyectos y nuestra empresa.
El plan de pruebas consiste en 19 partes, que aunque suenan muchas, son simples de trabajar, a continuación las revisaremos:
1. Identificador del plan de pruebas.
Simplemente nos debe decir con un identificador único, de qué plan de pruebas se trata, si es un plan maestro o de nivel, o un plan especializado como puede ser de desempeño. Regularmente incluiremos autores, control de cambios y otra información relevante directamente relacionada con el mantenimiento del documento.
2. Referencias.
Referencias a otra documentación del proyecto, como calendarios, documentos de diseño de alto y bajo nivel, requerimientos, estándares, otros planes de prueba y cualquier documento que resulte relevante para la creación y ejecución de las pruebas.
3. Introducción.
Descripción sumaria del plan de prueba. Normalmente se indica el nivel del plan, su relación con otros planes, alcance y la relación del plan con otros items del proyecto como pueden ser recursos, calendario, etapas del ciclo de vida donde se ejecutará el plan, etcétera.
4. Items de prueba.
Funcionalidades, especificadas a muy alto nivel, de lo que será probado. Si se trata de un plan de alto nivel (Maestro) describir el area funcional o de aplicación a probar, o la versión específica. Si se trata de un nivel más bajo, enunciar los módulos o componentes a probar.
5. Riesgos.
Descripción general de los riesgos del plan de prueba, como puede ser una pobre documentación de análisis y diseño, software de terceros, (des)conocimiento de ciertas herramientas de prueba, requisitos específicos de seguridad, áreas del sistema de las que se conoce de demasiados defectos anteriores.
6. Características a probar.
Lista de características desde el punto de vista del usuario que serán probadas, no una descripción técnica de las mismas.
7. Características que NO serán probadas.
También, desde el punto de vista de usuario, todas aquellas características que no serán probadas, especificando la razón por la que no serán probadas, por ejemplo una característica que fue probada previamente, una que no será incluída en la versión.
8. Estrategia.
Describir en términos generales la estrategia para el plan, incluyendo herramientas de prueba, métricas de prueba, administración de configuraciones, hardware y software requerido.
9. Criterios de fallo y éxito.
Especificar cuando se considera que el plan de pruebas pasa y cuando es fallido. Esto no necesariamente quiere decir que todas las pruebas sean exitosas, así que se debe especificar también el nivel de tolerancia de fallos, por ejemplo "no más de 10 defectos cosméticos".
10. Criterios de suspensión y reinicio de pruebas.
Indicar si existe un nivel crítico de fallos que haga inviable seguir probando.
11. Entregables.
Lista de todos los entregables del plan de pruebas, como el plan mismo, sus casos de prueba, los reportes de defectos, bitácoras de servidores, reportes de framework de pruebas automatizadas.
12. Pruebas pendientes.
Listar todas aquellas pruebas que deberán ejecutarse en otro momento, por ejemplo en una versión posterior o que depende de un software de terceros no instalado aún.
13. Requerimientos de ambiente.
Herramientas específicas y características de hardware y software específicos que serán necesarias para efectuar las pruebas, por ejemplo un cliente que usa una versión antigua de navegador requerirá de esa misma versión en el ambiente de pruebas.
14.Necesidades del equipo de trabajo y entrenamiento.
¿Todo el equipo necesita una herramienta de pruebas escogida por el cliente y no la conoce? ¿El sistema es de tal complejidad que requiere de entrenamiento para poder ser probado?
15. Responsables.
Quien hace que dentro del contexto del plan de pruebas.
16. Calendario.
Quién y cuándo va a efectuar las tareas del plan de pruebas.
17. Riesgos y contingencias.
Especificar cuales son los riegos y posibles contingencias del plan de pruebas y cómo se va a reaccionar frente a ellos, por ejemplo que el sistema no sea entregado a tiempo, que no haya datos para probar, que existan restricciones de acceso del cliente.
18. Aprobaciones.
¿Qué y quien aprueba los resultados del plan de pruebas?
19. Glosario.
Espero que esta introducción a IEEE 829 les ayude en su plan perfecto.
Wednesday, August 26, 2015
Tuesday, August 19, 2014
Bugzilla usando GMail
Uno de los mejores bug trackers que existen es Bugzilla (más sobre el tema después). Su instalación ahora es rápida, limpia y directa, es compacto y bastante seguro en general.
Si ya tienes configurado Sendmail (o root ya te hizo el favor de configurarlo) es muy simple que bugzilla mande el correo de cada cambio que se haga en un bug: se requiere una cuenta local que pueda enviar correo y ya.
Pero si Sendmail no está y no tienes demasiado tiempo para hacer las cosas, te estarás enfrentando a instalar y configurar una pieza particularmente compleja de software, que aunque probablemente necesites, no es parte real de tu bugtracker.
La alternativa es usar SMTP de un servidor existente, y gmail tiene esa prestación.
El proceso es simple, se da por supuesto que root instala:
1. Descargar el módulo de perl para gmail
perl -MCPAN -e 'install "email::Send::Gmail"
2. Modificar el archivo /ruta/a/bugzilla/Bugzilla/Mailer.pm
Cambiar la línea que dice
if ($method eq "SMTP") {
a
if (($method eq "SMTP") || ($method eq "Gmail")) {
3. En la pantalla de configuración de correo de Bugzilla http://tu_bugzilla.com/editparams.cgi?section=mta
mailfrom: tuusuario@gmail.com
smtpserver: smtp.gmail.com
smtp_username: tuusuario@gmail.com
smtp_password: ********** tu password en gmail****
smtp_ssl: on
¡Listo! Solo hay que tener algunas precauciones propias de gmail:
No se pueden enviar más de 2 correos por minuto, porque si se supera ese ritmo por 10 minutos o más la cuenta se bloquea temporalmente
Hay que ingresar periódicamente mediante la interfaz web: el hecho de que los correos son muy parecidos y frecuentes puede activar los filtros de spam de gmail y suspender la cuenta, en cuyo caso hay que aclarar que se trata de un bugzilla en funciones.
Disfruten.
Si ya tienes configurado Sendmail (o root ya te hizo el favor de configurarlo) es muy simple que bugzilla mande el correo de cada cambio que se haga en un bug: se requiere una cuenta local que pueda enviar correo y ya.
Pero si Sendmail no está y no tienes demasiado tiempo para hacer las cosas, te estarás enfrentando a instalar y configurar una pieza particularmente compleja de software, que aunque probablemente necesites, no es parte real de tu bugtracker.
La alternativa es usar SMTP de un servidor existente, y gmail tiene esa prestación.
El proceso es simple, se da por supuesto que root instala:
1. Descargar el módulo de perl para gmail
perl -MCPAN -e 'install "email::Send::Gmail"
2. Modificar el archivo /ruta/a/bugzilla/Bugzilla/Mailer.pm
Cambiar la línea que dice
if ($method eq "SMTP") {
a
if (($method eq "SMTP") || ($method eq "Gmail")) {
3. En la pantalla de configuración de correo de Bugzilla http://tu_bugzilla.com/editparams.cgi?section=mta
mailfrom: tuusuario@gmail.com
smtpserver: smtp.gmail.com
smtp_username: tuusuario@gmail.com
smtp_password: ********** tu password en gmail****
smtp_ssl: on
¡Listo! Solo hay que tener algunas precauciones propias de gmail:
No se pueden enviar más de 2 correos por minuto, porque si se supera ese ritmo por 10 minutos o más la cuenta se bloquea temporalmente
Hay que ingresar periódicamente mediante la interfaz web: el hecho de que los correos son muy parecidos y frecuentes puede activar los filtros de spam de gmail y suspender la cuenta, en cuyo caso hay que aclarar que se trata de un bugzilla en funciones.
Disfruten.
Monday, August 18, 2014
Cuando y Cuanto automatizar pruebas.
El siguiente es un artículo que originalmente publiqué en el blog de Quarksoft en mayo de este año. Sale ahora en mi blog de testing.
La industria de la Tecnología de Información, como parte natural de su evolución, ha tomado vertientes diferentes en cuanto a las pruebas de software.
Algunas metodologías alientan el uso de la validación y verificación independiente (IVV). Mientras que otras descartan al tester independiente y regularmente es parte del equipo de desarrollo quien prueba. Incluso, en función del tamaño de la aplicación a probar, es el mismo equipo de desarrollo el que ejecuta las pruebas. Esto desde hace largo tiempo es un poco desalentador como tester y por lo menos desconcertante desde el punto de vista profesional.
Uno de los argumentos que se utilizan es que lo mejor que hace un desarrollador es… claro, desarrollar, hacer código limpio, funcional, eficiente y de calidad. A veces destina mucho de su tiempo en crear pruebas formales, apegadas a un plan bien hecho, cuando las restricciones de tiempo para terminar el proyecto pueden ser estrictas e incluso angustiosas.
La respuesta a la primera pregunta debiese ser siempre un rotundo “Sí”, y en un mundo ideal la respuesta a la segunda debiese ser “todas”. Pero la TI -¡Y el mundo!- no es ideal, así que se deben ponderar cuidadosamente.
Algunos criterios para seleccionar la automatización son los siguientes:
A pesar de ser una fórmula simple, rara vez es aplicada en los proyectos de software. Aunque el costo del proyecto puede inflarse, a veces la abundancia y bajo costo de los recursos para pruebas manuales parecieran justificar el no automatizar, sin embargo el hecho es que lo que de ninguna forma se ahorra es tiempo. El único recurso no renovable y no adquirible, y con frecuencia el más escaso en los proyectos de software.
Automatizar pruebas en la actualidad debiese ser parte de todo modelo o marco de trabajo de desarrollo de software, sea por generalistas o especialistas. La simple aplicación de la fórmula anterior debería ser suficiente para darle especial cuidado a la automatización.
El segundo grupo de criterios básicamente tiene que ver con la complejidad de la aplicación y sus componentes. Automatizar, por ejemplo, las pruebas de un “widget” para tableta o teléfono celular que solamente presenta fecha, hora y temperatura de un lugar específico, seguramente llevaría casi tanto código para el widget mismo como para sus pruebas. Así que el criterio haciendo TD en la ecuación presentada tan grande que hiciese a A negativo inclusive, o por lo menos cercano a cero.
Por otra parte, secciones de código muy complejas con relevancia de negocio, a pesar de tener un ahorro cercano a cero o negativo (típicamente reportes complejos, cálculos estrictos y complicados o pantallas de captura de muchos elementos fuertemente interrelacionados) muy probablemente deban ser automatizados. Esto es debido a la complejidad del código mismo, a las consecuencias de negocio de un fallo del componente o a las consecuencias de un fallo de la prueba misma: tanto un falso positivo como un falso negativo tendrían consecuencias importantes al implicar una refactorización de un componente de por sí complejo.
En la actualidad automatizar pruebas no debiese tener argumentos como la falta de herramientas para hacerlo. Prácticamente no existe lenguaje, framework de desarrollo o pruebas, IDE que no soporte en mayor o menor grado la automatización de pruebas. Por lo cual no debe ser argumento en contra de automatizar. Infinidad de herramientas de automatización existen en el mercado, tanto software libre como propietario. Algunas de ellas son (en orden alfabético): Quick Test Pro de HP, Rational Functional Tester de IBM, Selenium, TestComplete de Smartbear o Watir.
Si en adición al uso adecuado de herramientas de automatización existen buenos procesos de desarrollo y calidad, seguramente existirán ahorros importantes en manejo de calendario de proyecto y calidad de la aplicación.
La industria de la Tecnología de Información, como parte natural de su evolución, ha tomado vertientes diferentes en cuanto a las pruebas de software.
Algunas metodologías alientan el uso de la validación y verificación independiente (IVV). Mientras que otras descartan al tester independiente y regularmente es parte del equipo de desarrollo quien prueba. Incluso, en función del tamaño de la aplicación a probar, es el mismo equipo de desarrollo el que ejecuta las pruebas. Esto desde hace largo tiempo es un poco desalentador como tester y por lo menos desconcertante desde el punto de vista profesional.
Uno de los argumentos que se utilizan es que lo mejor que hace un desarrollador es… claro, desarrollar, hacer código limpio, funcional, eficiente y de calidad. A veces destina mucho de su tiempo en crear pruebas formales, apegadas a un plan bien hecho, cuando las restricciones de tiempo para terminar el proyecto pueden ser estrictas e incluso angustiosas.
Cuánto y cuándo automatizar
Independientemente si se usan generalistas o IVV, es importante ajustarse a presupuesto y tiempo, y unas consideraciones que debería hacer todo PM o Test Manager es “¿Debemos automatizar las pruebas?” y si la respuesta es positiva “¿Cuántas y cuales pruebas deberán ser automatizadas?”.La respuesta a la primera pregunta debiese ser siempre un rotundo “Sí”, y en un mundo ideal la respuesta a la segunda debiese ser “todas”. Pero la TI -¡Y el mundo!- no es ideal, así que se deben ponderar cuidadosamente.
Algunos criterios para seleccionar la automatización son los siguientes:
- Sistemas que tendrán muchos ciclos de desarrollo o sprints.
- Pruebas en las que los errores humanos son probables y causarían falsos resultados.
- Pruebas que requieran de muchos conjuntos de datos.
- Funcionalidades de alto riesgo.
- Pruebas que son humanamente imposibles en tiempo, costo o complejidad.
- Pruebas en múltiples plataformas.
- Pruebas que por sí mismas tomarían demasiado tiempo de ejecutarse manualmente.
- Pruebas de componentes de alta complejidad ciclomática.
A = N*(TM –TA) – TD
Donde:- A = Ahorro en tiempo.
- N = Número de ciclos de desarrollo.
- TM = Tiempo de ejecución de pruebas manuales.
- TA = Tiempo de ejecución de pruebas automatizadas.
- TD = Tiempo de desarrollo de las pruebas automatizadas.
A pesar de ser una fórmula simple, rara vez es aplicada en los proyectos de software. Aunque el costo del proyecto puede inflarse, a veces la abundancia y bajo costo de los recursos para pruebas manuales parecieran justificar el no automatizar, sin embargo el hecho es que lo que de ninguna forma se ahorra es tiempo. El único recurso no renovable y no adquirible, y con frecuencia el más escaso en los proyectos de software.
Automatizar pruebas en la actualidad debiese ser parte de todo modelo o marco de trabajo de desarrollo de software, sea por generalistas o especialistas. La simple aplicación de la fórmula anterior debería ser suficiente para darle especial cuidado a la automatización.
El segundo grupo de criterios básicamente tiene que ver con la complejidad de la aplicación y sus componentes. Automatizar, por ejemplo, las pruebas de un “widget” para tableta o teléfono celular que solamente presenta fecha, hora y temperatura de un lugar específico, seguramente llevaría casi tanto código para el widget mismo como para sus pruebas. Así que el criterio haciendo TD en la ecuación presentada tan grande que hiciese a A negativo inclusive, o por lo menos cercano a cero.
Por otra parte, secciones de código muy complejas con relevancia de negocio, a pesar de tener un ahorro cercano a cero o negativo (típicamente reportes complejos, cálculos estrictos y complicados o pantallas de captura de muchos elementos fuertemente interrelacionados) muy probablemente deban ser automatizados. Esto es debido a la complejidad del código mismo, a las consecuencias de negocio de un fallo del componente o a las consecuencias de un fallo de la prueba misma: tanto un falso positivo como un falso negativo tendrían consecuencias importantes al implicar una refactorización de un componente de por sí complejo.
En la actualidad automatizar pruebas no debiese tener argumentos como la falta de herramientas para hacerlo. Prácticamente no existe lenguaje, framework de desarrollo o pruebas, IDE que no soporte en mayor o menor grado la automatización de pruebas. Por lo cual no debe ser argumento en contra de automatizar. Infinidad de herramientas de automatización existen en el mercado, tanto software libre como propietario. Algunas de ellas son (en orden alfabético): Quick Test Pro de HP, Rational Functional Tester de IBM, Selenium, TestComplete de Smartbear o Watir.
Si en adición al uso adecuado de herramientas de automatización existen buenos procesos de desarrollo y calidad, seguramente existirán ahorros importantes en manejo de calendario de proyecto y calidad de la aplicación.
Friday, January 31, 2014
Che bel piacere
Debiese antes que nada comenzar por justificar la dirección del blog (barbierediqualita.blogspot.com) diciendo que me hace muy feliz el software y probarlo. Llevo casi 15 años haciéndolo y lo disfruto enormemente. Y el título es desde luego por varias razones, cínicamente robado a Gioaccino Rossini, del aria "Largo al Factotum" de "El Barbero de Sevilla" (Il barbiere di Siviglia). En ella Fígaro canta alegremente:
"Ah che bel vivere, che bel piacere, che bel piacere
per un barbiere di qualitá, di qualitá"
(Que bella vida, que bello placer, que bello placer
para un barbero, de calidad, de calidad...)
Si vamos a hablar de calidad, de software o de barberos ¿Que mejor que el Figaro, que disfruta su trabajo, por ajetreado que le parezca? ¿Por que no quitarle un poquito de solemnidad a las pruebas de software y al software mismo?
Tengo algunos colegas que actúan como el médico de Quino. Demasiados. Sobre todo en áreas de arquitectura y regularmente te tratan así:
(Donde dice Médico ponga Ingeniero de Software o Arquitecto de Software, o Project Manager y hasta empresa consultora):
Y comenzaré con analogía...
Siempre, sin excepción, los profesionales de la industria de software (y algunas de las más prestigiosas instituciones de educación e investigación de software) pretendemos "ingenierizarlos": darle métricas y parámetros rigurosos, que permitan construir programas y sistemas como quien construye un estacionamiento o un edificio de departamentos.
¿En serio? ¿Lo toman en serio?
¡Allá ellos! Muy pocos edificios se caen por mero uso, y casi no hay software que no se caiga por mero uso. Corríjanme si hasta aquí me equivoco.
Y no quisiera ser malentendido: la creación de software es una nobilísima profesión, que exige conocimientos, rigor y dedicación a cual más, pero dista mucho de ser comparable con la ingeniería civil, mecánica o química. No funciona igual: la complejidad estructural de cualquier edificio es matemáticamente analizable con leyes físicas y propiedades mecánicas bien conocidas y establecidas y el software lidia con lo más complejo (aparte de enamorarnos) que puede hacer el ser humano: el pensamiento. Un ingeniero civil puede predecir con bastante exactitud bajo que condiciones se va a caer su estructura. Jamás se lo pregunten a un ingeniero de software.
Dos de las primeras razones que hacen "imprevisible" al software son la complejidad y las interacciones. Cuando se considera que una pieza de software de miles, cientos de miles o millones de líneas de código que son convertidas a instrucciones de máquina con compiladores de cientos de miles de líneas de código sobre un sistema operativo...
Blah, el escenario está pintado: complejidad, interacciones.
¿Por que no mejor comparar con algo de mayor complejidad que el edificio? A mi en lo personal me parece más cercano comparar el software con la medicina que con la ingeniería civil: interacciones complejas, regularmente diferentes entre sí, más cuidadas estadísticamente que definidas matemáticamente, el mísmo código (el mismo medicamento) aplicado en un entorno (paciente) diferente, tiene reacciones completamente diferentes. En uno corre (sana) y en otro se cae (el paciente muere)...
Pero como sabiamente dijo un colega: eso es más tema de sobremesa con vino o whisky que cualquier clase de verdad. Menos viniendo de alguien que no es más que un barbero de calidad...
Y a todo eso: En esa analogía ¿Que papel jugamos los de testing/QA?
Muchos colegas testers se han ofendido cuando les digo que el mismo rol del químico farmacobiólogo: tomamos la caca que hacen otros para ver que parásitos tiene y que el señor arquitecto / ingeniero de software le aplique el remedio.
No, no se ofendan. Recuerden que pese a las calumnias, tanto los QFB como los QA tenemos corazón. Y somos igualmente profesionales, aunque no siempre nos agrade lo que vemos.
Y, terminando con Fígaro como comenzamos:
Miglior cuccagna per un barbiere,
vita piu nobile,
no, non si da.
(Mayor abundancia para un barbero,
vida más noble,
no, no se da)
Los dejo con un vídeo (con letra) del "Largo al Factotum". Disfuten su testing como lo hago yo.
"Ah che bel vivere, che bel piacere, che bel piacere
per un barbiere di qualitá, di qualitá"
(Que bella vida, que bello placer, que bello placer
para un barbero, de calidad, de calidad...)
Si vamos a hablar de calidad, de software o de barberos ¿Que mejor que el Figaro, que disfruta su trabajo, por ajetreado que le parezca? ¿Por que no quitarle un poquito de solemnidad a las pruebas de software y al software mismo?
Tengo algunos colegas que actúan como el médico de Quino. Demasiados. Sobre todo en áreas de arquitectura y regularmente te tratan así:
(Donde dice Médico ponga Ingeniero de Software o Arquitecto de Software, o Project Manager y hasta empresa consultora):
Y comenzaré con analogía...
Siempre, sin excepción, los profesionales de la industria de software (y algunas de las más prestigiosas instituciones de educación e investigación de software) pretendemos "ingenierizarlos": darle métricas y parámetros rigurosos, que permitan construir programas y sistemas como quien construye un estacionamiento o un edificio de departamentos.
¿En serio? ¿Lo toman en serio?
¡Allá ellos! Muy pocos edificios se caen por mero uso, y casi no hay software que no se caiga por mero uso. Corríjanme si hasta aquí me equivoco.
Y no quisiera ser malentendido: la creación de software es una nobilísima profesión, que exige conocimientos, rigor y dedicación a cual más, pero dista mucho de ser comparable con la ingeniería civil, mecánica o química. No funciona igual: la complejidad estructural de cualquier edificio es matemáticamente analizable con leyes físicas y propiedades mecánicas bien conocidas y establecidas y el software lidia con lo más complejo (aparte de enamorarnos) que puede hacer el ser humano: el pensamiento. Un ingeniero civil puede predecir con bastante exactitud bajo que condiciones se va a caer su estructura. Jamás se lo pregunten a un ingeniero de software.
Dos de las primeras razones que hacen "imprevisible" al software son la complejidad y las interacciones. Cuando se considera que una pieza de software de miles, cientos de miles o millones de líneas de código que son convertidas a instrucciones de máquina con compiladores de cientos de miles de líneas de código sobre un sistema operativo...
Blah, el escenario está pintado: complejidad, interacciones.
¿Por que no mejor comparar con algo de mayor complejidad que el edificio? A mi en lo personal me parece más cercano comparar el software con la medicina que con la ingeniería civil: interacciones complejas, regularmente diferentes entre sí, más cuidadas estadísticamente que definidas matemáticamente, el mísmo código (el mismo medicamento) aplicado en un entorno (paciente) diferente, tiene reacciones completamente diferentes. En uno corre (sana) y en otro se cae (el paciente muere)...
Pero como sabiamente dijo un colega: eso es más tema de sobremesa con vino o whisky que cualquier clase de verdad. Menos viniendo de alguien que no es más que un barbero de calidad...
Y a todo eso: En esa analogía ¿Que papel jugamos los de testing/QA?
Muchos colegas testers se han ofendido cuando les digo que el mismo rol del químico farmacobiólogo: tomamos la caca que hacen otros para ver que parásitos tiene y que el señor arquitecto / ingeniero de software le aplique el remedio.
No, no se ofendan. Recuerden que pese a las calumnias, tanto los QFB como los QA tenemos corazón. Y somos igualmente profesionales, aunque no siempre nos agrade lo que vemos.
Y, terminando con Fígaro como comenzamos:
Miglior cuccagna per un barbiere,
vita piu nobile,
no, non si da.
(Mayor abundancia para un barbero,
vida más noble,
no, no se da)
Los dejo con un vídeo (con letra) del "Largo al Factotum". Disfuten su testing como lo hago yo.
Subscribe to:
Posts (Atom)