Mostrando entradas con la etiqueta pruebas. Mostrar todas las entradas
Mostrando entradas con la etiqueta pruebas. Mostrar todas las entradas

martes, agosto 11, 2009

QA&TEST 09 España

Esta nota esta más orientada para nuestros lectores de España, como ven, ya tenemos "audiencia internacional" :)

Desde la empresa SQS en Bilbao, España, les presentamos QA&TEST 2009, una Conferencia Internacional sobre Testing y Calidad de Software que este año celebrará en el mes de octubre su octava edición. QA&TEST es la conferencia más importante sobre testing celebrada en España y la única dedicada a los sistemas embebidos (empotrados). Es una oportunidad de formación inigualable que contará con 2 tutoriales, 3 keynotes y más de 20 presentaciones de la mano de grandes expertos como Mary Poppendieck, o el Doctor Bruce Douglas (Jefe "Evangelista" de IBM).

"Doctor Bruce Douglas, IBM"

"Mary Poppendieck"

Esta es la nota oficial del evento:

" La 8ª edición de QA&TEST reunirá en Bilbao a empresas y organismos de renombre internacional, como IBM, la NASA o GMV Aerospace and Defense. QA&TEST, la Conferencia Internacional sobre Testing y Calidad de Software en Sistemas Embebidos (Embedded, Empotrados), celebrará su octava edición los días 21, 22 y 23 de octubre en el Palacio Euskalduna de Bilbao. El Programa de QA&TEST, formado por 2 tutoriales, 3 keynotes y 20 presentaciones, reunirá a expertos en testing y calidad de software conocidos en todo el mundo, como Mary Poppendieck, el Dr. Bruce Douglass, de IBM y Guillaume Brat, de la NASA.

El keynote inaugural de la Conferencia correrá a cargo del Doctor Bruce Douglass, Chief Evangelist de IBM, considerado internacionalmente una figura clave en la aplicación del UML en tiempo real y sistemas embebidos. El Dr. Douglass tiene más de 30 años de experiencia en el diseño de aplicaciones en tiempo real para sistemas de seguridad crítica y ha impartido diversos cursos acerca de programación orientada a objetos y desarrollo de sistemas en tiempo real.

Mary Poppendieck, experta en software ágil, impartirá el segundo keynote de QA&TEST. Mary Poppendieck tiene una larga experiencia en desarrollo de software y programación, y es especialista en gestión de proyectos de software. Ha publicado dos libros basados en su amplia experiencia en el mundo del software Lean Software Development: An Agile Toolkit, galardonado con numerosos premios, e Implementing Lean Software Development: From Concept to Cash.

El tercer keynote de la Conferencia lo impartirá Hung Q. Nguyen, responsable de la dirección estratégica y de la gestión ejecutiva empresarial de LogiGear, donde también lidera las iniciativas de la compañía de aproximación al testeo de software, automatización de pruebas, soluciones para herramientas de testeo y programas educativos de testing. Nguyen es co-autor de uno de los libros más vendidos en el ámbito del software testing, Testing Computer Software (2002) y de otras publicaciones, entre las que se incluye Testing Applications on the Web (2003).

Además, esta edición de QA&TEST dará especial importancia al testing y la calidad de software en la industria aeronáutica y aeroespacial, con la presencia de representantes de la NASA, GMV Aerospace and Defense e Israel Aircraft Airlines. Puedes encontrar toda la información relativa a la Conferencia en www.qatest.org.

Puedes encontrar más información acerca de QA&TEST en la página web oficial de la Conferencia www.qatest.org "

Dos breves comentarios sobre esta conferencia:
1. Espero que algun d'ia se celebren una conferencia así en El Salvador.
2. Si eres Español, y tienes la oportunidad de ir, ¡no dudes en hacerlo!

Ah!, pueden seguir el evento en twitter: @qatest_bilbao.

¡Saludos!

QA&TEST 09 España

Esta nota esta más orientada para nuestros lectores de España, como ven, ya tenemos "audiencia internacional" :)

Desde la empresa SQS en Bilbao, España, les presentamos QA&TEST 2009, una Conferencia Internacional sobre Testing y Calidad de Software que este año celebrará en el mes de octubre su octava edición. QA&TEST es la conferencia más importante sobre testing celebrada en España y la única dedicada a los sistemas embebidos (empotrados). Es una oportunidad de formación inigualable que contará con 2 tutoriales, 3 keynotes y más de 20 presentaciones de la mano de grandes expertos como Mary Poppendieck, o el Doctor Bruce Douglas (Jefe "Evangelista" de IBM).

