Mostrando entradas con la etiqueta Pruebas de Software. Mostrar todas las entradas
Mostrando entradas con la etiqueta Pruebas de Software. Mostrar todas las entradas

miércoles, 22 de febrero de 2012

Hablando de pruebas de software y calidad

Con esta imagen empecé hace 2 años una de mis exposiciones favoritas en la especialización, 5 minutos 10 diapositivas, los límites impuestos por uno de mis profes favoritos @betancur en la materia Verificación y Validación.

El tema que escogí para la exposición probar el software completamente es imposible, y que mejor que una referencia como Cem Kaner, experto en el tema de Pruebas de Sotfware para hablar sobre esto en su publicación The Impossibility of Complete Testing (a quien no le gusten los documentos densos, esta publicación tiene una versión corta que les recomiendo leer).

Bien los tuits que me hicieron pensar nuevamente en este tema fueron estos:


Una de las ideas gráficas más claras acerca de las pruebas de software es pensar en los programas como "campos minados" donde evidentemente los bugs (o fallas de calidad) son las minas, la diferencia frente al tema del campo minado, es que no hay como en el espacio físico, fronteras claras sobre el espacio a explorar, y entre otras, en cada revisión existe la posibilidad de que los errores ya encontrados continúen o se introduzcan nuevos, así que ¡vaya tarea!

En este punto es donde siempre recuerdo lecciones aprendidas con @betancur, la primera es clara y es que si tienes un terreno desconocido por explorar, encontrar errores en ese terreno se tratará de tener ideas, los testers deberían ser los mejores compañeros de un emprendimiento, deberían ser profesionales admirables por su capacidad de tener diferentes ideas para explorar y encontrar escenarios nuevos o derivados, entendiendo la heurística como fuente de las ideas, que lejos de ser un escenario de descontrol o desorden busca que además de tener esa chispa de encontrar diferentes vías se usen metodologías, técnicas y mecanismos de investigación para descubrir, develar o encontrar diferentes escenarios y resultados, y es que ni todos los programas de software, ni todos los equipos de trabajo, ni todos los proyectos son iguales, citando a betancur: "Diferentes objetivos requieren diferentes estrategias e implican distintas pruebas, documentación y resultados". 

La segunda de mi más valiosas lecciones aprendidas es:

"Quality is a value for someone"

En esa perspectiva es obvio que el tema resulta bastante subjetivo, pero esa frase es tan real y casi hace alusión a otra frase más típica que dice que "El cliente tiene la razón", esto en cualquier ámbito profesional está lejos de hacerse solo por seguir caprichos, tiene que ver fuertemente con los deseos (sensatos) de las personas y está sustentado en sus necesidades, finalmente y citando otra frase: "Si alguien que no importa encuentra que el producto es terrible es probable que no cambiemos nada".

Ahora bien, si ubicamos la calidad en contexto de tiempo y dinero, bajo nuestro escenario de no tener un espacio de exploración preciso, obtener un punto donde nuestro cliente considere que el software esta 100% probado, podría suponer un escenario de tener un software extremadamente probado en unos varios años cuando el promedio de errores por mes encontrados sea absolutamente insignificante (Insignificante es bien diferente a inexistente). En este punto podría casi escuchar a un cliente preguntando ¿Cuántos años? ¿Cual es el costo? ¿Qué obtenemos a cambio de invertir tanto tiempo es protegernos de posibles errores? No se ustedes que digan, parece un poco difícil convencer a alguien de asumir semejante inversión. Les invito a leer una última frase, con detenimiento:

Probar completamente significa que al final de las pruebas, usted sabe que no quedan mas bugs desconocidos.
Cem Kaner 

Creo que sobran las explicaciones. Por otro lado y para finalizar, algo que nunca debemos perder de vista es que la calidad no se logra encontrando al final de todo un proceso los errores que quedaron, parte de la calidad se logra con el compromiso de los individuos que hacen parte de un equipo en seguir un proceso y mejores prácticas, en tener técnicas y desmitificar el tema de que la improvisación en software es suficiente.

