Una lección para los jefes...

Los trabajadores necesitan incentivos, no computadoras más rápidas.

11 consejos para los que hacen Test Plan con estandar IEEE 829

Comento a continuación algunos consejos que me han sido dados, para cuando uno hace un test plan siguiendo el estándar IEEE 829.
1. Al completar el espacio requerido de referencias, si no se cuenta con un identificador interno del documento dentro de la organización, se debe poner la referencia completa con el formato formal que incluye los autores, el título, la editorial, el lugar y el año (o si es web, el URL y la fecha en que se consultó).
2. Para probar la funcionalidad no necesitan ver la documentación interna (del código). De hecho, a menos que usen pruebas de caja blanca, tampoco se tiene la necesidad de usar el código de la aplicación, bastaría con correr el ejecutable de la aplicación.
3. La usabilidad abarca muchos aspectos más de la interfaz gráfica que sólo verificar la respuesta a las opciones del menú. De igual forma, cuando se habla de navegabilidad, se puede incluir aspectos como: si estando en una pantalla de la aplicación, siempre hay un botón que permita al usuario devolverse a la anterior o al menos a la pantalla principal de la aplicación.
4. La seguridad no es sólo verificar que los roles estén definidos correctamente, sino intentar violar los mecanismos de seguridad y control de acceso sobre esos roles.
5. ¨Altos volúmenes¨ no es medible. En general, si van a hacer pruebas de volumen es porque existen requerimientos explícitos de manejo de volúmenes mínimos para la aplicación, y en tal caso debería hacerse las pruebas contra estos requerimientos medibles (p.ej., la aplicación debe soportar hasta 100 consultas concurrentes)
6. Cuando se habla de baja prioridad, quiere decir los menos importantes, y éstos son los que se dejan para el final (si da tiempo); mientras que los de alta prioridad con los que se corren primero. Talvés la confusión está en que típicamente alta prioridad se indica con cero o uno; mientras que los de baja prioridad se indican con 2 o 3 en un test normal
7. Típicamente cuando las pruebas se suspenden, para dar el visto bueno de reanudación de pruebas se deben correr pruebas de regresión básicas (de prioridad 0) que aseguren la usabilidad del sistema.
8. El plan debe indicar el software que se necesita en el servidor y en el cliente. Por ejemplo, indicar que se necesita Microsoft SQL Server 2008 (para la base de datos) y Microsoft Team Foundation Server (para registrar todo lo concerniente a las pruebas).
9. "Herramientas" es un término demasiado general. Se debe especificar cuáles herramientas, porque si hay herramientas para las cuales necesitan licencia, o que llevan un proceso de instalación complejo y de mucho tiempo, hay que considerarlo dentro del plan de pruebas. Igualmente, hay ocasiones en que sólo la configuración del ambiente de pruebas (software, comunicación, etc) toma más tiempo que las pruebas mismas, entonces hay que indicar cuál es todo el software requerido.
10. Debe indicarse el entrenamiento o capacitación requerida por el equipo de trabajo. Si el equipo de testing necesita capacitarse en el uso de la herramienta VS2010 para poder realizar con éxito sus tareas esto debe planificarse.
11. En la sección de aprobaciones debe citarse el rol de quien tiene que aprobar el plan, no sólo su nombre. Es decir, si es el Test Managar, si es el QA Manager, el Developer Manager, etc.

Gracias a la profesora Martinez por estos consejos, los cuales obviamente son de su autoría.

+ Latex

Recién he intentado hacer un articulo que parezca lo más profesional posible, por un lado tenemos el default de kile y por otro tenemos la plantilla de la IEEE que adjunto a continuación http://mocha-java.uccs.edu/ieee/. Al final como es un trabajo en grupo el formato será una decisión colegiada, sin embargo debe decir que al publicó no lo gusta mucho el estándar IEEE, pese a que ahorra mucho espacio por las dos columnas. Creo que los estudiantes en términos generales somos muy tradicionales y encasillados en los formatos de presentación de los documentos, pero al menos debiéramos tener la capacidad de ajustar flexiblemente la presentación de nuestra obra del conocimiento.
Suerte a los que exploren los estándares no tradicionales.

Pruebas exploratorias

La aventura de las pruebas de software es sin duda un viaje estilo Indiana Jones: Díficil e intensiva en destrezas personales.

Su creador Cem Kaner la define como "un estilo de pruebas de software que se concentra en la libertad personal y la responsabilidad del evaluador para optimizar continuamente la calidad de su trabajo".
El hecho de que las pruebas exploratorias se lleven a cabo sin ningún guión, no significa que éste no tenga estructura ni regla alguna. Las pruebas exploratorias tiene cinco elementos externos: tiempo, probador, producto, misión y reportes. Una prueba exploratoria se lleva a cabo en un tiempo delimitado, sobre un producto específico, por medio de un tester en particular, tratando de cumplir una misión, el cual puede reportar el estado y resultados de la misma en cualquier momento.
Los elementos más importantes de esta metodología son:

• Exploración del producto: Descubrir y almacenar los propósitos y funciones del producto, tipos de datos procesados y áreas potenciales de inestabilidad.
• Diseño de pruebas: Determinar las estrategias de operar, observar y evaluar el producto.
• Ejecución de pruebas: Operaciones sobre el producto, observar su comportamiento y utilizar la información para formar hipótesis sobre cómo el producto trabaja.
• Heurísticas: Guías y reglas de dedo que ayudan a decidir que hacer.
• Resultados revisables: Deben estar oriendados a cumplir los requerimientos o la misión.

El exploratory test es particularmente conveniente si los requisitos y las especificaciones están incompletas, o si se dispone de poco tiempo para el proceso de pruebas.

Sirve también cuando no se sabe qué es lo siguiente que se debe probar o si se debe o no probar un área del programa en particular.

El enfoque también se puede utilizar para verificar que otros tipos de pruebas han encontrado los defectos más importantes en la aplicación.

Pensamiento

“Investigación es la transformación de dinero en conocimientos."

"Innovación es la transformación de conocimientos en dinero"
Bayer AG

Visual Studio 2010 para test

El día de ayer participe en una exposición acerca de test de software automatizados, el expositor, Don Jorge Villegas del BCCR, dio un tour por las nuevas funcionalidades incluídas en Visual Studio 2010 para probar procesos de autenticación, busquedas en web y generación de reportes con los resultados de las pruebas. El resultado impresionante!!!
Me llamó mucho la atención de la exposición la chota a un momento histórico reciente, en que para probar concurrencias y desempeño se reuniá a un grupo de usuarios y algo así como con un silbato se les decía "entre todos a la vez". Me produjo risa porqué yo he participado en pruebas con esta dinámica y aparte de las complicaciones operativas las condiciones nunca eran óptimas para emitir criterio, además de que no eran repetibles de manera semejante.

Ayer pude apreciar como la herramienta configura, cuántos usuarios virtuales participan, en qué momento entrán, hasta que cantidad, etc. Si alguien me pidiera participar nuevamente en una prueba así, me bastaría con comentar lo demostrado que a todas luces es mejor.
Lo aprendido tiene que ver con la necesidad de tener acceso a las vivencias de otros, leer revistas, participar de exposiciones, ir a talleres y no tener ostracismo en algo tan cambiante como la técnologia, si no se tiene el acceso a experiencias como las del señor Villegas se avanzará muy lentamente en los procesos de interiorización del conocimiento.
Termino con muchas espectativas de las exposiciones que vendrán!!!!