"Doctor Bruce Douglas, IBM"

"Mary Poppendieck"

Esta es la nota oficial del evento:

" La 8ª edición de QA&TEST reunirá en Bilbao a empresas y organismos de renombre internacional, como IBM, la NASA o GMV Aerospace and Defense. QA&TEST, la Conferencia Internacional sobre Testing y Calidad de Software en Sistemas Embebidos (Embedded, Empotrados), celebrará su octava edición los días 21, 22 y 23 de octubre en el Palacio Euskalduna de Bilbao. El Programa de QA&TEST, formado por 2 tutoriales, 3 keynotes y 20 presentaciones, reunirá a expertos en testing y calidad de software conocidos en todo el mundo, como Mary Poppendieck, el Dr. Bruce Douglass, de IBM y Guillaume Brat, de la NASA.

El keynote inaugural de la Conferencia correrá a cargo del Doctor Bruce Douglass, Chief Evangelist de IBM, considerado internacionalmente una figura clave en la aplicación del UML en tiempo real y sistemas embebidos. El Dr. Douglass tiene más de 30 años de experiencia en el diseño de aplicaciones en tiempo real para sistemas de seguridad crítica y ha impartido diversos cursos acerca de programación orientada a objetos y desarrollo de sistemas en tiempo real.

Mary Poppendieck, experta en software ágil, impartirá el segundo keynote de QA&TEST. Mary Poppendieck tiene una larga experiencia en desarrollo de software y programación, y es especialista en gestión de proyectos de software. Ha publicado dos libros basados en su amplia experiencia en el mundo del software Lean Software Development: An Agile Toolkit, galardonado con numerosos premios, e Implementing Lean Software Development: From Concept to Cash.

El tercer keynote de la Conferencia lo impartirá Hung Q. Nguyen, responsable de la dirección estratégica y de la gestión ejecutiva empresarial de LogiGear, donde también lidera las iniciativas de la compañía de aproximación al testeo de software, automatización de pruebas, soluciones para herramientas de testeo y programas educativos de testing. Nguyen es co-autor de uno de los libros más vendidos en el ámbito del software testing, Testing Computer Software (2002) y de otras publicaciones, entre las que se incluye Testing Applications on the Web (2003).

Además, esta edición de QA&TEST dará especial importancia al testing y la calidad de software en la industria aeronáutica y aeroespacial, con la presencia de representantes de la NASA, GMV Aerospace and Defense e Israel Aircraft Airlines. Puedes encontrar toda la información relativa a la Conferencia en www.qatest.org.

Puedes encontrar más información acerca de QA&TEST en la página web oficial de la Conferencia www.qatest.org "

Dos breves comentarios sobre esta conferencia:
1. Espero que algun d'ia se celebren una conferencia así en El Salvador.
2. Si eres Español, y tienes la oportunidad de ir, ¡no dudes en hacerlo!

Ah!, pueden seguir el evento en twitter: @qatest_bilbao.

¡Saludos!

miércoles, marzo 04, 2009

Pruebas de Uso (Usability Test)

Supongamos que estas trabajando en un software, por los últimos... cuatro o cinco meses. Y tienes que entregar un producto terminado en dos semanas (tu deadline es en dos semanas).
Resuelves bugs, tu código esta cubierto (Code Coverage), tu software pasa las pruebas unitarias (Unit Testing), y además, pasa las pruebas de deploy ("Deployar" como escuche mencionar alguna vez) y de pronto, algo realmente importante surge en tu mente, algo que tienes ahi en tu cráneo desde el principio...
¿Es usable mi programa?
Rayos!, esa, si que es una pregunta muy importante, no solo porque tienes que saber:
¿Quien usa mi programa? o ¿Cuanto van a usar mi programa?
... para ver si realmente lo que hiciste es útil. No, no solo es por eso. Es importante, debido a la simple y sencilla razón, de que el cliente o usuario final, es la razón, propósito y motivo ulterior por la que estas desarrollando software, y TU software (o el software que estas desarrollando) DEBE (si, DEBE) facilitar la vida del usuario final de la aplicación.

Que este sea el mantra de esta semana:
"Mi aplicación deberá facilitar la vida del usuario final."
La manera para asegurarte de que este mantra se cumpla lo máximo posible es utilizando las Pruebas de Uso. En el sentido técnico una Prueba de Uso consiste en realizar una prueba de "caja negra" a tu software. Es decir, observar a las personas que van a usar el producto, REALMENTE usándolo para descubrir errores y ÁREAS de mejora.