El tema de pruebas de software es un universo completo, como lo es en ingeniería de software cada una de las disciplinas existentes, razón por la que siempre me ven por estos lados discutiendo con los programasoes que se creen que hacer software en "solo" un arte, yo si creo firmemente que hacer software es un arte, pero no es eso solamente y creo que eso falta dejarlo claro.

Una última frase de reflexión
“Aunque haga muchos experimentos, mi hipótesis no queda confirmada, pero basta un solo experimento para confirmar mi error” Albert Einstein

Espero les haya resultado útil

Sorey

domingo, 29 de enero de 2012

Marketplace Test Kit


Como todos sabemos enviar una aplicación al Marketplace tiene un proceso a través del cual nuestra aplicación es certificada por Microsoft como apta y alineada con sus políticas.

Además de cumplir con temas básicos y obvios como alinearse al estilo Metro, la seguridad de los datos de los usuarios y no tener código malicioso, debemos tener en cuenta consideraciones más detalladas que nos sería difícil de recordar, por lo que en el SDK 7.1 fue incluido el Marketplace Test Kit.

Esta herramienta nos ayudará a realizar 3 tipos de test y además nos proveerá una lista de comprobación con 50 puntos que debemos comprobar en nuestras aplicaciones para tener mayor probabilidad de que nuestra aplicación pase el proceso de certificación la primera vez que la enviemos al Marketplace.

Para acceder al Marketplace Test Kit se abre la solución de la aplicación en Visual Studio seleccionando el proyecto a probar y abriendo el Marketplace Test Kit a través del menú contextual del proyecto.

El Marketplace Test Kit se actualizará cuando al ejecutarlo, si los requisitos de certificación del Marketplace cambian y es necesario ejecutarlo por cada proyecto que sea necesario para que tu aplicación funcione correctamente en el teléfono, en caso de tener varios proyectos.

Para usar el Market Test Kit es necesario compilar en modo release, para compilar en modo release o liberar es necesario ir a la barra de herramientas Estándar, y seleccionar Depurar o Liberar (Debug or Release) en el cuadro de lista Configuraciones de soluciones. Esta barra de herramientas no está disponible en Visual Basic Express o Visual C# Express, por lo que es necesario en el Explorador de soluciones, seleccionar el proyecto, en el menú Ver, hacer clic en Páginas de propiedades, luego en la pestaña Compilación o Depurar (Compile or Debug) y en la lista desplegable Configuración en Debug o Release.

Entre las pruebas tenemos las comprobaciones de las características de la iconografía o imagenes asociadas a la aplicación o como es llamado el Application Artwork. Para este punto recuerden que existe una herramienta dentro del emulador para capturar las imágenes que serán la vista premilinar de tu aplicación, el Emulator Screenshot Tool.

Otra de las pruebas consiste en la verificación de las capacidades configuradas en el WMAppManifest.xml, es importante recordar que allí solo deben estar las capacidades del teléfono que a las que tu aplicación necesite para funcionar. Para determinar cuales son con precisión se puede usar el Capability Detection Tool.

Otras de las verificaciones básicas son el tamaño del archivo XAP (Paquete compilado de la aplicación) y el uso correcto del botón de retroceso y que la navegación entre las funciones no sea complicada, además de no caer en la navegación circular, para lo cual ya existe una posible solución publicada por el equipo de Windows Phone.

También se validan temas más avanzados como que haya un control adecuado de los errores de la aplicación que no hagan que esta termine abruptamente, y que el desempeño de nuestra aplicación y el uso de recursos no afecte el funcionamiento de teléfono. De la misma forma que la aplicación no utilice las API que no están permitidos en el teléfono y si es un agente en segundo plano que no use las API que no son permitidas para este tipo de aplicaciones.

Los 4 grupos de pruebas que incluye el Marketplace Test Kit son: Detalles de aplicación, Pruebas automatizadas, Pruebas monitoreadas y Pruebas manuales (Lista de comprobación). La descripción y el uso de cada una de ellas se encuentra explicado en forma detallada en MSDN y traducida a español en La liga silverlight.

Ëxito con sus aplicaciones y hasta la próxima.

Sorey