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.
Tuesday, August 19, 2014
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)