"Google realiza pruebas de uso, para conocer que áreas de una pagina son las que mas son 'visitadas' por el cursor (esto también es conocido como HeatMap)"

Suele ser de caja negra, porque no importa lo que hace en el fondo el sistema, sino la forma. Generalmente una prueba de uso, medirá que tan bien responden los usuarios en cuatro áreas: eficiencia, exactitud, recuerdo o familiaridad (recall), y respuesta emocional...
  • Rendimiento -- ¿Cuanto tiempo y cuantos pasos se requieren para que una persona realice una tarea básica? (Ordenar Productos, Buscar, etc).
  • Exactitud -- ¿Cuantos errores realizaron las personas? (Fueron errores fatales, recuperables, etc).
  • Recuerdo-- ¿Que tan bien se recuerda el uso del programa, después de largos periodos de no utilizarlo?
  • Respuesta Emocional -- ¿Como se siente una persona al completar una tarea? ¿Estresada, Confiada, Emocionada?
"Es necesario conocer que piensa el usuario final del software que usara"

¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:
  1. No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
  2. Facilitas la vida del usuario final (Diseñar buenas GUI)
  3. Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
  4. Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).
Y definitivamente, es algo que quieres estar haciendo cada quince días o un mes como máximo, no es necesario que cien usuario prueben constantemente el software, uno siempre es mejor que ninguno. A continuación, les describo la mas simple Prueba de Usabilidad que se puedan imaginar:
  • Eliges un usuario final (operativo, gerencia, financiero, etc)
  • Se aísla al usuario, y se le presenta el software.
  • Se le asigna una o un par de tareas a realizar en el sistema.
  • Se observa al usuario resolviendo la tarea.
  • Se pregunta al usuario que piensa de la tarea (¿cuando esta en el proceso?, ¿como cree que puede mejorarlo?)
  • Cuando el usuario termina la prueba (si la termina sin que le de un ataque cardíaco, por la frustración), se le pregunta lo siguiente: ¿Como se siente con respecto a la tarea? ¿Que recuerda del proceso? etc...
  • Repita el proceso, con los usuarios aislados (siempre es mejor, probar a un solo usuario, que a varios para las Pruebas de Uso) y evalué en base a los resultados de las pruebas anteriores.
En el blog de Robin Good, se puede encontrar en detalle una introducción al método "A/B Split Testing", les presento un extracto:

"A/B split testing

Por Lisa Halabi

A partir de cualquier estudio de usabilidad de sitio web, generalmente se encuentran un número de problemas de usabilidad. A menudo puede suscitarse un debate dentro de una organización para hallar la solución a cada problema, sin que nadie conozca realmente la solución óptima. En vez de dejar que prevalezca la opinión de la persona que grita más, una mejor opción puede ser probar dos soluciones en un entorno en vivo. Aquella que tenga el mejor rendimiento es claramente la solución superior. ¡Bienvenido al A/B split testing! ... click aquí para leer mas."

Aquí la clave (resaltada en negritas) es no dejar que prevalezca la opinión del que grita mas, sino la mejor opción, pero para el usuario.


Steve Krug en su libro Don't Make Me Think!, en el capitulo nueve, plantea una serie de aclaraciones sobre las Pruebas de Uso, que toda persona que este encargada de crear software debe de leer, pueden encontrar el capitulo 9 (en Ingles) de la primera edición de este genial libro dando clic aquí.

Espero, sinceramente, que la próxima vez que estén en un proyecto de software, que se preocupen constantemente, en la opinión del usuario final, final, final (el que realmente usara tu software todos los dias, para hacer su vida mas fácil). Para que de esta forma, realmente estés produciendo software enfocado al uso o a la "usabilidad".

Saludos!

Pruebas de Uso (Usability Test)

Supongamos que estas trabajando en un software, por los últimos... cuatro o cinco meses. Y tienes que entregar un producto terminado en dos semanas (tu deadline es en dos semanas).
Resuelves bugs, tu código esta cubierto (Code Coverage), tu software pasa las pruebas unitarias (Unit Testing), y además, pasa las pruebas de deploy ("Deployar" como escuche mencionar alguna vez) y de pronto, algo realmente importante surge en tu mente, algo que tienes ahi en tu cráneo desde el principio...
¿Es usable mi programa?
Rayos!, esa, si que es una pregunta muy importante, no solo porque tienes que saber:
¿Quien usa mi programa? o ¿Cuanto van a usar mi programa?
... para ver si realmente lo que hiciste es útil. No, no solo es por eso. Es importante, debido a la simple y sencilla razón, de que el cliente o usuario final, es la razón, propósito y motivo ulterior por la que estas desarrollando software, y TU software (o el software que estas desarrollando) DEBE (si, DEBE) facilitar la vida del usuario final de la aplicación.

Que este sea el mantra de esta semana:
"Mi aplicación deberá facilitar la vida del usuario final."
La manera para asegurarte de que este mantra se cumpla lo máximo posible es utilizando las Pruebas de Uso. En el sentido técnico una Prueba de Uso consiste en realizar una prueba de "caja negra" a tu software. Es decir, observar a las personas que van a usar el producto, REALMENTE usándolo para descubrir errores y ÁREAS de mejora.

"Google realiza pruebas de uso, para conocer que áreas de una pagina son las que mas son 'visitadas' por el cursor (esto también es conocido como HeatMap)"

Suele ser de caja negra, porque no importa lo que hace en el fondo el sistema, sino la forma. Generalmente una prueba de uso, medirá que tan bien responden los usuarios en cuatro áreas: eficiencia, exactitud, recuerdo o familiaridad (recall), y respuesta emocional...
  • Rendimiento -- ¿Cuanto tiempo y cuantos pasos se requieren para que una persona realice una tarea básica? (Ordenar Productos, Buscar, etc).
  • Exactitud -- ¿Cuantos errores realizaron las personas? (Fueron errores fatales, recuperables, etc).
  • Recuerdo-- ¿Que tan bien se recuerda el uso del programa, después de largos periodos de no utilizarlo?
  • Respuesta Emocional -- ¿Como se siente una persona al completar una tarea? ¿Estresada, Confiada, Emocionada?
"Es necesario conocer que piensa el usuario final del software que usara"

¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:
  1. No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
  2. Facilitas la vida del usuario final (Diseñar buenas GUI)
  3. Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
  4. Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).
Y definitivamente, es algo que quieres estar haciendo cada quince días o un mes como máximo, no es necesario que cien usuario prueben constantemente el software, uno siempre es mejor que ninguno. A continuación, les describo la mas simple Prueba de Usabilidad que se puedan imaginar:
  • Eliges un usuario final (operativo, gerencia, financiero, etc)
  • Se aísla al usuario, y se le presenta el software.
  • Se le asigna una o un par de tareas a realizar en el sistema.
  • Se observa al usuario resolviendo la tarea.
  • Se pregunta al usuario que piensa de la tarea (¿cuando esta en el proceso?, ¿como cree que puede mejorarlo?)
  • Cuando el usuario termina la prueba (si la termina sin que le de un ataque cardíaco, por la frustración), se le pregunta lo siguiente: ¿Como se siente con respecto a la tarea? ¿Que recuerda del proceso? etc...
  • Repita el proceso, con los usuarios aislados (siempre es mejor, probar a un solo usuario, que a varios para las Pruebas de Uso) y evalué en base a los resultados de las pruebas anteriores.
En el blog de Robin Good, se puede encontrar en detalle una introducción al método "A/B Split Testing", les presento un extracto:

"A/B split testing

Por Lisa Halabi

A partir de cualquier estudio de usabilidad de sitio web, generalmente se encuentran un número de problemas de usabilidad. A menudo puede suscitarse un debate dentro de una organización para hallar la solución a cada problema, sin que nadie conozca realmente la solución óptima. En vez de dejar que prevalezca la opinión de la persona que grita más, una mejor opción puede ser probar dos soluciones en un entorno en vivo. Aquella que tenga el mejor rendimiento es claramente la solución superior. ¡Bienvenido al A/B split testing! ... click aquí para leer mas."

Aquí la clave (resaltada en negritas) es no dejar que prevalezca la opinión del que grita mas, sino la mejor opción, pero para el usuario.


Steve Krug en su libro Don't Make Me Think!, en el capitulo nueve, plantea una serie de aclaraciones sobre las Pruebas de Uso, que toda persona que este encargada de crear software debe de leer, pueden encontrar el capitulo 9 (en Ingles) de la primera edición de este genial libro dando clic aquí.

Espero, sinceramente, que la próxima vez que estén en un proyecto de software, que se preocupen constantemente, en la opinión del usuario final, final, final (el que realmente usara tu software todos los dias, para hacer su vida mas fácil). Para que de esta forma, realmente estés produciendo software enfocado al uso o a la "usabilidad".

Saludos!

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...